هل أنت حقا تريد دفع ضريبة ميكروسوفت؟

لماذا تقسيم قاعدة الكود في وقت مبكر يمكن أن تدمير سرعة فريقك بسهولة - وما يجب فعله بدلاً من ذلك.

لماذا تقسيم قاعدة الكود في وقت مبكر يمكن أن تدمير سرعة فريقك بسهولة - وما يجب فعله بدلاً من ذلك.

في إحدى المدارس،your survival depends on how quickly you can iterate, ship features, and deliver value to end-usersهذا هو المكان الذي يلعب الأكاديمية الأساسية للمبتدئين دورًا كبيرًا؛ بالإضافة إلى ذلك، فإن الأشياء مثل مجموعة التكنولوجيا الخاصة بك والعديد من خيارات لغة البرمجة تؤثر بشكل مباشر على سرعة الفريق الخاص بك.

لقد حصلت على هذه الخبرة عندما عملت على المشاريع الخضراء للشركات الناشئة في المراحل المبكرة ، حيث اتخذت قرارات مشكوك فيها فيما يتعلق بمعمارية البرمجيات التي أدت إلى خدمات منتصف الطريق والإعدادات المحلية المزمنة والمتعددة التكنولوجيا ومزمنةو وdemoralized teamsالذين يحاولون الحفاظ على التكلفة غير الضرورية.

قبل التفكير في الحواجز المحددة ، إليك ما أنت حقا التسجيل عند إدخال ميكروسوفت في وقت مبكر:

Microservices Early On: What You’re Paying For

معقدة التنفيذ

تنسيق 5+ الخدمات لميزة واحدة

Hours lost per release

إزالة الضعف المحلي

Docker Spread, broken scripts, الخاطفين المتخصصين في منصة

Slow onboarding, frequent breakage

تكرار CI / CD

أنابيب متعددة مع منطق متكرر

Extra toil per service

تقييمات Cross-Service

الخدمات "الخلفية" ذات الصلة بالواقع المشترك

Slower changes, coordination tax

التفكير في Overhead

التتبع الموزع ، التتبع ، التتبع

Weeks to instrument properly

اختبار Suite Fragmentation

اختبارات تنتشر عبر الخدمات

Brittle tests, low confidence

دعونا نلقي نظرة على السبب في أن الخدمات الذكية غالباً ما تندفع في وقت مبكر، حيث أنها تساعد حقاً، وكيفية بناء أنظمة بدأتك للسرعة والعيش.

البروتينات ليست أعداء

إذا كنت تخطط لإنشاء منتج SaaS ، فإن حتى محطات بيانات SQL البسيطة قد تؤدي في النهاية إلى الكثير من المعقدة الداخلية في طريقة عمل منطق عملك ، بالإضافة إلى ذلك ، يمكنك الوصول إلى مجموعة متنوعة من التكاملات والمهام الخلفية التي تسمح بتحويل مجموعة من البيانات إلى أخرى.

مع مرور الوقت ، في بعض الأحيان ميزات غير ضرورية ، من المستحيل أن تطور التطبيق قد يزداد صعوبة.Monoliths, even when messy, keep your team focused on what matters most:

• البقاء حية
• توفير قيمة العملاء

أكبر مزايا monoliths هي سهولة تطويرها، وبشكل عام، يتم بناء هذه المشاريع حول إطارين موجودين - قد يكون Django for Python.ASP.NETبالنسبة إلى C#، Nest.js بالنسبة إلى التطبيقات Node.js، وما إلى ذلك، عندما تتأثر بالهيكل البسيط، يمكنك الحصول على أكبر مزيد من الخصائص المميزة - دعم واسع من المجتمع البسيط ومديري المشاريع الذين تم تصميم هذه المرافق بشكل رئيسي للعمل كإجراء واحد، تطبيق البسيط.

في واحدة من تطوير العقارات حيث أود القيام بعملية الجانب الأصلي، وأنا في بعض الأحيان استشارة فريق الخلفية حول خيارات التكنولوجيا، كان لدينا تطور مثير للاهتمام من تطبيق بناء على Laravel.

مع مرور الوقت ، تطور إلى مجموعة غنية بالميزات التي تتعامل مع مئات المائة غيغابايت من الوثائق والتكامل مع عشرات الخدمات من جهات ثالثة.

