👩‍💼 👉🏼 ✋🏼 الخدمات الصغرى: ما هي ، ولماذا ، ومتى تحتاج إلى تنفيذها 🤧 🤴🏿 👩‍🚀

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

قانون كونواي والعلاقة بين الأعمال والتنظيم ونظام المعلومات

مرة أخرى ، أسمح لنفسي أن أقتبس:

"أي منظمة تصمم نظامًا (بالمعنى الواسع) ستتلقى تصميمًا ينسخ هيكلها بنية فرق العمل في هذه المنظمة"
- ميلفين كونواي ، 1967

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

نظم معلومات التوجه التجاري

سأشرح بمثال. افترض أن هناك فرصة عمل لتنظيم عمل بيتزا. في إصدار V1 (دعنا نسميها ما قبل المعلومات) ، كانت الشركة عبارة عن مطعم بيتزا ، مكتب صرف ، خدمة توصيل. كانت هذه النسخة طويلة الأمد في ظروف التباين المنخفض في العالم المحيط. ثم جاء الإصدار 2 ، الذي كان أكثر تقدمًا وقادرًا على استخدام نظام المعلومات كأساس لأعمال ذات بنية متجانسة. وهنا ، في رأيي ، هناك ببساطة ظلم رهيب فيما يتعلق بالحجارة المتجانسة - يفترض أن العمارة المتجانسة لا تتوافق مع نموذج عمل المجال. نعم ، إذا كان الأمر كذلك ، لما كان النظام قادرًا على العمل على الإطلاق ، على عكس نفس قانون كونواي والحس السليم. لا ، تتوافق العمارة المتجانسة تمامًا مع نموذج الأعمال في هذه المرحلة من تطوير الأعمال - بالطبع أعني المرحلة التي تم فيها إنشاء النظام بالفعل وتشغيله. إنها حقيقة ملحوظة تمامًا أنه بغض النظر عن النهج المعماري ، فإن كلاً من الهندسة الموجهة نحو الخدمة للإصدار 3 وبنية الخدمات الصغيرة للإصدار N ستعمل بشكل جيد على قدم المساواة. ما هو الصيد؟

هل يتدفق كل شيء ، هل يتغير كل شيء ، أم أن الخدمات المصغرة هي طريقة للتعامل مع التعقيد؟

قبل المتابعة ، سننظر في بعض المفاهيم الخاطئة فيما يتعلق ببنية الخدمات الدقيقة.

غالبًا ما يقول مؤيدو نهج الخدمات الدقيقة أن تقسيم وحدة متجانسة إلى خدمات صغيرة يبسط نهج التطوير من خلال تقليل قاعدة التعليمات البرمجية للخدمات الفردية. في رأيي ، هذا البيان هراء مطلق. بجدية ، هل التفاعل الواضح داخل كتلة متجانسة ورمز متجانس يبدو معقدًا؟ إذا كان هذا صحيحًا ، فسيتم بناء جميع المشاريع في البداية كخدمات صغيرة ، بينما تُظهر الممارسة أن الانتقال من الخدمات المتجانسة إلى الخدمات الدقيقة أكثر شيوعًا. لا يختفي التعقيد في أي مكان ، فهو ينتقل ببساطة من الوحدات الفردية إلى الواجهات (سواء حافلات البيانات ، RPC ، APIs وغيرها من البروتوكولات) وأنظمة التنسيق. ومن الصعب!

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

دورة حياة المنتج ودورة حياة الخدمة

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

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

الخدمات الصغيرة كأداة لمكافحة التعقيد ... إدارة التكوين

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

الموجودات

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