غير مصنف

ما هي الخدمات المصغرة؟

ما هي الخدمات المصغرة؟

الخدمات المصغرة (أو بنية الخدمات متناهية الصغر) هي منهج بناء أصلي بالبيئة السحابية حيث يتكون فيه التطبيق الواحد من مكونات أو خدمات متعددة صغيرة ومتباعدة وقابلة للنشر بشكل مستقل. هذه الخدمات عادة ما

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

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

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

للاطلاع على مزيد من المعلومات حول الاختلافات بين الخدمات المصغرة والبنية المتجانسة، شاهد هذا الفيديو (6:37):

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

يتعرض منشور “SOA vs. Microservices: What’s the Difference?‎” لمزيد من التفاصيل.

كيف تستفيد المؤسسة من الخدمات المصغرة

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

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

(المصدر: ‘Microservices in the enterprise 2021: Real benefits, worth the challenges’.‎)

إليك بعض من المزايا التي تجنيها المؤسسة من الخدمات المصغرة.

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

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

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

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

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

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

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

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

ومع ذلك، فإن هذه التحديات لا تمنع الجهات غير المتبنية من تبني الخدمات المصغرة – أو الجهات المتبنية من تعميق التزامها تجاه الخدمات المصغرة. أظهرت بيانات البحث التقييمي الجديد الذي أجرته IBM أنه من المرجح أو المرجح جدا أن يقوم 56% من غير-المستخدمين الحاليين بتبني واعتماد الخدمات المصغرة خلال العامين القادمين، وأنه من المرجح أن يقوم 78% من مستخدمي الخدمات المصغرة الحاليين بزيادة الوقت والمال والجهد الذي قاموا باستثماره في الخدمات المصغرة (أنظر الشكل 1).

ثلاث رسوم بيانية دائرية تظهر 56 في المائة و78 في المائة و59 في المائة
الشكل ‏1‏: الخدمات المصغرة هنا لتبقى. في غضون العامين المقبلين، من المرجح أن يتبنى 56% من غير-المستخدمين الخدمات المصغرة، وسوف يقوم 78% من المستخدمين بزيادة استثماراتهم في الخدمات المصغرة، وسوف يتم تكوين 59% من التطبيقات عن طريق الخدمات المصغرة. (المصدر: ‘Microservices in the enterprise 2021: Real benefits, worth the challenges’.)

الخدمات المصغرة تتيح DevOps وتطلبه

كثيرا ما يتم وصف بنية الخدمات المصغرة بأنها قد تم تطويرها بالشكل الأمثل لتناسب DevOps والتكامل المستمر/التسليم المستمر (CI/CD)، وفي سياق الخدمات الصغيرة التي يمكن نشرها بصورة متكررة، من السهل أن تفهم السبب وراء ذلك.

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

لطلب خدمة مصغره لتصميم صور خدمات او النشر على المنتديات يمكنك زيارة صفحتي على خمسات

https://khamsat.com/user/hussamabed

مقالات ذات صلة

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

زر الذهاب إلى الأعلى
error: لا نسمح لك بنسخ المحتوى