لماذا عدنا إلى استخدام الـ Modular Monolith

تغير فرق البرمجيات استراتيجيتها. قضت العديد من الفرق سنوات في تقسيم التطبيقات إلى microservices. والآن، يعيدون تجميع الأجزاء معاً. إنهم لا يبنون monoliths قديمة وفوضوية، بل يبنون modular monoliths.

تخلق الـ microservices تكاليف خفية. وتضيف الأنظمة الموزعة (distributed systems) تعقيداً هائلاً. تتبنى العديد من الفرق الـ microservices بسبب الضجيج الإعلامي (hype)، وليس لأنها بحاجة إلى هذا النطاق (scale). إذا كان لديك فريق صغير، فقد تؤدي الـ microservices إلى إبطاء وتيرة عملك.

يمنحك الـ modular monolith أفضل ما في العالمين. فهو يظل وحدة واحدة قابلة للنشر (deployable unit)، ولكن الكود منظم في وحدات (modules) صارمة. ستحصل على حدود واضحة دون التكلفة العالية لتشغيل نظام موزع.

قارن بين النهجين:

• النشر (Deployment): تستخدم الـ monoliths وحدة واحدة، بينما تستخدم الـ microservices وحدات عديدة. • الحدود (Boundaries): تستخدم الـ monoliths قواعد كود صارمة، بينما تستخدم الـ microservices الشبكة. • التواصل (Communication): تستخدم الـ monoliths استدعاءات دوال (function calls) بسيطة، بينما تستخدم الـ microservices استدعاءات الشبكة. • الأعباء الإضافية (Overhead): تتميز الـ monoliths بتكاليف تشغيلية منخفضة، بينما تتميز الـ microservices بتكاليف عالية.

متى يجب عليك اختيار الـ modular monolith؟

  • فريقك يضم أقل من 50 مهندساً.
  • تحتاج إلى تقليل تكاليف البنية التحتية السحابية.
  • تريد تبسيط عمليات تصحيح الأخطاء (debugging) والاختبار.
  • خدماتك غالباً ما تحتاج إلى النشر معاً على أي حال.

شركات حقيقية تقوم بذلك بالفعل. تستخدم Shopify نهجاً نموذجياً (modular approach) لإدارة ملايين التجار. وقامت Amazon Prime Video بنقل عبء عمل محدد من الـ microservices إلى monolith. وقد شهدوا انخفاضاً بنسبة 90% في تكاليف البنية التحتية.

لا تبنِ لتصل إلى حجم Netflix إذا كنت فريقاً صغيراً. ابدأ بنهج modular. لا تستخرج خدمة (extract a service) إلا عندما تظهر بياناتك أنك بحاجة فعلية لذلك.

استخدم قائمة التحقق هذه لمعرفة ما إذا كنت بحاجة إلى الدمج:

  • هل تقضي وقتاً في تصحيح اتصالات الخدمات أكثر مما تقضيه في بناء الميزات؟
  • هل تنمو فاتورة السحابة الخاصة بك بشكل أسرع من نمو عدد مستخدميك؟
  • هل لديك أقل من 5 مهندسي DevOps للعديد من الخدمات؟
  • هل يقوم المهندسون بتتبع طلب واحد عبر 3 خدمات أو أكثر للعثور على خطأ؟

إذا كانت إجابتك بنعم، فمن المرجح أن يكون الـ modular monolith هو الخطوة الصحيحة.

المصدر: https://dev.to/ail_akram_dcc5063c428734b/why-we-moved-back-to-a-modular-monolith-the-costly-reality-of-microservices-in-2026-3kbo

مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi