كنت أرغب في كتابة مقال عن موضوع بنية الخدمات الصغيرة لفترة طويلة، لكن نقطتين ظلتا تمنعانني - كلما تعمقت في الموضوع، بدا لي أن ما أعرفه واضح، وما أعرفه واضح. ما أعرفه يحتاج إلى دراسة ودراسة. ومن ناحية أخرى، أعتقد أن هناك بالفعل شيئًا يستحق المناقشة بين جمهور واسع. لذلك نرحب بالآراء البديلة.
قانون كونواي والعلاقة بين الأعمال والتنظيم ونظام المعلومات
ومرة أخرى سأسمح لنفسي أن أقتبس:
"إن أي منظمة تصمم نظامًا (بالمعنى الواسع) ستحصل على تصميم يحاكي هيكله هيكل الفرق في تلك المنظمة."
- ملفين كونواي، 1967
في رأيي، من المرجح أن يتعلق هذا القانون بجدوى تنظيم الأعمال التجارية، وليس مباشرة بنظام المعلومات. اسمحوا لي أن أشرح مع مثال. لنفترض أن لدينا فرصة عمل مستقرة إلى حد ما مع دورة حياة طويلة جدًا بحيث يكون من المنطقي تنظيم مؤسسة (هذا ليس خطأ مطبعي، لكنني حقًا أحب هذا المصطلح الذي سرقته). وبطبيعة الحال، النظام الداعم لهذه الأعمال سوف تتوافق تنظيميًا وإجرائيًا مع هذا العمل.
التوجه التجاري لنظم المعلومات
اسمحوا لي أن أشرح مع مثال. لنفترض أن هناك فرصة عمل لتنظيم مشروع تجاري لبيع البيتزا. في الإصدار V1 (دعنا نسميها المعلومات المسبقة)، كانت الشركة عبارة عن مطعم بيتزا، وسجل نقدي، وخدمة توصيل. كان هذا الإصدار طويل العمر في ظروف التقلبات البيئية المنخفضة. ثم جاء الإصدار 2 ليحل محله - وهو أكثر تقدمًا وقدرة على استخدام نظام المعلومات في جوهره للأعمال ذات البنية المتجانسة. وهنا، في رأيي، هناك ببساطة ظلم فظيع فيما يتعلق بالمتراصة - الهندسة المعمارية المتجانسة المزعومة لا تتوافق مع نموذج أعمال المجال. نعم، لو كان الأمر كذلك، فلن يتمكن النظام من العمل على الإطلاق - وهو ما يتعارض مع نفس قانون كونواي والفطرة السليمة. لا، إن الهندسة المعمارية المتجانسة تتوافق تمامًا مع نموذج الأعمال في هذه المرحلة من تطوير الأعمال - وأنا بالطبع أعني المرحلة التي تم فيها إنشاء النظام وتشغيله بالفعل. إنها حقيقة رائعة للغاية أنه بغض النظر عن النهج المعماري، فإن كلاً من الإصدار 3 من البنية الموجهة نحو الخدمة والإصدار N من البنية الموجهة للخدمات الصغيرة سيعملان بشكل جيد على قدم المساواة. ما الفائدة؟
كل شيء يتدفق، كل شيء يتغير، أم أن الخدمات الصغيرة هي وسيلة لمكافحة التعقيد؟
قبل أن نواصل، دعونا نلقي نظرة على بعض المفاهيم الخاطئة حول بنية الخدمات الصغيرة.
غالبًا ما يجادل مؤيدو استخدام نهج الخدمات الصغيرة بأن تقسيم كتلة متراصة إلى خدمات صغيرة يبسط نهج التطوير عن طريق تقليل قاعدة التعليمات البرمجية للخدمات الفردية. في رأيي، هذا البيان هو محض هراء. على محمل الجد، يبدو التفاعل الواضح داخل كود متراص ومتجانس معقدا؟ إذا كان هذا هو الحال حقًا، فسيتم إنشاء جميع المشاريع في البداية كخدمات صغيرة، في حين تظهر الممارسة أن الانتقال من وحدة متراصة إلى خدمات صغيرة هو أكثر شيوعًا. لا يختفي التعقيد، بل ينتقل ببساطة من الوحدات الفردية إلى الواجهات (سواء كانت ناقلات البيانات، أو RPC، أو واجهات برمجة التطبيقات، والبروتوكولات الأخرى) وأنظمة التنسيق. وهذا صعب!
إن ميزة استخدام المكدس غير المتجانس أمر مشكوك فيه أيضًا. لن أزعم أن هذا ممكن أيضًا، لكنه نادرًا ما يحدث في الواقع (بالنظر إلى المستقبل - يجب أن يحدث هذا - بل كنتيجة وليس ميزة).
دورة حياة المنتج ودورة حياة الخدمة
نلقي نظرة أخرى على الرسم البياني أعلاه. ليس من قبيل المصادفة أنني لاحظت انخفاض دورة الحياة لإصدار منفصل من الأعمال - في الظروف الحديثة، فإن تسريع انتقال الأعمال بين الإصدارات هو العامل الحاسم لنجاحها. يتم تحديد نجاح المنتج من خلال سرعة اختبار فرضيات العمل فيه. وهنا، في رأيي، تكمن الميزة الرئيسية لهندسة الخدمات الصغيرة. ولكن دعونا نذهب بالترتيب.
دعنا ننتقل إلى المرحلة التالية في تطور أنظمة المعلومات - إلى بنية SOA الموجهة نحو الخدمة. لذلك، في مرحلة معينة سلطنا الضوء على منتجنا خدمات طويلة الأمد - طويلة الأمد، بمعنى أنه عند التنقل بين إصدارات المنتج، هناك احتمال أن تكون دورة حياة الخدمة أطول من دورة حياة الإصدار التالي من المنتج. سيكون من المنطقي عدم تغييرها على الإطلاق - نحن ما يهم هو سرعة الانتقال إلى الإصدار التالي. لكن للأسف، نحن مجبرون على إجراء تغييرات مستمرة على الخدمات - وهنا كل شيء يعمل لصالحنا، ممارسات DevOps، النقل بالحاويات، وما إلى ذلك - كل ما يتبادر إلى الذهن. لكن هذه لا تزال ليست خدمات صغيرة!
الخدمات المصغرة كوسيلة لمكافحة التعقيد...إدارة التكوين
وهنا يمكننا أخيرًا الانتقال إلى الدور المحدد للخدمات الصغيرة - وهذا هو النهج الذي يبسط إدارة تكوين المنتج. بمزيد من التفصيل، تصف وظيفة كل خدمة صغيرة بالضبط وظيفة العمل داخل المنتج وفقًا لنموذج المجال - وهذه هي الأشياء التي لا تعيش في إصدار قصير العمر، ولكن في فرصة عمل طويلة العمر. والانتقال إلى الإصدار التالي من المنتج يحدث دون أن يلاحظه أحد حرفيًا - حيث تقوم بتغيير/إضافة خدمة صغيرة واحدة، وربما مجرد مخطط تفاعلهم، وفجأة تجد نفسك في المستقبل، تاركًا وراءك المنافسين الباكيين الذين يواصلون القفز بين إصدارات المنتج متراصة بهم. تخيل الآن أن هناك عددًا كبيرًا إلى حد ما من الخدمات الصغيرة ذات الواجهات وقدرات الأعمال المحددة مسبقًا. وتأتي وتبني هيكل المنتج الخاص بك من الخدمات الصغيرة الجاهزة - ببساطة عن طريق رسم رسم تخطيطي، على سبيل المثال. تهانينا - لديك منصة - والآن يمكنك جذب الأعمال لنفسك. أحلام أحلام.
النتائج
- يجب أن يتم تحديد بنية النظام من خلال دورة حياة مكوناته. إذا كان أحد المكونات موجودًا ضمن إصدار المنتج، فلا فائدة من زيادة تعقيد النظام باستخدام أسلوب الخدمة الصغيرة.
- يجب أن تعتمد بنية الخدمات الصغيرة على نموذج المجال - لأن فرصة العمل هي المجال الأطول عمراً
- تعد ممارسات التسليم (ممارسات DevOps) والتنسيق أحد أهم الممارسات في بنية الخدمات الصغيرة - وذلك لأن الزيادة في معدل تغيير المكونات تؤدي إلى زيادة الطلب على سرعة التسليم وجودته
المصدر: www.habr.com