خرافة الخدمات المصغرة: لماذا لا تتعلق التقنية بالخدمات بل بهيكلية فريقك؟

مقدمة تحليلية

في أروقة شركات التقنية الكبرى والناشئة على حد سواء، يتكرر مشهد كلاسيكي في غرف الاجتماعات: مهندس يصرخ بأن الانتقال إلى نظام الخدمات المصغرة (Microservices) هو السبيل الوحيد للتوسع (Scaling)، بينما يرد آخر بمرارة بأن تجربته السابقة معها كانت كارثة تقنية محققة. في الواقع، كلاهما يخطئ في تشخيص المشكلة؛ فهما يعتقدان أن الجدال يدور حول بنية النظام (Architecture)، بينما الحقيقة هي أن النقاش يتمحور حول 'قانون كونواي' (Conway's Law) الذي لم يلحظه أحد منهما بعد. إن هذا الصراع الأزلي ليس مجرد تفضيل تقني، بل هو انعكاس لكيفية تواصل البشر داخل المؤسسة قبل أن يكون انعكاساً لكيفية تواصل الخوادم.

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

التحليل التقني

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

خطر 'الـ Monolith الموزع'

إذا كانت خدماتك تتشارك قاعدة بيانات واحدة، أو تضطر لنشرها معاً ككتلة واحدة، أو إذا أدى تغيير في خدمة 'أ' إلى ضرورة تغيير خدمة 'ب' فوراً؛ فأنت لا تمتلك Microservices. ما تملكه هو 'Monolith موزع' (Distributed Monolith)، وهو أسوأ سيناريو ممكن في هندسة البرمجيات. في هذه الحالة، أنت تدفع 'ضريبة الأنظمة الموزعة' (مثل تعقيد الشبكة، وتأخر الاستجابة، وفشل الاتصال) دون الحصول على أي من فوائد الاستقلالية. الاستفسار الحقيقي هنا ليس 'هل نريد خدمات صغيرة؟' بل 'هل تحتاج فرقنا حقاً للشحن بشكل مستقل؟'.

قانون كونواي والهيكلية التنظيمية

يقول ملفين كونواي (1968): 'أي منظمة تصمم نظاماً ستنتج تصميماً يمثل نسخة من هيكل اتصالاتها'. معمارية نظامك هي صورة فوتوغرافية لمخططك التنظيمي. لا يمكنك الهروب من هذا الواقع؛ فإذا كنت تريد خدمات مستقلة، يجب أن تمتلك فرقاً مستقلة أولاً. كل عملية هجرة ناجحة للخدمات المصغرة سمعت عنها كانت في جوهرها عملية إعادة هيكلة للمؤسسة متنكرة في زي تقني.

رياضيات الفشل: الكمون عند النطاق (Tail at Scale)

هناك معضلة رياضية يغفل عنها الكثيرون. لنفترض أن لكل نداء خدمة فرعي فرصة 99% ليكون سريعاً. عندما يتوزع طلب مستخدم واحد على 100 خدمة (Fanout)، فإن احتمالية أن يكون طلب واحد على الأقل بطيئاً تتبع المعادلة: P(slow) = 1 - (0.99)^N.

• عندما N=10 تكون الاحتمالية 10%
• عندما N=100 تقفز الاحتمالية إلى 63%
• عندما N=1000 تصل الاحتمالية تقريباً إلى 100%

هذا يعني أن ثلثي طلبات المستخدمين ستواجه بطئاً ليس لأن هناك خللاً، بل لأن الاحتمالية تتوسع مع تشعب النظام. استدعاءات الوظائف داخل البرنامج الواحد (In-process calls) سريعة، لكن الشبكة تضاعف التباين في كل قفزة.

السياق وتأثير السوق

تاريخياً، أدركت أمازون في عام 2002 أن النظام الموحد لا يمكنه دعم وتيرة نموها، فأصدر جيف بيزوس مرسوماً يقضي بمنع تواصل الفرق إلا عبر واجهات برمجية (APIs) خارجية. كانت النتيجة ولادة AWS كنموذج عمل، ووصول وتيرة النشر إلى مرة كل 11 ثانية تقريباً. لكن هذا النجاح دفع الشركات الصغيرة لتقليد 'النتيجة' (الخدمات المصغرة) دون امتلاك 'السبب' (الحجم التنظيمي الهائل).

في المقابل، نجد شركات عملاقة مثل Shopify تدير نظام Rails موحداً (Modular Monolith) يتعامل مع 30 تيرابايت من البيانات في الدقيقة وقت الذروة، بينما يخدم Stack Overflow أكثر من 200 مليون طلب يومياً عبر 11 خادماً فقط. هذه الشركات لم تفشل في 'التخرج' إلى الخدمات المصغرة، بل قررت بذكاء أنها لا تملك المشكلة التنظيمية التي تستدعي دفع تكلفة التعقيد الموزع.

رؤية Glitch4Techs

في Glitch4Techs، نرى أن الخدمات المصغرة هي حل لمشكلة توسيع نطاق الفريق (Team Scaling) أكثر منها حلاً لمشكلة توسيع نطاق التقنية (Tech Scaling). هي أداة لإدارة الفوضى البشرية عبر فك الارتباط بين الفرق. إذا كان فريقك يتكون من أقل من 15 مهندساً يعملون على كود برمي واحد، فإن الانتقال للخدمات المصغرة هو 'انتحار تقني' بطيء.

نصيحتنا لكل قائد تقني: ابدأ بـ Monolith منظم جيداً (Modular Monolith). وكما قال مارتن فاولر: 'كل قصص نجاح الخدمات المصغرة بدأت بنظام موحد أصبح كبيراً جداً'. لا تبنِ المعمارية التي تتمنى أن يمتلكها فريقك المستقبلي، بل ابنِ المعمارية التي تناسب الفريق الذي تملكه اليوم. إذا كانت إجابتك بـ 'لا' على سؤال: 'هل الفرق تحتاج حقاً لنشر الكود بوتيرة مختلفة تماماً؟'، فابقَ على النظام الموحد ووفر ميزانيتك وجهدك لما يهم المستخدم حقاً.