بالطريقة التقليدية تنفيذ برمجة المشاريع التقنية (موقع أو تطبيق ولوحة تحكم) لمشروع ما مثل متجر إلكتروني، خدمة حكومية، تطبيق لشركة ناشئة… يتم من خلال تطوير المشروع بلغة برمجة يتقنها الفريق فينطلق المشروع صغيراً ثم يبدأ يتوسع بإضافة المزايا على نفس المشروع المبني والمنشور وقد يتم تطوير لوحة التحكم وتطوير API كذلك على نفس المشروع الذي تم بناءه كمشروع واحد ويتم الاتصال بقاعدة البيانات بشكل مباشر، مثلاً إنشاء مشروع متجر إلكتروني بلغة برمجة محددة ويحتوي على كل مزايا المتجر الإلكتروني عضويات، منتجات، سلة مشتريات، كوبونات، دفع، مبيعات… وكل ميزة يتم تطويرها (في نفس المشروع) كميزة إضافية Module أو Plugin مثلاً إضافة ميزة قائمة الأمنيات، وكل عضو بذلك سيقوم بتطوير أي ميزة على (نفس المشروع المنُفَذ كاملاً)، والأمور تسير بشكل جيد بدون Microservices صحيح؟ المشكلة هي عندما يكبر حجم المشروع تأتي المعوقات وتزداد خصوصاً أن المشروع يظل عبارة عن نظام ككتلة واحدة والتعامل معه في السيرفر على هذا الأساس، والخيار الآخر هو بناء API كنظام مستقل وتوفير احتياجات اي نظام آخر بالاتصال بالـ API سواءً موقع أو تطبيق أو لوحة التحكم أو أي نظام آخر يعتمد على Frontend ويتصل بالنظام في الـ Backend عبر API حتى وإن كان عميل، أمر جميل ولكن لا يزال النظام عبارة عن نظام تقليدي للتطوير ولا يصل للمزايا الخاصة بالتطوير باستخدام Microservices والتي سنذكرها في هذه المقالة …

ما تسعى له الشركات هو طرق أداء و نتائج (أفضل) وذلك ما يقدمه لنا Microservices Architecture فإن مع قوة فريق التطوير في المجال التقني إلا انه يجب أن يتم استخدام الطرق الأنسب للتطوير وذلك لتساهم بنجاح المشاريع التقنية بشكل أكبر في الشركات الناشئة أو غير الناشئة فأي مشروع تقني مهم الأخذ في الاعتبار Microservices لما لها من أهمية في تحسين التطوير والحصول على نتائج أفضل والنشر وتقليل المشاكل مقارنة بالطريقة التقليدية، وسنوضح كل ذلك الأن…

ولا يهمك … باختصار Microservices كتعريف أساسي عبارة عن هيكلة بناء Architecture بنمط محدد Pattern لتطوير فكرة برنامج (خدمة) بدلاً من انشاء مشروع برمجي واحد يتم تقسيمه بإنشاء عدة مشاريع برمجية وكل مشروع عبارة عن جزء (خدمة مصغرة) من كامل فكرة البرنامج، ويتم التواصل من قبل بعضها البعض باستخدام API والتي تكون بطريقة REST عادةً … وبذلك يمكن العمل على كل خدمة مصغرة وبنائها واختبارها وتطويرها ونشرها وتوسيع نطاقها كمشروع مستقل.

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

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

توضيح أكثر من خلال Git: كل خدمة مصغرة من المشروع عبارة عن Repo مستقل في Git ولا يتم اضافة الخدمات المصغرة في مشروع واحد مشترك لكن يتم التواصل بكل خدمة مع الخدمات المرتبطة بها من خلال API.

توضيح أكثر من خلال السيرفر: كل خدمة مصغرة عبارة عن موقع مستقل في السيرفر يمكن بذلك يكون كل خدمة مصغرة بسيرفر مختلف والتحكم بمواصفاته وعمل Scale لوحده حسب الحاجة.

توضيح أكثر بالصورة:

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