وافق الفريق بشكل كبير على أفضل الممارسات الموصى بها من قبل المجتمع Laravel.هذه التخصصية تمكننا من زيادة القدرات التطبيقية بشكل كبير في الوقت الذي يلبي احتياجات الأعمال والتوقعات.

من المثير للاهتمام أننا لم نحتاج أبداً إلى إزالة النظام إلى ميكروفونات أو اتخاذ نموذجات أكثر تعقيداً من البنية التحتية.نحاول تجنب الكثير من المعقدة بالطريقة نفسها.إن البساطة في المعمارية أعطيت لنا القدرة على الاستفادة.“المسيح الكبير”وهذا يبين لماذا البساطة هي قوة عظمى في البداية.

غالبا ما يذكر الناس أنه من الصعب جعل البروتوكولين مرنة ، ولكن هذا هو البروتوكولية السيئةداخلالكونفدرالية التي يمكن أن تسبب مثل هذه المشاكل.

Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting.

أليس “الخدمات الذكية” أفضل الممارسات؟

كثير من المهندسين يصلون إلى ميكروبيرات في وقت مبكر ، ويعتقدون أنهم "الطريق الصحيح" ، و بالتأكيد - على نطاق واسع ، يمكنهم مساعدتهم.

تستفيد ميكروسوفت فقط عندما يكون لديك عجلة في التوسع الحقيقي أو فريقين كبيرين أو مراكز تتطور بشكل مستقل. قبل ذلك؟ أنت تتحمل السعر دون الحصول على الفائدة: التعديلات الداخليّة المتكرّرة، وتحديثات محددة ضعيفة، والتبديل السريع.Segmentفي النهايةإعادة توزيع ميكروباصاتهملهذا السبب الحقيقي - تكلفة كبيرة ، وليس قيمة كافية.

Takeaway: Microservices are a scaling tool — not a starting template.

أين تذهب ميكروسوفت (على سبيل المثال في وقت مبكر)

في فريق من المراحل المبكرة التي أقولها، فإن القرار على تقسيم الخدمات خلق المزيد من التنسيق بين PM-engineering أكثر من الفوز التقني.

هنا هي الأكثر شيوعًا المضادات الحيوية التي تنتشر في وقت مبكر.

1- حدود الخدمة الذاتية

في النظرية، في كثير من الأحيان، يمكنك رؤية توصيات حول تقسيم التطبيقات الخاصة بك حسب المجالات المنطقية للشركة - خدمة المستخدمين، خدمة المنتجات، خدمة الطلبات، وما إلى ذلك.

• قاعدة بيانات مشتركة
• تدعو الخدمات المتنوعة إلى تدفقات عمل بسيطة
• التفاعل المختلط بـ "الانفصال"

في واحدة من المشاريع ، شاهدت فريقًا ينقسم المستخدم والموثوقية والموثوقية إلى خدمات منفصلة ، مما أدى إلى تعقيد التطوير والتحديات في تنسيق الخدمة لأي عملية API التي تم إنشاؤها.

في الواقع، فإن منطق الأعمال لا يهدأ مباشرة إلى حدود الخدمة.الانفصال المبكر يمكن أن يجعل النظام أكثر صعوبة وأكثر من ذلك بكثير من الصعوبة في إدخال التغييرات بسرعة.

بدلاً من ذلك ، قم بتحديد المفصل الجراحي - بناءً على الألم الحقيقي ، وليس الرائحة النظرية.

عندما قمت بتدريب فريقين في المراحل المبكرة، لقد استخدمنا في بعض الأحيان علامات داخلية أو خرائط التطوير لتثبيت قطع الخدمة في المستقبل - دون الضغوط التشغيلية المباشرة.

Takeaway: Don’t split by theory — split by actual bottlenecks.

2.الخزانة والتنمية Sprawl

عند العمل على التطبيق ، عادة ما يكون مجموعة التالية من الأشياء مهمة:

• اتساع نمط الكود (Linting)
• اختبار البنية التحتية بما في ذلك اختبار التكامل
• تصميم البيئة المحلية
• الوثائق
• تصنيف CI/CD

إذا كانت مشاريعك متكاملة مثل monorepo، يمكنك تسهل حياتك من خلال وجود نظام CI / CD المركزية (عندما تعمل مع GitHub Actions أو GitLab CI).

بالنسبة إلى فريق من ثلاثة أشخاص، هذا أمرًا عارمًا.البدء في التبديل بين المختبرات والأدوات يزيد من الوقت لتطوير كل ميزات يتم نقلها.

