حين يأتيني عميل يقول "ننتقل إلى خدمات مصغرة"، أول سؤال أطرحه عليه: لماذا؟ الإجابة الحقيقية — وليس الإجابة التي يتوقع الناس أن يسمعوها — تخبرني كل شيء عما إذا كان هذا قراراً صحيحاً أم لا.
النظام الموحد ليس جريمة
دعني أكون واضحاً من البداية: نظام موحد بناء بشكل جيد قادر على خدمة ملايين المستخدمين. عندما تأتيك شركة كبيرة جداً في الخليج — مصرف، شركة لوجستيات، مشغل شبكة — يعملون على نظام موحد كتب منذ 10 سنوات، وهو يعمل. المشكلة ليست النظام الموحد. المشكلة أن الناس تخلط بين "مبروم والنظام يعمل" و"هذا هو السبيل الوحيد للنمو".
من تجربتي في قيادة مشاريع في الكويت والخليج: 85% من الشركات التي تقول "نريد microservices" لا تعاني من المشاكل التي تحلها microservices. تعاني من مشاكل أخرى تماماً: فريق ضعيف، اتصالات سيئة بين المبرمجين، أو ببساطة — لم تقرر بعد كيف تريد منتجك أن يبدو.
الانتقال إلى microservices لن يحل أياً من هذه. في الحقيقة، سيجعلها أسوأ.
متى تقول: ابقَ مع النظام الموحد
إذا كنت في أي من هذه الحالات، فأنت لا تحتاج إلى خدمات مصغرة:
- فريقك أصغر من 20 مبرمج. microservices تُضيف تعقيداً عندما تكون الفرق صغيرة — كل فريق صغير يملك خدمة واحدة، والاتصالات بينهم تصبح أم المشاكل.
- لم تصل بعد إلى million user، ولا توقعاتك أن تصل السنة القادمة. النظام الموحد يستطيع تخديم 10 ملايين user بلا أي مشكلة إذا كان النموذج صحيح.
- أجزاء نظامك مترابطة جداً — التطبيق، قاعدة البيانات، خدمات الدفع، كل شيء يعتمد على بعضه. في هذه الحالة، فكك النظام أولاً على الورقة، ثم فكره في التطبيق.
- لا توجد "المشاكل" بعد. يعني النظام يحمل التطبيق. الفريق يستطيع رشم الميزات. الأداء مقبول. أنت تبحث عن مشاكل لم تحدث بعد.
الحقيقة المُرة: إذا قلت "كل شيء يعمل الآن، لكننا نريد أن نستعد للمستقبل"، فأنت في طريق خطير. البرمجيات لا تُبنى "للمستقبل المحتمل". تُبنى "للحاضر الفعلي، بمرونة كافية تسمح بالتطور بسرعة".
الخطأ الذي رأيته يغرق المشاريع
شركة استثمرت 80,000 دينار في نقل نظام يخدم 500,000 مستخدم إلى microservices. الغرض: "تحسين الأداء والمرونة". المشكلة الحقيقية كانت قاعدة البيانات — لم تكن محسّنة. بعد 8 أشهر، اكتشفوا أن المشكلة في SQL queries، وليس في الهندسة. كان يمكنهم حلها في شهر واحد مع DBA متخصص. microservices لم تحل شيئاً — أضافت تعقيد جديد.
العلامات التحذيرية الحقيقية
لكن هناك نقطة تأتي حينها تقول: "نعم، وقت الانتقال". ما هي هذه النقطة؟
الأول: الفريق محشور. ثلاثة فرق تعمل على نفس النظام الموحد. كل فريق يريد أن يرشم ميزات مختلفة بسرعات مختلفة. ملايين conflicts في الـ git. الـ deployment يأخذ ساعات لأنك تنتظر فريق X ينهي، ثم يأتي دور فريق Y. البيئة الإنتاجية متوقفة مرة أسبوع لأن أحداً حطم شيء غير متوقع.
الثاني: بعض أجزاء النظام بطيء جداً. وليس كل النظام — جزء معين. مثلاً، محرك البحث يحتاج 8 ثوان للرد لأنه يقرأ من نفس قاعدة البيانات التي تكتب عليها الـ 50 عملية أخرى كل ثانية. النظام الموحد يعني أن جميع العمليات تتنافس على نفس الموارد. هنا، عزل هذا الجزء يساعد فعلاً.
الثالث: تريد معايير deployment مختلفة. أحد الفرق ينشر تحديثات 10 مرات يومياً. فريق آخر ينشر مرة أسبوع. فريق ثالث يريد rollback فوري لأن عملاءهم اللوجستيون لا يسامحون الأخطاء. النظام الموحد يعني deployment واحد لكل شيء. إما كل شيء ينشر معاً، أو لا أحد ينشر.
الرابع: لديك فرق موزعة جغرافياً تعمل على أجزاء مختلفة تماماً. عندك فريق في الكويت يعمل على الواجهة الأمامية والدفع. فريق في الإمارات على الـ logistics. فريق في السعودية على السوشيال. كل فريق يريد أن يملك حجر نهايته — أن يطور، يطبّق، ينشر، بلا انتظار أحد.
إذا كنت في حالة واحدة من هذه — ليس كل الأربع، واحدة — فأنت تقترب من نقطة الانتقال.
التكلفة الحقيقية للانتقال
كل عميل يسألني "كم يكلف؟" أجيب: أولاً، كم يكلفك الآن أن تكون عالقاً؟
لكن دعني أعطيك الأرقام:
| المرحلة | المدة الزمنية | التكلفة (تقريبي) | ماذا يحدث |
|---|---|---|---|
| التصميم والتخطيط | 2-3 أسابيع | 3,000-5,000 د.ك | فصل الخدمات، تخطيط قواعد البيانات، رسم الاتصالات |
| بناء البنية الأساسية | 3-4 أسابيع | 5,000-8,000 د.ك | Docker، Kubernetes أو ما شابه، service discovery، logging |
| نقل الخدمات الأولى | 4-6 أسابيع | 8,000-12,000 د.ك | اختبار، مراقبة، تصحيح الأخطاء تحت الضغط |
| كل خدمة إضافية | 1-2 أسابيع | 2,000-3,500 د.ك | تناقص المجهود كلما تكررت العملية |
| التدريب والتوثيق | 1-2 أسابيع | 2,000-4,000 د.ك | فريقك يستطيع الآن أن يعيش مع هذا |
الإجمالي: 20,000-35,000 دينار كويتي، و4-8 أشهر، بفريق من 4-5 مهندسين. إذا أضفت أن الإنتاجية تنخفض بـ 30-40% خلال هذه الفترة — لأن الفريق مشغول بالهندسة ولا يطور ميزات جديدة — فأنت تُضيف 10,000-15,000 دينار آخر من "التكلفة المخفية".
قبل أن تبدأ، اسأل: إذا صرفت هذه الـ 35,000 دينار على تحسينات مباشرة للمنتج، ماذا كان ممكن أحقق؟ إذا كانت الإجابة "أكثر من فوائد microservices"، فلا تفعل.
الأداء والمراقبة — التفاصيل التي تحطم المشاريع
عندما تنقسم خدماتك، كل منها يجب أن تراقب بشكل منفصل. latency بين الخدمات يصبح مشكلة فعلية. إذا كانت خدمتك A تنادي الخدمة B التي تنادي الخدمة C، وكل واحدة تأخذ 200 ميلي ثانية، فطلب واحد أصبح 600 ميلي ثانية. في النظام الموحد، كان 50 ميلي ثانية. رأيت هذا يفاجئ الناس.
كيف تقرر فعلاً
هنا الخطوات العملية:
شهر 1: افهم المشكلة الفعلية
لا تقول "نريد microservices" — قل بالضبط ما يؤلمك. هل الـ deployment بطيء؟ قس الوقت. هل الفريق محشور؟ عدّ عدد merge conflicts. اكتشف الرقم. بلا رقم، أنت تخمن.
شهر 2: احسب الفائدة بدقة
إذا كانت مشكلتك "الـ deployment يأخذ ساعتين"، كم مرة تنشر شهرياً؟ إذا 30 مرة، كم ساعة ستوفر فعلاً؟ microservices قد تقلل هذا إلى 15 دقيقة لكل خدمة — لكن 80% من وقتك سيذهب في testing، وليس في الـ deployment. الفائدة الحقيقية قد تكون 30%، وليس 80%.
شهر 3: استكشف البدائل
قبل أن تنقسم إلى microservices، جرب: modular monolith (نظام موحد بهندسة نظيفة)، أو حتى فقط تحسين processes الفريق. أحياناً المشكلة ليست الكود، المشكلة كيف يتواصل الفريق.
شهر 4: جرب على مشروع صغير
لا تنقل كل شيء دفعة واحدة. اختر خدمة صغيرة — مثلاً، خدمة الإشعارات أو الـ image processing — وجرب معها. هل العمل أسهل؟ أم أعقد؟ كم استغرق؟ البيانات من مشروع حقيقي أفضل بكثير من التوقعات.
صراحةً، الكثير من الشركات الكويتية والخليجية لن تحتاج microservices أبداً. وهذا بخير تماماً. النموذج الموحد النظيف يكفي لخدمة ملايين المستخدمين إذا كان بناؤه صحيحاً.
لكن إذا وصلت إلى نقطة حيث علامات التحذير الحقيقية ظاهرة — الفريق محشور، deployment مكلف، أجزاء من النظام معزولة — عندها microservices ليست رفاهية، إنها ضرورة. وعندها فقط.
الخطأ الأخير أريد أن أحذرك منه: لا تستعجل الانتقال لأن "كل شركة كبيرة تستخدم microservices". غوغل وفيسبوك وأمازون تستخدمونها لأنهم يخدمون مليارات المستخدمين. أنت تخدم آلاف أو ملايين. الهندسة المطلوبة مختلفة تماماً.
ابدأ بنظام موحد بناء بشكل نظيف. لما تشعر بالألم الحقيقي — وليس الألم المتخيل — عندها تنقسم. الوقت الصحيح مختلف لكل شركة.