في ٢٠٢٤ ساعدنا شركة تكنولوجيا مالية محلية في تحويل monolith عمره ٦ سنوات (٨٠٠٠٠+ سطر كود، ١٢ developer، ٤٥ deploy يومياً) لـ microservices. الرحلة اخدت ١٤ شهر، فيها شغل كتير، دروس أكتر، وأرقام بتتكلم.
إمتى تفكر في التحول؟
مش كل monolith محتاج تحول. علامات التحذير اللي بتقول إن الوقت جه:
- Deploy واحد بيكسر ٣ أجزاء منفصلة
- فريق بيحتاج coordination ساعات عشان ينشر feature
- مش قادر تسكيل جزء من النظام بدون ما تسكيل الكل
- زمن الـ CI pipeline تجاوز ٣٠ دقيقة
- Codebase بقى “حد ما يعرف كله”
إمتى ما تفكر في التحول؟
- فريقك أقل من ١٠ developers
- Monolith شغال كويس ومفيش شكاوى أداء
- مش عندك infrastructure team مختصة
- بتبني MVP — الـ microservices في البداية انتحار
“الـ microservices تكلفة تشغيلية عالية. الشركات اللي بتتحول عشان الـ trend بتخسر — بتحل مشاكل ما كانتش موجودة وتستورد مشاكل جديدة.”
مراحل التحول — الطريقة اللي اتبعناها
المرحلة ١: Strangler Fig Pattern (٣ شهور)
بدأنا بحطّ API gateway قدام الـ monolith، ومن ثم بنينا أول microservice جديد (Notifications) بدون ما نلمس الـ monolith. كل request جديد بيمشي على الـ service الجديد، القديم باقي شغال.
المرحلة ٢: Extract Bounded Contexts (٥ شهور)
حددنا الـ bounded contexts (Users، Orders، Payments، Reports) وبدأنا extraction واحد واحد. كل extraction كان بياخد ٤-٦ أسابيع. قاعدة البيانات كانت التحدي الأكبر — مش الكود.
المرحلة ٣: Data Decomposition (٤ شهور)
تقسيم الـ database كان أصعب مرحلة. استخدمنا dual-write pattern في البداية — نكتب في الاتنين — ثم switchover تدريجي. عملنا reconciliation scripts كل يوم للتأكد من consistency.
المرحلة ٤: Cleanup (شهرين)
بعد ما كل الـ services اتشغلت، رجعنا للـ monolith وشيلنا الكود المنقول. الـ monolith اتحول لـ “legacy service” بس بـ ٢٠٪ من حجمه الأصلي.
الأرقام الحقيقية
- Deploy frequency: من ٤٥/يوم إلى ٢٠٠+/يوم
- Mean time to recovery: من ٤٥ دقيقة إلى ٨ دقائق
- Infrastructure cost: زاد ٤٠٪ (تكلفة التحول الحقيقية)
- Developer productivity (features/sprint): زادت ٢.٣x
- Incidents: انخفضت ٦٠٪ بعد ٦ شهور من الانتهاء
٥ دروس اتعلمناها
١. ابدأ بالـ deployment pipeline مش بالكود
لو مش عندك CI/CD ناضج، containers، monitoring، و service mesh — التحول هيفشل. جهز الـ infrastructure الأول.
٢. الـ database هو العدو الحقيقي
تقسيم الكود سهل. تقسيم البيانات مع الحفاظ على الـ consistency — ده المشروع الحقيقي.
٣. الـ distributed tracing ما تبقى optional
بدون Jaeger أو Tempo، استحالة تـ debug مشكلة بتمر من ٥ services. ركّبه قبل أول service.
٤. الفريق محتاج تدريب فعلي
الـ patterns مختلفة تماماً. Saga، Event sourcing، CQRS — مش كل فريق جاهز ليها. استثمر في التدريب قبل الكود.
٥. ما تتحولش كله مرة واحدة
Big bang migrations بتفشل دايماً. التحول التدريجي (strangler pattern) بيوفر القدرة على التراجع في أي مرحلة.
الخلاصة
الـ microservices مش حل سحري — هي أداة بتحل مشاكل معينة وبتستورد مشاكل جديدة. لو قرّرت تبدأ، خطّط ١٨ شهر، خصّص ميزانية كافية، واستعد لرحلة صعبة لكن مجزية. ولو محتاج دليل من حد مشى الطريق، احنا موجودين.