Monolit'ten Mikroservise: Ne Zaman ve Nasıl?

"Mikroservislere geçmemiz lazım" — son 5 yılda yazılım ekiplerinden en çok duyduğumuz cümle. Çoğu zaman bunu söyleyen ekibin gerçek sorunu mikroservislerin çözeceği bir sorun değil. Belki deploy yavaş, belki büyük takım koordinasyonu zor, belki kod tabanı kaotik. Mikroservis bu sorunların hiçbirini sihirli şekilde çözmez; üstelik yenilerini ekler.

Mikroservise geçmek için 3 gerçek sebep vardır: (1) Farklı bileşenlerin farklı ölçekleme ihtiyaçları var — bir bileşen 100x trafik alırken diğeri sabit. (2) Bağımsız deploy kritik — bir takım diğerini beklemeden yeni özellik çıkarmalı. (3) Teknoloji çeşitliliği gerekli — bir servis Python'da ML, diğeri Go'da yüksek performans gerektiriyor. Bu sebepler yoksa, iyi yapılandırılmış bir monolit daha mantıklıdır.

Geçiş için altın kural: Strangler Fig deseni. Monoliti bir gecede kesmeye çalışmayın. Önce bir bileşen seçin (genellikle en az bağımlı, en çok ölçekleme ihtiyacı olan), ayrı bir servis olarak dışarı çıkarın, monolit ile API üzerinden konuşturun. Trafiği kademeli olarak yönlendirin. Bu döngüyü 6-12 ay içinde 4-5 servis için tekrarlayın. Big-bang göç projelerinin %70'i başarısız oluyor.

Bir e-ticaret müşterimizde, başlangıçta bir Ruby on Rails monoliti vardı; ekip 35 kişiye çıkmıştı, deploy günde 1 kez ancak yapılabiliyordu. Önce ödeme servisini, sonra stok servisini, sonra arama altyapısını ayırdık. 18 ayda 7 mikroservis ile tamamen modüler bir sisteme dönüştük. Deploy günde 50+ kez yapılıyor, ekipler bağımsız çalışıyor. Ama bu geçiş, sadece gerçek sorunlar olduğu için başarılı oldu — moda olduğu için değil.