Son birkaç yıldır “mimari danışmanlığı” başlığıyla gelen projelerin neredeyse yarısı bir tanıdık hikayeyle açılıyor: “Monolit’imiz büyüdü, mikroservise geçmeliyiz.” Ben de bu lafın arkasındaki gerçek problemi anlayana kadar danışmanlığa başlamıyorum, çünkü %60’ında çözüm mikroservis değil.
1. Sorun gerçekten mi kod, yoksa ekip mi?
Conway’in yasası net: bir ekibin kuracağı sistem, o ekibin iletişim yapısına benzer. Tek bir 12 kişilik ekip tek bir monolitik kod tabanı üretir. Aynı ekip ayrılmadan mikroservis yazmaya kalkarsa, aslında aynı monolit’i dağıtık sistemde tekrar üretir, sadece daha zor debug edilebilir halde.
Soru şu: “Monolit teslim hızımızı neden yavaşlatıyor?”
- Herkes aynı yere deploy ettiği için mi? → Feature flag mantığı yeterli olabilir.
- Test suite saatlerce sürüyor mu? → Test parçalama, paralel çalıştırma önce denenmeli.
- Bir geliştirici diğerinin kodunu bilmediği için mi? → Modüler monolit (bounded contexts) çözer.
- Yeni geliştiriciyi onboarding uzun sürüyor mu? → Dokümantasyon ve kod haritası eksik.
Bu sorunların hiçbiri mikroservis gerektirmiyor. Mikroservis, ancak ayrı ekipler ayrı deploy cycle’ı istediğinde değer katıyor. Tek ekip varsa deploy cycle zaten tek, servisleri ayırmak sadece latency ve operasyonel yük ekliyor.
2. Bugünkü operasyon ekibin mikroservis’i kaldırabilir mi?
Mikroservis sadece yazılım kararı değil, operasyon kararı. Dağıtık sistemin altyapısı gelir:
- Service discovery, load balancer, API gateway
- Centralized logging (hangi servis, hangi istek, hangi response?)
- Distributed tracing (bir request kaç servis üzerinden geçti?)
- Her servis için ayrı CI/CD pipeline
- Circuit breaker, retry, idempotency strategies
Bunların hepsi büyük yatırımlar. Bir yazılımcı + bir DevOps ile monolit yönetmek mümkün; aynı ekiple 8 servisli bir sistem yönetmek sürekli tökezleme demek.
Benim önerim: mikroservis’e geçmeden önce 6 ay boyunca monitoring ve observability’yi monolit’te bile doğru kurmayı isterim. Monolit’in gözlemlenebilirliği iyiyse, dağıtık sisteme geçiş daha kolay. Değilse, mikroservis’te toz bulutunun içinde çalışırsın.
3. Bounded context’ler gerçekten ayrı mı?
Domain-driven design’ın söylediği şu: eğer iki “servis” sürekli birbirini çağırıyorsa, aynı servis olmaları gerekiyor. Mikroservis’e ayırdığın bir şey eğer tek bir kullanıcı aksiyonu için 4-5 hop yapıyorsa, yanlış sınır çizmişsin demektir.
Gerçek bir örnek: geçen sene bir müşteri “user service, auth service, profile service, notification service” mimarisiyle geldi. Kullanıcı kayıt olurken 4 servisi de çağırması gerekiyordu. Ben de 1 servise konsolide ettik, “users”, ve latency %60 düştü, hata yüzeyi inanılmaz sadeleşti.
Bounded context’i test etmenin en basit yolu: servisler arasında “transaction” ihtiyacı var mı? Varsa, muhtemelen tek servis olmalılar. Dağıtık transaction (saga pattern) bir çözüm, ama çözmeye çalıştığın problem sensin.
Kısaltmalar ve tekniğin ötesi
Modüler monolit bugün çoğu takım için doğru cevap. Tek deploy, tek repo, ama paket düzeyinde sınırlar net. Paket X paket Y’nin iç tiplerine ulaşamaz. Testler modül düzeyinde izole koşulur. 2-3 yıl sonra ekip büyüdüğünde ve gerçek bir ayrım gerektiğinde, modülü servise çıkarmak 2-3 haftalık bir iştir, çünkü sınırlar zaten çizili.
Mikroservis’e geçen her ekibin 2 yıl sonra yarısını geri topladığını gördüm. Shopify yıllarca “majestic monolith” savundu. Basecamp aynı şekilde. Amazon, Netflix, Uber’in ölçeğinde değilseniz, monolit’i fazla erken terk etmek pahalı bir ders.
Gerçek soru “mikroservis mi monolit mi” değil, “şu anki problem benim ekibimin işini daha yavaş mı yapıyor, yoksa çözmeye çalıştığım başka bir şey mi?”