الخدمات المصغرة

menu icon

الخدمات المصغرة

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

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

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

  • يكون لها حزمة التكنولوجيا الخاصة بها، بما يتضمن قاعدة البيانات ونموذج إدارة البيانات؛
  • تقوم بالاتصال ببعضها البعض من خلال مجموعة من واجهات تعامل البرمجة 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 من أجل أن تحقق النجاح. في حين أن التطبيقات المتجانسة لها عدد من السلبيات التي تم مناقشتها في السابق في هذه المقالة، إلا أنها يتوافر بها ميزة كونها ليست نظاما موزعا معقدا بأجزاء متحركة متعددة وحزم تقنية مستقلة. وعلى النقيض من ذلك، ونظرا للزيادة الهائلة في التعقيد والأجزاء المتحركة والارتباطات التي تأتي مع الخدمات المصغرة، فإنه من غير الحكمة الاقتراب من الخدمات المصغرة بدون استثمارات كبيرة في النشر والمراقبة والتشغيل الآلي لدورة الحياة.

أندريا كروفورد تقدم نظرة أعمق حول DevOps في الفيديو التالي:

التقنيات والأدوات التمكينية الرئيسية

في حين أن أي أداة أو لغة حديثة يمكن استخدامها في بنية الخدمات المصغرة، فإن هناك عدد بسيط من الأدوات الأساسية التي أصبحت ضرورية وتعريفية للحدود بالنسبة للخدمات المصغرة:

الحاويات وDocker وKubernetes

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

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

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

في فيديو "Kubernetes Explained،" يقدم ساي فينام نظرة شاملة عن Kubernetes وكل ما يتعلق به:

 

آليات اتصال API

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

هناك العديد من التقنيات التي يمكن استخدامها لتجهيز آليات اتصال API، بما في ذلك منصات إدارة API، ولكن إذا كان يتم تجهيز بنية الخدمات المصغرة باستخدام الحاويات وKubernetes، فعادة ما يتم تنفيذ آلية الاتصال باستخدام Ingress أو، مؤخرا، Istio.

برامج الرسائل وتدفق مرسلات الأحداث

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

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

بدون وحدة خدمة

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

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

الخدمات المصغرة والخدمات السحابية

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

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

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

الأنماط الشائعة

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

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

يمكنك التعرف على المزيد عن هذه النماذج في "كيفية استخدام نماذج التطوير مع الخدمات المصغرة (الجزء 4)". كما يقدم IBM Developer أيضا الكثير من المعلومات إذا كنت تريد التعرف على نماذج أخرى من الأكواد للخدمات المصغرة.

