"Mikroservis mimarisi kullanıyoruz" cümlesi teknik görüşmelerde güven veriyor. Ama çoğu zaman bu cümleyi söyleyen ekipler Netflix değil, 5-15 kişilik bir yazılım takımı.
Conway's Law'ı Hatırlayın
Melvin Conway'in 1968'den kalma gözlemi: "Sistemleri tasarlayan organizasyonlar, bu organizasyonların iletişim yapısını kopyalayan tasarımlar üretmek zorunda kalır."
Pratik anlamı: Ekibiniz 5 parçadan oluşuyorsa, sisteminiz de 5 parçaya bölünmeye eğilimli olur. Bu bölünme zorla yapılırsa, yani organizasyona uygun olmayan bir mikroservis mimarisi dayatılırsa, koordinasyon maliyeti üretime yansır.
3 Gerçek Maliyet
Maliyet 1: DevOps Yükü
Her mikroservis kendi CI/CD pipeline'ı, kendi monitoring'i, kendi log aggregation'ı demek. 10 servis = 10 deployment birimi. Küçük ekipler için bu, geliştirme süresinin %30-50'sini operasyona harcamak demek.
Maliyet 2: Distributed Transactions
Sipariş oluşturma işlemi 3 servisi kapsıyorsa: Sipariş Servisi, Stok Servisi, Ödeme Servisi. Birinde hata olursa? Saga pattern, compensation transactions, distributed locks... Bu komplekslik monolit'te basit bir veritabanı transaction'ı ile çözülür.
Maliyet 3: Debug Karmaşıklığı
"Neden hata aldım?" sorusu, monolitte stack trace ile cevaplanır. Mikroserviste: distributed tracing, log correlation, service mesh anlamak gerekebilir. Bunlar çözülebilir problemler ama küçük ekipler için ciddi yük.
Eğer "servisler arası haberleşme hatası" veya "hangi servis çekiyor bunu?" gibi soruları sık sık duyuyorsanız, ölçek için tasarlanmış bir mimariyi hazır olmayan bir ekibe uygulamış olabilirsiniz.
KELD'in Önerisi: Modüler Monolit
Modüler monolit tam olarak ortada duruyor: Tek bir deploy birimi, ama içeride iyi tanımlanmış modüller. Her modülün kendi domain'i var, kendi veritabanı tabloları var, ancak hepsi aynı süreçte çalışıyor.
Avantajları:
- Tek CI/CD pipeline
- Database transaction kullanılabilir
- Debug basit, tek stack trace
- Gerektiğinde modülleri gerçek servislere ayırmak mümkün
Ne Zaman Gerçekten Mikroservise Geçmeli?
3 sinyal:
- Farklı servislerin bağımsız olarak ölçeklenmesi gerekiyor (yoğun trafik alan özellik diğerlerinden izole edilmeli)
- Farklı ekipler farklı teknoloji yığınlarına ihtiyaç duyuyor
- Organizasyon zaten domain-based takımlara bölünmüş ve bu bölünme mantıklı
Bu 3 koşul yoksa: modüler monolit ile başlayın.
Sonuç
Mikroservis "modern" değil, karmaşık. Doğru ölçekte, doğru organizasyonla güçlü. Yanlış ölçekte, zayıf ekiple felaket. Başlangıç noktanız iyi bir monolit olsun, gerektiğinde bölersiniz.