يا جماعة الخير، السلام عليكم.
اسمحولي اليوم أحكيلكم قصة صارت معي قبل كم سنة، قصة فيها سهر وتعب وقهوة كتير… قصة عن وحش. مش وحش خيالي، لأ، وحش برمجي حقيقي كان عايش معنا في الشركة، وكان اسمه “المونوليث”.
بتذكرها زي كأنه مبارح. كانت الساعة 2 بعد نص الليل، وأنا وفريق صغير قاعدين بالمكتب، عيونا حُمر من التعب والشاشات. كان عنا “إطلاق” (Deployment) لتحديث بسيط على نظامنا المركزي. المفروض إنه شغلة بسيطة، تعديل على آلية حساب الفواتير، ما بتاخد وقت. لكن مع نظامنا المونوليثي، “بسيط” هي كلمة مش موجودة بالقاموس.
كل شيء كان مربوط ببعضه زي صحن مسبحة انفرطت خرزاته. تعديل صغير في مكان، بخلّي النظام كله “يضرب” في مكان تاني ما إله أي علاقة. بعد ساعات من البحث، اكتشفنا إنه التعديل تبعنا أثّر على وحدة (module) تسجيل دخول المستخدمين! شو دخل الفواتير بتسجيل الدخول؟ اسألوا الوحش المونوليثي، هو بس اللي بيعرف. يومها، بعد ما أصلحنا المشكلة وطلعنا مع خيوط الفجر الأولى، قعدت مع حالي وحكيت: “لهون وبس، لازم نلاقي حل. هاي مش حياة مبرمجين!”.
ما هو الوحش المونوليثي (Monolith)؟ ولماذا هو مشكلة؟
قبل ما نكمل القصة، خلينا نحكي شوي عن “المونوليث”. تخيل إنك بتبني بيت، وبدل ما تبني كل غرفة لحال وتوصل بينهم بممرات، قررت تبني البيت كله ككتلة واحدة عملاقة من الإسمنت. غرفة النوم جزء لا يتجزأ من المطبخ، والحمام ملزق بالصالون. هاد بالزبط هو النظام المونوليثي.
في البداية، بيكون هاد الأسلوب سريع وسهل. كل الكود في مكان واحد، قاعدة بيانات واحدة، عملية نشر واحدة. لكن مع الوقت، لما المشروع يكبر ويتعقد، بتبلش المشاكل:
- التعقيد القاتل: أي تغيير صغير بيتطلب فهم النظام كله، وهذا شبه مستحيل. بصير الفريق بخاف يلمس الكود.
- بطء التطوير والنشر: عملية الـ build والـ testing والنشر بتصير تاخد ساعات وأحياناً أيام.
- صعوبة التوسع (Scalability): إذا جزء واحد من النظام عليه ضغط (مثلاً، البحث)، لازم تعمل scale للنظام كله، وهذا مكلف جداً وغير فعال.
- سجن التكنولوجيا: أنت محبوس بنفس لغة البرمجة وإطار العمل اللي بديت فيهم. صعب جداً تجرب تقنيات جديدة أو تحدث مكتبات قديمة.
سراب “إعادة الكتابة الكبرى” (The Big Rewrite)
لما وصلنا مرحلة اليأس، أول اقتراح انطرح على الطاولة من أحد المبرمجين الشباب المتحمسين كان: “ليش ما نعيد كتابة كل شيء من الصفر؟”.
هذا الاقتراح، يا جماعة، هو واحد من أخطر الفخاخ اللي ممكن يوقع فيها أي فريق تقني. إعادة الكتابة الكبرى تبدو وكأنها الحل السحري، أرض الأحلام اللي فيها كود نظيف وتقنيات حديثة. لكنها في الحقيقة سراب في الصحراء. ليش؟
- الوقت والتكلفة: ممكن تاخد شهور أو حتى سنوات، وخلال كل هاي الفترة، أنت ما بتضيف أي ميزات جديدة للشغل (business). الإدارة ما رح تكون مبسوطة.
- المخاطرة العالية: شو بيضمنلك إنه النظام الجديد رح يكون أحسن؟ أنت بتخاطر بإنك تكرر نفس الأخطاء، أو تعمل أخطاء جديدة.
- الهدف المتحرك: متطلبات السوق والعمل بتتغير. لما تخلص إعادة كتابة بعد سنتين، ممكن يكون النظام الجديد صار قديم أصلاً.
رفضنا فكرة إعادة الكتابة، مش جبناً، ولكن حكمة. كنا بدنا حل عملي، حل يخلينا نصلح السيارة وهي ماشية. وهنا، وبعد بحث وقراءة، وجدنا ضالتنا في استراتيجية عبقرية اسمها “نمط الخانق”.
المنقذ: نمط شجرة التين الخانقة (Strangler Fig Pattern)
الاسم غريب شوي، صح؟ الفكرة مستوحاة من شجرة التين الخانقة في الغابات الاستوائية. هاي الشجرة بتبدأ حياتها كبذرة صغيرة على فروع شجرة ضخمة قديمة. شوي شوي، بتنزل جذورها الرفيعة للأرض، وبتبدأ تنمو وتلتف حوالين الشجرة المضيفة. مع مرور السنين، جذورها بتصير أضخم وأقوى، وبتحجب الشمس والهوا عن الشجرة الأصلية، لحد ما الشجرة الأصلية تموت وتتحلل، وبتضل شجرة التين الخانقة مكانها، قوية وشامخة.
هذا بالضبط ما يفعله هذا النمط مع نظامك المونوليثي. بدل ما تهدمه مرة واحدة، أنت بتبني نظام جديد “حواليه” قطعة قطعة، لحد ما النظام القديم “يختنق” ويموت تدريجياً.
كيف يعمل نمط الخانق على أرض الواقع؟ (الخطوات العملية)
القصة وما فيها، هي عملية تدريجية ومنظمة. خلينا نمشي فيها خطوة خطوة:
الخطوة الأولى: تحديد “الحدود” ووضع “الواجهة” (Facade)
أول وأهم خطوة هي وضع “بروكسي” أو “بوابة واجهة برمجة تطبيقات” (API Gateway) أمام النظام المونوليثي القديم. هاي البوابة بتصير هي نقطة الدخول الوحيدة لكل الطلبات (requests) من المستخدمين. في البداية، كل وظيفتها هي إنها تمرر كل الطلبات زي ما هي للنظام القديم.
نصيحة أبو عمر: لا تستخدم حلول معقدة في البداية. ممكن تبدأ ببروكسي بسيط جداً باستخدام Nginx أو Caddy. الهدف هو السيطرة على تدفق البيانات، مش بناء نظام معقد جديد.
الخطوة الثانية: تحديد أول “ضحية” (أول خدمة سيتم استبدالها)
ابدأ بشيء صغير ومنفصل نسبياً. لا تروح على طول على قلب النظام. ممكن تكون خدمة إدارة ملفات المستخدمين (User Profiles)، أو نظام الإشعارات، أو سلة المشتريات في متجر إلكتروني. اختار جزء واضح ومفهوم.
في حالتنا، كانت أول ضحية هي خدمة “تصدير التقارير”. كانت خدمة بتسبب ضغط كبير على قاعدة البيانات، ومنفصلة منطقياً عن باقي العمليات الحساسة.
الخطوة الثالثة: بناء الخدمة الجديدة (Microservice)
هنا تبدأ المتعة. قم ببناء الخدمة الجديدة كـ “خدمة مصغرة” (Microservice) مستقلة تماماً. استخدم أحدث التقنيات اللي بتحبها (Python, Go, Node.js)، قاعدة بيانات خاصة فيها، وكل شيء. هاي فرصتك للتجربة والتحسين.
الخطوة الرابعة: عملية “الخنق” (التوجيه)
بعد ما الخدمة الجديدة تصير جاهزة، بترجع للبوابة (API Gateway) اللي حطيناها في الخطوة الأولى. الآن، بدل ما تمرر الطلبات الخاصة بالتقارير للنظام القديم، بتقوم بتوجيهها للخدمة الجديدة.
مثلاً، لو الطلب كان /api/reports، البوابة بتعرف إنه هاد لازم يروح للخدمة الجديدة. أي طلب تاني (مثلاً /api/billing) بضل يروح للنظام المونوليثي القديم.
هذا مثال بسيط جداً على إعدادات Nginx لتحقيق هذا:
http {
# عنوان الخدمة الجديدة (تصدير التقارير)
upstream new_reports_service {
server reports-service:8000;
}
# عنوان النظام المونوليثي القديم
upstream old_monolith {
server monolith-app:8080;
}
server {
listen 80;
# إذا كان المسار للتقارير، وجهه للخدمة الجديدة
location /api/reports {
proxy_pass http://new_reports_service;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# أي شيء آخر، وجهه للنظام القديم
location / {
proxy_pass http://old_monolith;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
شفتوا كيف؟ شغل مرتب وبسيط. المستخدم النهائي ما بحس بأي شيء. هو بضل يطلب نفس الرابط، لكن “تحت الغطا”، الطلب بروح لمكان جديد ومحسن.
الخطوة الخامسة: التكرار والتوسع
مبروك! لقد قمت بخنق أول جزء من الوحش بنجاح. الآن، كل ما عليك هو تكرار العملية. ارجع للخطوة الثانية، اختار “ضحية” جديدة، ابني خدمتها، ووجه الطلبات إلها. مع كل دورة، نظامك الجديد بيكبر، والوحش المونوليثي بيصغر وبيصغر، لحد ما يتبقى منه جزء صغير جداً ممكن تتركه أو تتخلص منه بسهولة.
الخلاصة: ترويض الوحوش بحكمة وصبر
نمط الخانق مش حل سريع، هو استراتيجية طويلة الأمد. بده صبر وتخطيط، لكنه الأسلوب الأكثر أماناً وفعالية للتعامل مع الأنظمة الموروثة الضخمة. بدل ما تدخل في معركة خاسرة مع الوحش، أنت بتتحايل عليه وبتسحب البساط من تحت رجليه شوي شوي.
الدروس اللي تعلمتها من هاي التجربة كانت ثمينة جداً:
- ✅ النمو التدريجي أفضل من الثورة المفاجئة: التغييرات الصغيرة والمتراكمة بتقلل المخاطر وبتسمحلك تشوف قيمة شغلك بسرعة.
- ✅ السيطرة على “البوابة” هي مفتاح كل شيء: من يملك الـ Proxy/Gateway يملك القدرة على التحكم في عملية التحديث.
- ✅ لا تخف من الأنظمة القديمة: مع الاستراتيجية الصحيحة، أي نظام قديم هو فرصة للتحسين والتعلم.
نصيحتي الأخيرة لكل مبرمج أو مدير فريق بواجه وحش مونوليثي: لا تيأسوا، ولا تنجروا وراء حلم “إعادة الكتابة الكبرى”. ابدأوا صغاراً، فكروا كشجرة التين الخانقة، ولفوا جذوركم الحديثة حول النظام القديم. خطوة خطوة، رح تبنوا نظاماً جديداً وقوياً، ورح تلاقوا حالكم بالنهاية واقفين على أنقاض الوحش القديم. 💪