النماذج المضادة

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

  • القاعدة الأولى للخدمات المصغرة هي، لا تقوم ببناء الخدمات المصغرة: وبطريقة أكثر دقة، لا تبدأ بخدمات مصغرة. تعد الخدمات المصغرة طريقة لإدارة مدى التعقيد بمجرد أن تصبح التطبيقات كبيرة للغاية ويصبح تحديثها وصيانتها بسهولة أمر غير عملي. فقط عندما تشعر بتسلل المشاكل والتعقيد في المنهج المتجانس، حينها يستحق الأمر النظر في كيفية تعديل الكود في التطبيق وتحويله إلى خدمات أصغر. حتى تشعر بهذا الألم، فلن يكون لديك حقا التطبيق المتجانس الذي يحتاج إلى تعديل الكود.
  • لا تعمل بخدمات مصغرة بدون DevOps أو الخدمات السحابية: بناء الخدمات المصغرة يعني بناء الأنظمة الموزعة، والأنظمة الموزعة صعبة (وتكون صعبة بشكل خاص إذا قمت باختيارات تجعلها أكثر صعوبة). تعتبر محاولة العمل بخدمات مصغرة بدون أي من (أ) التشغيل الآلي الصحيح للنشر والمراقبة أو (ب) خدمات سحابية مدارة لدعم البنية الأساسية المتمددة وغير المتجانسة الخاصة بك، مجلبة للكثير من المشاكل غير الضرورية. احم نفسك من المتاعب بحيث يمكنك قضاء وقتك في الاهتمام بالحالة.
  • لا تقم ببناء خدمات صغيرة جدا بحيث يصبح عدد الخدمات المصغرة كبير جدا: إذا تماديت في مفهوم "الصغر المتناهي (micro)" الذي تقدمه الخدمات المصغرة، تجد بسهولة أن ما يتحقق من نفقات عامة وتعقيدات يفوق المكاسب الكلية لبنية الخدمات المصغرة. من الأفضل أن تميل نحو خدمات أكبر حجما، ومن ثم تقسيمها عندما تبدأ في إخراج صفات تعمل الخدمات المصغرة على حلها - أي أنها أصبحت صعبة وبطيئة في نشر التغييرات، أو أن نموذج البيانات المشترك قد أصبح معقدا أكثر من اللازم، أو أن أجزاء مختلفة من الخدمة أصبحت لها متطلبات مختلفة للتحميل/لتوسيع النطاق.
  • لا تقم بتحويل الخدمات المصغرة إلى SOA: دائما ما يتم الخلط بين الخدمات المصغرة والبنية الموجهة للخدمات (SOA)، نظرا لأنهما في أبسط مستوياتهما يهتمان ببناء مكونات فردية قابلة لإعادة الاستخدام، يمكن استهلاكها بواسطة تطبيقات أخرى. يعد الاختلاف بين الخدمات المصغرة وSOA هو أن مشروعات الخدمات المصغرة تتضمن عادة تعديل الكود للتطبيق بحيث يصبح أسهل في إدارته، بينما تهتم SOA بتغيير طريقة عمل خدمات تكنولوجيا المعلومات على نطاق المؤسسة. مشروع الخدمات المصغرة الذي يتحول إلى مشروع SOA غالبا سوف ينهار تحت ثقله.
  • لا تحاول أن تكون مثل Netflix: كانت Netflix واحدة من الرواد الأوائل في استخدام بنية الخدمات المصغرة عند بناء وإدارة تطبيق يحتل ثلث حجم حركة إرسال واستقبال البيانات بالكامل على الإنترنت - نوع قد يوصف بالعاصفة العنيفة التي تطلبت منهم بناء الكثير من الأكواد والخدمات المهيأة التي ليس لها ضرورة لمتوسط أجزاء التطبيق. من الأفضل كثيرا لك أن تبدأ بالوتيرة التي يمكنك التعامل معها، وأن تتجنب التعقيد، وأن تستخدم أكبر قدر ممكن من الأدوات الجاهزة.

البرامج التعليمية: بناء مهارات الخدمات المصغرة

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

الخدمات المصغرة وIBM Cloud

تتيح الخدمات المصغرة التطوير الابتكاري بالسرعة المناسبة لمجال الأعمال الحديثة. تعرّف على كيفية الاستفادة من قابلية التطوير ومن المرونة في البيئة السحابية من خلال نشر خدمات مستقلة من الخدمات المصغرة في بيئات التشغيل السحابية. اكتشف كيف سيبدو الأمر بعد تحديث التطبيقات الخاصة بك بالمساعدة المقدمة من IBM.

اتخذ الخطوة التالية:

  • وفر الوقت لفرق التطوير لديك بالاعتماد على التكرار الآلي بمساعدة أدوات التطوير السحابية المحلية في IBM Cloud.
  • تعرّف على المزيد عن Kubernetes المدارة من خلال البدء باستخدام Red Hat OpenShift on IBM Cloud أو IBM Cloud Kubernetes Service. أيضا، يمكنك الاطلاع على IBM Cloud Code Engine لمزيد من المعلومات عن الحوسبة بدون وحدة خدمة.
  • تتعلق الخدمات المصغرة بعمليات الفرق وتنظيمها تماما بقدر ما تتعلق بالتكنولوجيا. ضع الخطة الاستراتيجية لمنهج DevOps الخاص بك بالمساعدة المقدمة من IBM DevOps.

البدء باستخدام حساب IBM Cloud اليوم.