تقليل المشاكل باستخدام monorepos و لغات البرمجة واحدة

هناك العديد من الطرق لتخفيف هذه المشكلة.للمشاريع المبكرة ، فإن أهم شيء واحد هو الحفاظ على الكود الخاص بك في monorepo.هذا يضمن وجود نسخة واحدة من الكود الموجودة على prod ، وهو أمر أسهل بكثير لتنسيق مراجعات الكود والتعاون مع فريقين صغار.

بالنسبة لمشاريع Node.js ، أوصي باستخدام أداة monorepo مثلnxأوturborepoكلاهما :

• تسهيل تكوين CI/CD عبر المشاريع المتوسطة
• الدعم لـ Graph-Based Build Caching
• دعونا نتعامل مع الخدمات الداخلية مثل مكتبات TypeScript (من خلال استيرادات ES6)

هذه الأدوات تخزين الوقت الذي تم إنفاقه على كتابة الكود أو إعادة اختراع التصميم.

• يمكن أن تنمو الأشجار المرتبطة بسرعة
• توزيع الأداء CI ليس سهلاً
• قد تحتاج إلى أدوات أسرع (مثل بون) للحفاظ على أوقات البناء.

أولاً: تثبيت مثلnxأوturborepoيوفر فريقين صغيرين سرعة monorepo - إذا كنت مستعدًا لتستثمر في الحفاظ على نظافةهم.

عند تطويرgo-الخدمات الذكية، فكرة جيدة في وقت مبكر من تطويرها هو استخدام واحد goمساحة العمل معreplaceالمادة فيgo.modفي النهاية ، كما تزداد البرمجيات ، من الممكن تمييزها بسهولة goالتخزين في مستودعات منفصلة.

Takeaway: A monorepo with shared infra buys you time, consistency, and sanity.

إزالة الارتفاع المحلي = إزالة السرعة المحلية

If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity.

غالبًا ما يعاني المشاريع المبكرة من:

• الملفات المفقودة
• التهديدات المفقودة
• هجمات محددة على نظام التشغيل (السلام عليكم، إعدادات Linux فقط)

في تجربتي، عندما حصلت على مشاريع من فريق التطوير السنوي، غالباً ما تم تطويرها لمجموعة واحدة من أنظمة التشغيل. كان بعض المطورين يفضلون بناء على macOS ولا يلجأون إلى دعم نصائحهم في Windows. في فريقي السنوي، كان لدي المهندسين يعملون على أجهزة Windows، وأحياناً كان من الضروري إعادة كتابة نصائح الضوء أو فهم كلياً وإعادة تصميم عملية تشغيل البيئة المحلية. مع مرور الوقت، قمنا بتنظيم إعداد البيئة في جميع أنظمة التشغيل السنوي لتقليل الارتباك في الانضمام، وهو استثمار صغير قد حان الوقت لكل مهندس جديد.

في مشروع آخر، خلصت مؤسسة التطور الفردية إلى إنشاء إعدادات ميكروسوفت ضعيفة، حيث تم تركيب تدفقات Docker إلى نظام ملفات محلي.

لكن إدخال تطوير جديد في المرتبة الأولى مع جهاز الكمبيوتر المحمول Windows القديم أصبح حجر الزاوية. كانوا بحاجة إلى إدخال عشرة محطات فقط للتحقق من جهاز الكمبيوتر المحمول. كل شيء خسر - الكمبيوتر والاتصالات والتوافق مع المحطات - وتتضمن إعدادات صعبة للغاية.

لقد حصلنا على هكذا Node.js بروكس الذي كان يتناول تشكيل nginx/Docker دون محطات. لم يكن رائعًا، ولكن تمكن من إزالة المطور وبدء التمويل.

Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster.

Tip:في الحقيقة ، يهدف إلىgit clone <repo> && make upإذا لم يكن ذلك ممكنًا، فمن الضروري الحفاظ على ملف README حديثيًا مع إرشادات لـ Windows/macOS/Linux. اليوم، هناك بعض لغات البرمجة والمعدات التي لا تعمل جيدًا على ويندوز (مثل OCaml)، ولكن الكمبيوتر المعروفة الحديثة تعمل بشكل جيد على كل نظام تشغيل تستخدم على نطاق واسع؛ من خلال الحد من تثبيتك المحلي إلى نظام تشغيل واحد، فإنه غالبا ما يكون علامة على نقص الاستثمار في DX.

4 - عدم التوازن التكنولوجي

فضلاً عن الأكاديمية، يُعزّز مجموعة التكنولوجيا الخاص بك أيضًا كيفية تصنيع ميكروسوفتات عاطفية - ليس كل لغة تظهر في أكاديمية ميكروسوفت.

• Node.js وPython: جيدًا للتكرار السريع، ولكن إدارة إنشاء العناوين، والتحكم في الإصدارات المرتبطة، والتوافق في وقت التشغيل في جميع الخدمات يصبح سريعًا للغاية.
• Go: يتم جمعها إلى الأدوات الثنائية، وأوقات البناء السريعة، ومعدلات التشغيل المنخفضة.

إذا كنت تبحث عن الأداء، ربما تبحث عن JVM وباقي أنظمةه وقدرة على تطوير العناصر على نطاق واسع وتشغيلها في الأكاديميات القائمة على الخدمات الذكية.إذا كنت تفعل الاختبارات السريعة للغاية والتصوير النموذجي بسرعة دون الاهتمام بتطوير البنية التحتية لتنفيذها - أنت جيد مع شيء مثل Python.

في كثير من الأحيان يدرك الفريقون أن هناك مشاكل كبيرة مع اختيار تقنياتهم التي لم تكن واضحة في البداية، وأنهم كانوا بحاجة إلى دفع تكلفة إعادة بناء الخلفية في لغة برمجة مختلفة (مثل:هؤلاء الرجالتم إجبارها على القيام بأي شيء حول قاعدة الكود Python 2 القديمة وتراجع إلى Go).

ولكن على العكس من ذلك، إذا كنت تحتاج حقاً، يمكنك تجميع لغات البرمجة متعددة مع البروتوكولات مثل:gRPCأو اتصال الرسائل المباشرة. وهذه غالباً هي الطريقة للخروج من الأشياء. عندما تصل إلى النقطة التي تريد أن تجعل مجموعة الخصائص الخاصة بك مع وظائف تكنولوجيا التعلم الآلي أو وظائف تعتمد على ETL، كنت قد تم بناء البنية التحتية القائمة على ML الخاصة بك بشكل منفصل في Python، بسبب منظومة بيئية غنية من المكتبات ذات الصلة بالمساحة، والتي لا تنتهي بشكل طبيعي من أي لغات البرمجة الأخرى. ولكن يجب أن يتم اتخاذ مثل هذه القرارات عندما يكون هناك كمية كافية من القلق لقبول هذه الخطوة.

Takeaway: Match the tech to your constraints, not your ambition.

التفكير الخاطئ: الاتصال والتحكم

ميكروسوفت تطلق شبكة غير مرئية من الاحتياجات:

• خدمة العثور على
• API نسخة
• التخفيضات، التخفيضات، fallbacks
• التتبع الموزع
• الإشارة المركزة و التحذير

في نظام توزيع ، قد يكون خطأً بسيطًا. في نظام توزيع ، هذا هو "لماذا يلغي خدمة A عندما يتوقف توزيع B على C بنحو 30 ثانية؟" سوف تحتاج إلى الاستثمار بشكل كامل في خطوط التفكير الخاصة بك. لإجراء ذلك "حقًا" ، يتطلب إعداد التطبيقات الخاصة بك بطرق محددة ، على سبيل المثال ، تدمير OpenTelemetry لتعزيز التفكير ، أو اعتمادًا على أدوات منتجك على الهواتف الذكية مثل AWS XRay إذا كنت تتعامل مع نظام بدون سرور معيّن. ولكن في هذه المرحلة ، تحتاج إلى نقل التركيز بشكل كامل من قواعد التطبيقات إلى بناء البنية التحتية التقييمية المعقدة لتحديد ما إذا كانت الهيكل الخاص بك متاحة.actuallyالعمل في الإنتاج.

وبطبيعة الحال ، من الضروري أن يتم تنفيذ بعض الأدوات المختبرية على التطبيقات الذكية ، ولكنها أسهل بكثير من ذلك فيما يتعلق بالعدد من الخدمات بطريقة متزامنة.

Tip:فهم هذاdistributed systems aren't free.إنها التزام لمجموعة جديدة من التحديات الهندسية.

إذا كان ميكروباصاتالأواجعل معنى

على الرغم من الصعوبات المذكورة مع microservices ، هناك أحيانًا ما يكون إزالة مستوى الخدمة مفيدًا للغاية.

• إزالة حجم العمل: مثال مشترك لهذا هو في أفضل الممارسات في AWS حول استخدام إشعارات الأحداث S3 - عندما يتم تحميل الصورة إلى S3 ، تسبب عملية تعديل الصورة / OCR ، وما إلى ذلك لماذا هو مفيد: يمكننا إزالة مكتبات معالجة البيانات الفارغة في خدمة إزالة نفسية وتجعلها API التركيز فقط على معالجة الصورة وتوليد الإنتاج من البيانات المرسلة.
• احتياجات التوسع المزدوجة: - تخيل أنك تقوم بتصنيع منتج AI. واحد من الجزء من النظام (API الويب) الذي يقوم بتشغيل كميات عمل ML ويظهر النتائج السابقة ليس كميات ضخمة من الموارد، وهو صغير، لأنه يتفاعل بشكل رئيسي مع قاعدة البيانات. على العكس من ذلك، نموذج ML يعمل على GPUs هو في الواقع صعب التنقل ويحتاج إلى آلات خاصة مع دعم GPU مع إعدادات إضافية.
• متطلبات وقت التشغيل المختلفة: - دعونا نقول لك أن لديك جزءاً من الكود الذي كتبه في C++. لديك خيارين - تحويلها إلى لغة البرمجة الأساسية الخاصة بك أو العثور على طرق لتكثيفها مع قاعدة رمزية. ، اعتماداً على معقدة هذه التطبيق القديم ، سوف تحتاج إلى كتابة الكود ، وتطبيق شبكات / بروتوكولات إضافية لإنشاء التفاعلات مع هذا الخدمة ، ولكن الخطوة الأولى هي - سوف تحتاج إلى تقسيم هذه التطبيق كخدمة منفصلة بسبب عدم التوافقات في وقت التشغيل.

قد تواجه أجهزة الهندسة الكبيرة تحديات مماثلة، على سبيل المثال، فريق الهندسة في Uber.تم توثيق التغييرات الخاصة بهم إلى معمارية ميكروسوفت متكاملة المستوى- ليس من خلال الشفافية النظرية، ولكن في استجابة للعديد من المضاعفات الحقيقية في جميع أنحاء المجموعات والتوسع في الحدود.

في مشروع واحد ، الذي يحدث أيضاً على أساس العقارات ، كان لدينا الكود من فريق سابق يعمل بطاقات العمل التحليلية القائمة على Python التي تنقل البيانات إلى db MS-SQL ، وجدنا أنه سيكون خاسراً بناء على ذلك تطبيق Django.

Takeaway: Use microservices when workloads diverge — not just because they sound clean.

إرشادات عمليّة لـ Startups

إذا كنت ترسل منتجك الأول ، إليك كتاب الأزياء الذي أود أن أقول:

• بدءًا من monolithic. اختار إطارًا مشتركًا ويتم التركيز على الحصول على الوظائف. جميع الإطارين المعروفين أكثر من جيدًا بما فيه الكفاية لإنشاء بعض API أو موقع ويب وخدم المستخدمين. لا تتبع التفكير، التفكير في الطريقة العصيبة للقيام بالأشياء؛ يمكنك شكر نفسك في وقت لاحق.
• لا تتردد في تقسيم رمزك إلى العديد من المختبرات. لقد عملت مع مؤسساتي الذين أرادوا تقسيم المختبرات إلى منفذين لتقليل المخاطر التي يواجهها المتدربون في تصفية IP. ولكن في الممارسة، كان هذا يزيد من الارتباك أكثر من الأمنية: إنشاءات أبطأ، وتقسيمات CI / CD، والظهور السلبي في جميع أنحاء المجموعات. لم تكن حماية IP الحالية تستحق الارتباك العملية، وخاصة عندما كانت التحكم الصحيح في الوصول داخل monorepo أسهل إدارة.
• إنشاء محطة محددة بسيطة. إنشاء عمل. إذا كان يستغرق أكثر من ذلك، أن تكون محددة جداً على الخطوات، تسجيل فيديو / لوم، وإضافة صور شاشات. إذا كانت الكود الخاص بك سوف يتم تشغيلها من قبل المتدرب أو المطور الأصغر، فإنها قد تصل إلى حريق، وسوف تستغرق وقتاً لتفسير كيفية حل مشكلة. وجدت أن توثيق كل مشكلة ممكنة لكل نظام تشغيل يلغي الوقت المطلوب لتفسير لماذا أشياء معينة في إعداد المحطة لا تعمل.
• الاستثمار في CI / CD في وقت مبكر. حتى لو كان هذا هو HTML بسيط يمكنك فقط scp إلى خادم يدويًا، يمكنك تثبيت هذا وتعتمد على التحكم في مصدر مع CI / CD للقيام بذلك. عندما يتم تثبيت تلقائيًا بشكل صحيح، يمكنك فقط أن تنسى البنية التحتية التكاملية المستمرة الخاصة بك وتتطلع إلى الميزات. لقد رأيت العديد من الأندية والمؤسسات عند العمل مع فريقين أجانب غالباً ما تكون رخيصة على CI / CD، وهذا يؤدي إلى أن الفريق يتم إزعاج وتعب من قبل عمليات التطوير اليدوي.
• تقسيم الجراحة. تقسيم فقط عندما يتم حلها بصورة واضحة إلى حد ما، إذا لم تتمكن من الاستفادة من التكوينات والتحليلات داخل النسيج، فإنها أسرع وأسهل للحفاظ على.

