متى تكون هندسة الخدمات المُصغرة تستحق العناء؟

متى تكون هندسة الخدمات المُصغرة تستحق العناء؟

إن بنية الخدمات المُصغرة عُبارة عن إطار عمل يتم فيه فصل التطبيق إلى خدمات أصغر 

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

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

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

فيُمكن تخصيص المزيد من الموارد لها بكفاءة.
- إذا اِنخفض الطلب مع تغير الموسم، فيُمكن تقليص الخدمة الصغيرة مما يسمح 

باِستخدام الموارد أو قوة الحوسبة في مناطق أُخرى.
- وخلال مقال (متى تكون هندسة الخدمات المُصغرة تستحق العناء؟)

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

أولاً: ما هي الخدمات المصغرة؟

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

الخدمات المُصغرة "Microservice" هي خدمة صغيرة وموزعة بشكل فضفاض.
- تطورت بنية الخدمات الصغيرة كحل لتحديات قابلية التوسع والنشر بشكل مُستقل والاِبتكار 

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

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

وغير مُناسب في ظروف أُخرى.

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

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

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

أو لغات جديدة أو التحديث إلى إصدارات جديدة من الأنظمة الحالية أو اِعتماد بروتوكولات جديدة 

يعني تغيير أجزاء مُتعددة من الخدمات الصغيرة بدلاً من قاعدة تعليمات برمجية واحدة.

لكي نكون واضحين يُمكن حل هذه العيوب بسهولة تامة ولكن القيام بذلك يتطلب طبقة إدارة 

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

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

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

مع مسؤوليات مُحددة بشكل ضيق ويُعتبر لبنة بناء التطبيقات الحديثة.
- يُمكن كتابة الخدمات المصغرة بمجموعة متنوعة من لغات البرمجة والأطر 

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

ثانيًا: متى تكون الخدمات الصغيرة منطقية؟

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

ثالثًا: فوائد الخدمات المُصغرة

الوحدات الصغيرة: يتم تقسيم التطبيق إلى وحدات أصغر يسهل على المطورين ترميزها وصيانتها.
تكيف أسهل للعمليات: باِستخدام الخدمات الصغيرة، يُصبح التكيف مع التكنولوجيا والعمليات الجديدة أسهل.
يُمكنك تجربة تقنيات جديدة مع الخدمات الصغيرة الأحدث التي نستخدمها.
إزالة التبعية: تعمل الخدمة الصغيرة على التخلص من الاِلتزام طويل الأمد تجاه أي مجموعة تكنولوجية مُنفردة.
غير متأثر: تظل التطبيقات الكبيرة غير متأثرة إلى حد كبير بفشل وحدة واحدة.
DURS: يُمكن أن تكون كل خدمة DURS بشكل مُستقل (نشرها وتحديثها واستبدالها وتوسيع نطاقها).
زيادة الأمان: تُتيح الخدمات الصغيرة فصل البيانات.
تحتوي كل خدمة على قاعدة بيانات خاصة بها، مما يجعل من الصعب على المُتسللين اِختراق تطبيقك.
المعايير المفتوحة: تُمكن واجهات برمجة التطبيقات (APIs) المطورين من بناء خدماتهم الصغيرة 

باِستخدام لغة البرمجة والتكنولوجيا التي يفضلونها.

رابعًا: حدود الخدمات إستخدام المُصغرة

أصبحت الخدمات المُصغرة إلى حد ما بمثابة الدواء الشافي لجميع مشاكل تطوير البرمجيات

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

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

خامسًا: عيوب الخدمات المُصغرة

في حين أن هُناك عددًا كبيرًا من المزايا لأي عمل تُجاري 

إلا أن هُناك أيضًا بعض عيوب الخدمات الصغيرة التي يجب مُراعاتها قبل اِعتمادها:
1) التكاليف الأولية أعلى مع الخدمات الصغيرة

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

2) التحكم في الواجهة أمر بالغ الأهمية

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

3) نوع مُختلف من التعقيد

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

4) اِختبار التكامل

• يُعد اِختبار الوحدة أكثر قابلية للإدارة باِستخدام بنية الخدمات الصغيرة.
• اِختبار التكامل ليس كذلك؛ نظرًا لأن البنية توزع كل خدمة صغيرة فلا يُمكن للمطورين اِختبار النظام بأكمله من أجهزتهم.

سادسًا: أمثلة على الخدمات المُصغرة

شهدت المؤسسات تغييرًا هائلاً أثناء اِستخدام الخدمات الصغيرة في تطبيقاتها وهُنا جاء التحول 

من الخدمة المُتجانسة إلى الخدمة الصغيرة.
*يُمكنك الاِطلاع على بعض الأمثلة الواقعية في التطبيقات التي تستخدم الخدمات المُصغرة وهي:

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

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

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

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

وخِـتامًا,,,,, الخدمات المُصغرة هي طريقة معمارية لتطوير البرمجيات 

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