Son on yılda yazılım dünyasında tek bir mantra hüküm sürdü: "Monolitik sistemler kötüdür; ölçeklenmek için mikroservislere geçmelisiniz." Bu akıma kapılan pek çok şirket, müşteri kitlesini oturtmadan ya da ekibini büyütmeden sistemini onlarca bağımsız servise böldü.
Bugün birçok ekip, mikroservislerin getirdiği karmaşıklığın altında eziliyor: DevOps yükü, dağıtık sistem hataları ve yüksek bulut faturaları. Tartışmanın sembolü haline gelen örnek ise Amazon Prime Video oldu: ekip, video kalitesini izleyen bir servisini dağıtık mimariden tek süreçli bir yapıya taşıyarak o servisin altyapı maliyetini %90'ın üzerinde düşürdüğünü anlattı.
Peki monolitin sadeliğini ve hızını koruyup mikroservislerin sunduğu temiz sınırları elde etmek mümkün mü? Cevap: modüler monolit (modular monolith) mimarisi.
Mikroservisler neden her şirket için doğru tercih değil?
Mikroservis mimarisi teoride harikadır: her servis bağımsız ölçeklenir, farklı teknolojiler kullanılabilir ve ekipler birbirini beklemeden kod yayınlayabilir. Pratikte ise şu engeller ortaya çıkar.
Aşırı karmaşık altyapı (over-engineering)
Tek bir veritabanı sorgusu yerine ağ üzerinden beş farklı servisle konuşmanız gerekir. Her çağrı ağ gecikmesi (network latency) ve yeni bir hata noktası demektir.
Dağıtık veri yönetimi
Veritabanları ayrıldığında servisler arası ACID işlemleri (transactions) zorlaşır. Veri tutarlılığını sonradan sağlamak (eventual consistency) ciddi bir teknik borç yaratır.
Yüksek bulut ve DevOps maliyeti
Her servis için ayrı CI/CD hattı, konteyner, Kubernetes kaynakları ve izleme (monitoring) araçları çalıştırmak, küçük ve orta ölçekli ekiplerin bütçesini ve zamanını zorlar.
Modüler monolit nedir?
Modüler monolit, uygulamanın tek bir dağıtım birimi (single deployment unit) olarak çalıştığı, ancak kod tabanının iç içe geçmiş "spagetti kod" yerine sıkı sınırlarla ayrılmış modüllerden (bounded contexts) oluştuğu mimari yaklaşımdır.
Örneğin bir e-ticaret sisteminde kullanıcı yönetimi, sipariş, ödeme ve stok modülleri aynı projede yer alır; ama birbirlerinin veritabanı tablolarına ya da iç mantığına doğrudan erişemez. İletişim yalnızca açıkça tanımlanmış modül arayüzleri ve olaylar (events) üzerinden kurulur.
Monolit, mikroservis ve modüler monolit karşılaştırması
| Kriter | Geleneksel monolit | Mikroservis | Modüler monolit |
|---|---|---|---|
| Dağıtım | Tek parça, hızlı | Çoklu servis, karmaşık | Tek parça, hızlı |
| Kod sınırları | Zayıf, spagettiye açık | Çok sıkı (ağ seviyesinde) | Sıkı (modül seviyesinde) |
| DevOps ve bulut maliyeti | Düşük | Yüksek | Düşük |
| Geliştirme hızı | Başta hızlı, sonra yavaş | Servis bağımlılıkları yüzünden yavaş | Sürekli yüksek |
| Ağ gecikmesi | Yok (bellek içi) | Var (HTTP / gRPC) | Yok (bellek içi) |
Modüler monolit mimarisinin 4 büyük avantajı
1. Kolay CI/CD ve düşük operasyonel yük
Tek bir kod deposu (repository) ve tek bir CI/CD hattı yeterlidir. Kubernetes cluster'ları yönetmek ya da servisler arası gecikmeleri analiz etmekle zaman kaybetmezsiniz.
2. Sınırları değiştirmek ve refactoring kolaydır
İş alanınızı (domain) henüz tam tanımıyorsanız, mikroservis sınırlarını yanlış çizmek kabusa dönüşür. Modüler monolitte iki modülü birleştirmek ya da sorumlulukları yeniden dağıtmak, birkaç refactoring adımından ibarettir.
3. Yüksek performans, ağ gecikmesi yok
Modüller birbiriyle HTTP ya da gRPC çağrıları yerine uygulama içi fonksiyon çağrılarıyla konuşur. Servisler arası ağ gecikmesi ve bu çağrıların hata yönetimi ortadan kalkar.
4. İleride mikroservise bölünmeye hazır yapı
En büyük avantajı budur: doğru kurgulanmış bir modüler monolitte, yarın ödeme modülü çok yüksek trafiğe ulaşırsa o modülü projeden ayırıp bağımsız bir mikroservise dönüştürmek çok daha kolaydır; çünkü sınırları ve arayüzü zaten bellidir.
Mikroservis bir hedef değil; ölçeklenme ihtiyacının doğal bir sonucu olmalı.
Ne zaman mikroservise geçmelisiniz?
Aşağıdaki koşullardan biri ya da birkaçı geçerliyse, modüler monolit büyük olasılıkla sizin için en doğru seçimdir:
- Yazılım ekibiniz 20–30 kişiden azsa,
- Modülleriniz arasında ölçeklenme ihtiyacı (CPU, bellek, trafik) açısından radikal farklar yoksa,
- İş modeliniz ve ürün sınırlarınız henüz oturmadıysa (MVP ya da hızlı büyüme dönemi).
Tersine; çok sayıda ekibin aynı kod tabanında birbirini beklediği, bir modülün diğerlerinden çok farklı ölçeklendiği ya da farklı teknoloji gerektirdiği durumlarda o modülü mikroservise ayırmanın zamanı gelmiş demektir.
oigoworks'te nasıl uyguluyoruz?
Her ürünümüz kendi sektöründe bağımsız bir uygulama olarak, tek bir dağıtım birimiyle çalışır; içeride ise rezervasyon, ödeme, raporlama gibi alanlar ayrı modüller halinde tutulur. Ürünler arası iletişim gerektiğinde bunu API ve webhook'larla kurarız. Size özel geliştirdiğimiz web yazılımlarında da aynı yaklaşımı izliyoruz: bugün sade ve hızlı, yarın gerektiğinde bölünebilir.
Sık sorulan sorular
Modüler monolit ile mikroservis arasındaki fark nedir?
İkisinde de kod net sınırlarla modüllere ayrılır. Fark, mikroservislerde her modülün ayrı bir uygulama olarak ağ üzerinden haberleşmesi; modüler monolitte ise tüm modüllerin tek bir uygulama içinde, fonksiyon çağrıları ve olaylarla haberleşmesidir.
Monolit mimari kötü mü?
Hayır. Sorun monolitin kendisi değil, modül sınırları olmayan "spagetti" monolittir. Sınırları net çizilmiş bir monolit, çoğu ekip için mikroservislerden daha hızlı ve daha ucuzdur.
Modüler monolitte modüller nasıl iletişim kurar?
Her modül diğerlerine yalnızca açık bir arayüz (servis sınıfı ya da sözleşme) sunar ve olay (event) yayınlar. Bir modül başka bir modülün veritabanı tablolarına doğrudan erişmez.
Modüler monolitten mikroservise geçiş zor mu?
Sınırlar baştan doğru çizildiyse görece kolaydır: modülün arayüzü zaten tanımlı olduğu için, içerideki fonksiyon çağrılarını ağ çağrılarına çevirip modülü ayrı bir servis olarak yayınlamak yeterli olur.
Sonuç: hız ve sürdürülebilirlik arasındaki denge
Yazılım mimarisinde "en havalı" olanı değil, iş hedeflerinize ve ekibinizin kapasitesine en uygun olanı seçmek esastır. Modüler monolit; sürdürülebilir, bakımı kolay ve gereksiz maliyet getirmeyen bir başlangıç noktası sunar ve sisteminizi gerektiğinde mikroservislere bölünebilecek esneklikte tutar.