متى تنفصل عن الأحادية (Monolith)؟ قرار الخدمات المصغّرة بلا مبالغة
تراجعت شركات كبرى عن الخدمات المصغّرة، فالقرار ليس موضة بل مقايضة. دليل متوازن بمعايير قرار حقيقية: متى تنفصل فعلًا، الأحادية النمطية كوسط ذهبيّ، والفخاخ التي تُفسد القرار.
في 2023، كان السؤال «متى ننتقل إلى الخدمات المصغّرة؟» يبدو بديهيًّا، وكأن الأحادية (Monolith) عارٌ هندسيّ يجب التخلّص منه. لكنّ شيئًا لافتًا حدث منذ ذلك الحين: بدأت شركات كبرى تتراجع. فريق Amazon Prime Video دمج نظام مراقبة قائمًا على الخدمات المصغّرة في تصميم أحاديّ، فخفض تكاليف البنية التحتية بأكثر من 90%. وشركة Segment قسّمت نظامها إلى أكثر من خمسين خدمة مبكّرًا، ثم عادت لتوحيد مساراتها الحرجة في أحادية بحثًا عن البساطة. أمّا Auth0 فتراجعت جزئيًّا إلى الأحادية بعد أن تجاوز العبء التشغيليّ المكاسب. هذه ليست حكايات فشل، بل دروس نضج: القرار المعماريّ ليس موضةً تُتّبع، بل مقايضةً تُحسَب.
لماذا هذا القرار أصعب ممّا يبدو؟
الخطأ الجوهريّ أن كثيرين يعاملون «الأحادية مقابل الخدمات المصغّرة» كخيار تقنيّ، بينما هو في جوهره قرار تنظيميّ وتجاريّ يؤثّر على ميزانيتك وسرعة فريقك ومسار منتجك لسنوات. الخدمات المصغّرة لا تحلّ مشكلة تقنية بالأساس؛ إنها توزّع التعقيد التنظيميّ ليتوسّع أداء الهندسة عبر فرق كثيرة. فإن لم تكن لديك هذه المشكلة التنظيمية، فأنت تدفع «ضريبة تشغيلية» مقابل لا شيء.
الوسط الذهبيّ: الأحادية النمطية (Modular Monolith)
قبل أن نناقش «متى تنفصل»، يجب كسر الثنائية الزائفة. فالخيار ليس «فوضى أحادية» مقابل «خدمات مصغّرة نظيفة». الخيار الافتراضيّ الأنضج في 2026 هو «الأحادية النمطية»: وحدة نشر واحدة، لكن داخلها حدودٌ صارمة بين الوحدات (Modules)، بواجهات صريحة، ودون وصول متقاطع لقواعد البيانات بين الوحدات. كل وحدة (الطلبات، المدفوعات، المستخدمون) تعرف ما تملكه وما لا تملكه. هذا النمط يمنحك 80% من وضوح الخدمات المصغّرة دون تعقيدها التشغيليّ، والأهمّ أنه يحفظ خيار «الاستخراج» لاحقًا عند الحاجة الفعلية.
وهنا النقطة التي يغفلها كثيرون: القيمة الحقيقية ليست في «كيف تنشر» بل في «كيف تقسّم منطقك». الفصل المنطقيّ (Logical) الجيّد أهمّ من الفصل الفيزيائيّ (Physical). ومن يقسّم فيزيائيًّا دون فصل منطقيّ سليم، ينتهي بأسوأ العالمَين: «أحادية موزّعة» (Distributed Monolith) بأقصى تعقيد وأدنى فائدة.
معايير القرار: متى تنفصل فعلًا؟
إليك الإشارات الحقيقية التي تبرّر الانفصال، وكلّها تنظيمية أو متعلّقة بمتطلّبات صارمة، لا مجرّد «تفضيل تقنيّ»:
حجم الفريق. الخدمات المصغّرة تبدأ في دفع ثمنها حين يتجاوز فريقك الهندسيّ نحو 20 إلى 30 مهندسًا. تحت هذا العدد، تضيف تنسيقًا زائدًا دون أن يعوّض نفسه. الفرق الأصغر من عشرة مهندسين يجب أن تبقى في أحادية نمطية منظّمة.
اختلاف وتيرة النشر. إذا كانت أجزاء نظامك تحتاج إيقاعات نشر مختلفة جذريًّا (صفحة الدفع تُنشَر يوميًّا، والفوترة فصليًّا)، فهذا مبرّر حقيقيّ للفصل. أمّا إن كانت كلها تُنشَر بالإيقاع نفسه، فلا تحتاج الفصل المعماريّ.
عزل الأعطال. حين يكون سقوط جزء يجب فعلًا ألّا يُسقط البقية (المدفوعات، البحث، التوصيات)، تتفوّق الخدمات المصغّرة. فإن لم يكن لمجالك متطلّب عزل صارم، فأنت تدفع الضريبة بلا مقابل.
اختلاف احتياجات التوسّع. إن كان لجزء احتياج توسّع مختلف جوهريًّا (خطّ معالجة فيديو يحتاج معالجات رسومية GPU لا يجب أن يشارك بنية واجهة REST بسيطة)، فالتوسّع المستقلّ يعطي قيمة حقيقية في الكلفة والموثوقية.
الفخاخ التي تُفسد القرار
ثلاثة أخطاء تتكرّر وتُفشل أيّ مقاربة. الأوّل: «لأن Netflix تفعلها». إن كان هذا مبرّرك الأساسيّ، توقّف؛ فحجم Netflix شبه مؤكّد لا يطابق حجمك. الثاني: الفصل الفيزيائيّ دون حدود منطقية. حين تنشر خدمات تتشارك قاعدة بيانات، أو بينها اعتماديات دائرية، أو تتطلّب إصدارات منسّقة، فقد صنعت «أحادية موزّعة» — كارثة التعقيد الأقصى بلا فائدة. الثالث، والأخطر: ظنّ أن الخدمات المصغّرة تحلّ الدَّين التقنيّ. إن كانت مشكلتك ديونًا تقنية، فالخدمات المصغّرة ستضخّمها لا تحلّها؛ لأنك توزّع الفوضى على الشبكة بدل احتوائها في مكان واحد.
عامل جديد في 2026: أدوات الذكاء الاصطناعي
ظهر مؤخّرًا اعتبار لم يكن موجودًا قبل ثلاث سنوات، وله وجهان. من جهة، تعمل مساعدات البرمجة بالذكاء الاصطناعي (كـ Copilot وCursor) بكفاءة أعلى داخل خدمة واحدة محدودة النطاق بعقد واجهة واضح، مقارنةً بالتنقّل في أحادية ضخمة بتبعيّات ضمنية — حجّة جديدة نسبيًّا للفصل. من جهة أخرى، جعلت «منصّات المطوّرين الداخلية» (كـ Backstage وPort) إدارة الخدمات المصغّرة في متناول فرق أصغر، إذ يستطيع فريق منصّة من شخصين إدارة معمارية من عشرين خدمة. هذان العاملان يخفّضان تكلفة الفصل، لكنهما لا يلغيان قاعدة أنه يجب أن يكون مبرّرًا بحاجة حقيقية.
المسار العمليّ: ابدأ صغيرًا، وانفصل بالتدريج
الإجماع في 2026 واضح: ابدأ بأحادية نمطية مبنية بحيث يمكن تقسيمها لاحقًا. فالانفصال منها مهاجرةٌ معروفة ومدعومة بالأدوات حين يبرّرها الإيراد وحجم الفريق. أمّا العكس — طيّ خدمات مصغّرة أفرطتَ في هندستها إلى أحادية حين تكتشف الخطأ — فأصعب بكثير. وحين تنفصل فعلًا، لا تُعِد كتابة كل شيء دفعةً واحدة؛ استخدم نمط «شجرة الخنق» (Strangler Fig): ابنِ القدرات الجديدة كخدمات مستقلّة، واستخرج وظائف الأحادية القائمة تدريجيًّا عبر 12 إلى 18 شهرًا، دون «انفجار كبير» محفوف بالمخاطر.
القاعدة العملية التي تختصر كل ما سبق: لا تسأل «أحادية أم خدمات مصغّرة؟» بل «ما المشكلة التنظيمية أو التقنية المحدّدة التي أحاول حلّها؟». إن لم تستطع تسمية مشكلة حقيقية — فريق تجاوز الثلاثين، أو جزء يحتاج عزلًا أو توسّعًا مستقلًّا فعليًّا — فالأرجح أنك لا تحتاج الخدمات المصغّرة بعد. أنجح الأنظمة ليست الأكثر تطوّرًا معماريًّا، بل التي أضافت التعقيد فقط حين استحقّته. ابدأ بسيطًا، احفظ حدودك نظيفة، وانفصل حين تجبرك الحقائق لا الموضة.
هل وجدت هذا المقال مفيدًا؟