وأكثر من ذلك:optimize for developer velocity.

Velocity is your startup’s oxygen.الأجهزة الذكية المبكرة تنفذ هذه الأكسجين ببطء - حتى يوم واحد ، لا يمكنك التنفس.

Takeaway: Start simple, stay pragmatic, and split only when you must.

إذا كنت تستخدم نهجًا متكاملًا

كان لدي مشاريع تعتمد على الخدمات الصغيرة التي تم إنشاؤها أولاً مما كان ينبغي أن تم إنشاؤها ، وهنا التوصيات التالية التي يمكنني أن أقدمها على ذلك:

• تقييم قوائم التقنية الخاصة بك التي تتيح بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة بيئة
• التركيز على بروتوكولات الاتصالات الموثوقة حول الاتصال الخدمي. إذا كان الاتصال غير المباشر، تأكد من أن خطط الرسائل الخاصة بك متوافقة ومستقرة. إذا كان REST، التركيز على توثيق OpenAPI. يجب تطبيق عملاء الاتصال بين الخدمات العديد من الأشياء التي لا تأتي من الخلفية: إعادة توزيعها مع ردود الفعل العنقودية، إعادة توزيع الوقت. يحتاج ملف gRPC عاديًا إلى تقييم هذه الأشياء الإضافية بشكل رئيسي لتأكد من أنك لا تتأثر بالخطأ المفاجئ.
• تأكد من أن تكوين جهازك، والتحقيق في التكامل، والتحقيق في نهاية المطاف مستقر، وتتراكم مع كمية الاختلافات على مستوى الخدمة التي تقوم بها في قاعدة الكود الخاصة بك.
• على المشاريع الصغيرة التي تستخدم كميات عمل مبتكرة من الخدمات الصغيرة، قد تعتمد على المكتبة المشتركة مع المساعدين المشتركين لتنظيم إشارات الاتصال الخاصة بك بطريقة متكاملة.
• انظر إلى الملاحظة في وقت مبكر. اشترى تسجيلات JSON المكونة من البروتوكولات وخلق IDات التوازن المختلفة للتحقق من الأشياء بعد تطوير التطبيق. حتى المساعدات الأساسية التي تنتج معلومات التسجيل الغنية (حين تم تصميم التطبيق مع إمكانات التسجيل / التتبع المناسبة) غالباً ما تخزين الوقت في معرفة تدفقات المستخدم المزعج.

على سبيل المثال: إذا كنت لا تزال ترغب في ميكروخدمات، يجب عليك أن تفهم على الفور الضرائب التي ستدفعها من حيث الوقت الإضافي للتطوير والتدريب لتجعل الإعدادية فعالة لكل مهندس في الفريق الخاص بك.

Takeaway: If you embrace complexity, invest fully in making it manageable.

النتيجة

Premature microservices are a tax you can’t afford. Stay simple. Stay alive.تختلف فقط عندما يجعل الألم واضحًا.

Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add.

الموارد ذات الصلة

• Monolith First – مارتن فاولر
• The Majestic Monolith - DHH / Basecamp
• إعجاباً على ميكروفونات: من 100 من الأطفال المشكلة إلى 1 سوبر ستار - قسم Eng.
• كيفية إزالة الضوء - Shopify Eng.
• تكنولوجيا الذكاء الاصطناعي (Domain-Oriented Microservice Architecture)
• Go + Services = One Goliath Project - أكاديمية خان