Monolit hâlâ doğru cevap: mikroservise geçmeden önce ölçülecek 4 şey

Mikroservise geçme kararı çoğu zaman şu cümleyle başlıyor: "Uygulama büyüdü, artık bölmemiz lazım." Bu cümledeki "büyüdü" kelimesi genelde kod tabanının büyüklüğünü kastediyor. Oysa mikroservisin çözdüğü problem kod büyüklüğü değil.

Mikroservis, bağımsız dağıtım problemini çözer. Yani: farklı ekiplerin, birbirini beklemeden üretime çıkabilmesi. Ekip sayınız buna ihtiyaç duyacak kadar fazla değilse, mikroservis size çözdüğünden fazla problem getirir.

Geçiş öncesi ölçülecek dört şey

1. Dağıtım çakışması sıklığı

Son üç ayda kaç kez, bir ekibin değişikliği başka bir ekibin değişikliğini beklediği için üretime çıkamadı?

Bu sayı ayda 1-2 ise sorun mimaride değil, dağıtım sürecinde. Ayda 10'un üstündeyse ve farklı ekiplerden geliyorsa, bölme tartışması anlamlı hâle geliyor.

2. Değişikliklerin dağılımı

Git geçmişinden şu soruyu cevaplayın: son 500 commit hangi dizinlere dokundu?

Eğer değişikliklerin %70'i kod tabanının %20'sine yığılıyorsa, o %20'yi ayırmak anlamlı olabilir. Eğer değişiklikler her yere yayılıyorsa, bölme sınırınız yok demektir — ve sınırı olmayan bir bölme, dağıtık monolit üretir. Dağıtık monolit, monolitin bütün dezavantajlarını mikroservisin bütün karmaşıklığıyla birleştiren yapıdır. En kötü sonuç budur.

3. Ölçekleme ihtiyacının şekli

Yükünüz her yerde eşit mi artıyor, yoksa tek bir uçta mı? Tek bir uçta yığılıyorsa (rapor üretimi, görüntü işleme, dışa aktarma), o ucu ayırmak için tüm mimariyi değiştirmeye gerek yok — o işi bir kuyruğa alıp ayrı bir işçi sürecine vermek yeterli.

Bu, mikroservis değil; sadece asenkron iş yürütme. Faydanın büyük kısmını, maliyetin küçük kısmıyla veriyor.

4. İşletme kapasiteniz

Mikroservis, bir işletme (operations) yatırımıdır. Geçmeden önce şunların hepsi mevcut olmalı:

• Dağıtık izleme (bir isteği servisler arasında takip edebilme)
• Merkezî log toplama
• Servisler arası sözleşme testleri
• Her servis için ayrı, otomatik dağıtım hattı
• Sürüm uyumsuzluğunu yönetecek bir strateji

Bu beşi yoksa, ilk üretim hatasında "hangi serviste?" sorusuna cevap veremezsiniz ve hata ayıklama süresi katlanır.

Monolitin çoğu zaman doğru olmasının nedeni

Tek bir süreç içinde:

• Fonksiyon çağrısı ağ çağrısı değildir — gecikme yok, kısmi hata yok, yeniden deneme mantığı yok.
• İşlem (transaction) bütünlüğü veritabanının işidir; dağıtık işlem kurmanız gerekmez.
• Yeniden düzenleme (refactor) derleyici/tip denetimi ile güvenlidir. Servisler arasında böyle bir güvence yok.
• Yerelde tek komutla çalışır. Bu, yeni ekip üyesinin ilk gününü belirler.

Bu avantajlar somut ve her gün hissediliyor. Mikroservisin avantajı ise ancak belirli bir ekip ölçeğinde hissediliyor.

Aradaki yol: modüler monolit

Çoğu ekip için doğru cevap ikisinin arası. Tek dağıtım birimi, ama içeride net sınırlar:

• Her modülün kendi dizini ve kendi genel arayüzü (public API) var.
• Modüller birbirinin iç yapısına değil, yalnızca arayüzüne dokunuyor.
• Veritabanı tablolarına yalnızca sahibi olan modül yazıyor. Diğerleri okumak için bile arayüzden geçiyor.
• Bu kural bir test ya da statik analiz kuralıyla zorlanıyor — "dikkat edelim" ile yürümüyor.

Bu yapının en büyük faydası şu: gerçekten bölmeniz gerektiğinde, sınırlar zaten çizilmiş oluyor. Bir modülü ayrı servise çıkarmak günlerin değil saatlerin işi hâline geliyor.

Geçişin gerçekten gerektiği tek durum

Onca kısıttan sonra kalan net kural şu: Ekipler birbirini bekliyorsa böl. Bunun dışındaki her gerekçe — ölçek, teknoloji çeşitliliği, "modern mimari", işe alım cazibesi — geçişin maliyetini karşılamıyor.

Ve bölerken önce en az bağımlı, en net sınırlı parçayı çıkarın. İlk servisiniz, en kritik iş akışınız olmasın.