المونوليثات المعيارية تحل محل الخدمات المصغّرة في فرق الهندسة متوسطة الحجم

طوال معظم العقد الماضي، كان تفكيك التطبيق إلى خدمات مصغّرة يُعتبر التصرف المسؤول الذي يقوم به المطورون حين يصبح التوسع أمراً جدياً. في عام 2026، يعكس عدد متزايد من فرق الهندسة هذا القرار بهدوء، لا بالتخلي عن حدود الخدمات، بل بدمجها مجدداً في وحدة نشر واحدة مع فصل داخلي صارم: المونوليث المعياري.
يبقى المثال العام الأوضح فريق Prime Video التابع لأمازون، الذي نقل في 2023 خدمة تحليل جودة الفيديو من خط أنابيب موزّع يعتمد على Lambda والخدمات المصغّرة إلى عملية مونوليثية واحدة. أفاد الفريق بانخفاض تكلفة البنية التحتية لتلك الخدمة بنحو 90٪، إلى جانب تبسيط كبير في عملية تتبّع الأخطاء.
لماذا عاد البندول إلى الخلف
تحل الخدمات المصغّرة مشكلة محددة: إمكانية النشر والتوسع المستقلين لفرق كبيرة بما يكفي بحيث تتحول قاعدة الكود المشتركة إلى عنق زجاجة تنسيقي. بالنسبة لمؤسسة هندسية من 200 شخص مقسّمة إلى عشرات الفرق المستقلة، هذه المقايضة منطقية. لكن لفريق من 15 شخصاً يشغّل 40 خدمة مصغّرة، يلتهم العبء التشغيلي الفائدة المفترضة.
صرّحت كل من Basecamp وShopify علناً بالبقاء في نموذج «المونوليث الفخم» أو العودة إليه، بدلاً من الانقسام إلى عشرات الخدمات، لنفس السبب: معظم مسارات طلباتهما لا تحتاج إلى توسع مستقل.
كيف يبدو المونوليث المعياري فعلياً
المونوليث المعياري ليس «الاستسلام وكتابة كود متشابك في ملف واحد». إنه تطبيق واحد قابل للنشر منظّم داخلياً في حزم أو وحدات ذات حدود صريحة ومفروضة، غالباً وحدة واحدة لكل مجال أعمال (الفوترة، المخزون، الإشعارات). تملك كل وحدة طبقة الوصول إلى بياناتها الخاصة وتعرض واجهة داخلية ضيقة للوحدات الأخرى.
هذا يمنحك معظم الفوائد التي كان الناس يسعون إليها أصلاً من الخدمات المصغّرة، دون ضريبة الأنظمة الموزّعة: لا كمون شبكي بين الوحدات، لا معالجة فشل جزئي لاستدعاءات كانت سابقاً استدعاءات دوال.
حين تظل الخدمات المصغّرة تستحق تكلفتها
الحجة الصادقة للخدمات المصغّرة لا تزال قائمة. إذا احتاج مكوّن واحد إلى التوسع بشكل مستقل بمعدل 50 مرة مقارنة ببقية النظام، فإن فصله هو القرار الصحيح. القاعدة العملية التي ظهرت بين الفرق في 2026: اجعل الافتراضي هو المونوليث المعياري، ولا تستخرج خدمة إلا إذا استطعت تسمية حاجة توسع أو لغة أو استقلالية فريق محددة تبرر ذلك.
خلاصة للفرق التي تعيد النظر في بنيتها
إذا كان فريقك يضم نحو 50 مهندساً أو أقل ويشغّل أكثر من حفنة خدمات، راجع أي الخدمات تحتاج فعلاً إلى توسع مستقل مقابل أيها انقسم لأسباب تنظيمية لم تعد قائمة. حافظ على حدود الوحدات؛ تخلّص من القفزات الشبكية.