Monolitten mikroservise geçerken yapılan dört hata

Son beş yılda 40'tan fazla mikroservis geçişinde bulundum. Bir kısmı başarıyla tamamlandı, bir kısmı geri döndü, bir kısmı yarım asılı kaldı. Başarısızlıkların çok azı gerçekten teknik sebeplerle olmuş; büyük çoğunluğu aynı dört tuzağa düşüyor.

Hata 1: Önce bölmek, sonra düşünmek

'Mikroservis' denilince akla ilk gelen, monoliti Docker container'larına parçalamak oluyor. Oysa önemli olan sınır çizmektir — hangi iş etkileşimi kendi içine kapalı bir alan oluşturuyor, hangisi ortak veriye dokunmak zorunda. Bu sınır çizmek için önce Domain-Driven Design prensipleriyle bounded context'leri çıkartmalı, ancak ondan sonra konuşma servis bölmeye gelmeli.

Hata 2: Paylaşılan veritabanı

Servisler farklı ama hepsi aynı Postgres'e yazıyor. Bu 'distributed monolith' dediğimiz durumdur: dağıtık operasyon karmaşıklığı var ama bağımsız deploy edilebilir değiller. Gerçek mikroservis, her servisin kendi veritabanına sahip olması demektir; veri paylaşımı event stream üzerinden veya iyi tanımlanmış API'lerden yapılır.

Hata 3: Ekip yapısını görmezden gelmek

Conway yasasını hatırlayın: yazdığınız sistem, iletişim yapınıza benzer. Altı ekip tarafından yazılan bir sistem altı servisten oluşma eğilimindedir, tam tersi değil. Mikroservise geçiyorsanız, ekip topolojinizi de yeniden tasarlamanız gerekir. Yoksa servislerin sınırları, gerçek iş kapısını değil ekiplerin iç politikasını yansıtır.

Hata 4: Gözlemlenebilirliği sonradan eklemek

Monolit bir sistemde log dosyasına bakmak genelde yeterlidir. Mikroservis bir sistemde bir isteğin yedi servisten geçtiğini ve birinde takıldığını log dosyasından bulmak imkansızdır. Distributed tracing, metrics, structured logging — bunlar geçişin ilk gününden itibaren yerleşmiş olmak zorunda. Sonradan eklenen gözlemlenebilirlik, her zaman eksiktir.

Peki nasıl yaklaşmalı?

1. Önce bounded context'leri çıkar — hangi alanın kime ait olduğunu netleştir.
2. En bağımsız kenardaki bir modülü ilk aday olarak seç (genelde rapor/analytics gibi).
3. Stranger fig yaklaşımıyla monolit ile paralel koştur, trafiği kademeli olarak yeni servise yönlendir.
4. Her adımda, geri dönebileceğinin emin ol — bir ayağını monolitte bırak.
5. Ekip sınırlarını da servisleriyle birlikte yeniden çiz.