Mikroservis mimarisi nedir ve ne zaman tercih edilmeli?

05 Kas 20:21

Geçen sene startup’ta monolitik bir backend’i mikroservislere taşıma macerası yaşadım, kanka. Başta “bütün fonksiyonlar aynı kod tabanında, neyse bir gün birden çok ekip aynı dosyada çalışıyor” diyorduk, ama sürüm çakışmaları ve ölçekleme sıkıntıları çığ gibi büyüdü. Mikroservise geçince, ekiplerimiz “kredi”, “ödeme” ve “kullanıcı” gibi alanlara göre bölündü; her takım kendi veri tabanını ve CI/CD pipeline’ını yönetti. Avantajı, bir servis üzerindeki değişikliği diğerlerini etkilemeden deploy edebildik, ayrıca trafik yoğunluğu olan ödeme servisini bağımsız olarak ölçekleyebildik. Dezavantajı ise, dağıtık izleme ve log toplama işini “her servisin ayrı bir evrende” gibi düşünmek zorunda kaldık; servisler arası ağ gecikmesi ve hata yönetimi de başımızın belası oldu. Geçişte en kritik nokta bence “sözleşme yönetimi ve gözlemlenebilirlik” oldu; API contract’larını sıkı tutmazsak versiyon çakışmaları aniden production’da patlar. Ayrıca DevOps ekibimiz tek bir pipeline’dan çok, “her servis için bir pipeline + merkezi monitoring” modeline geçmek zorunda kaldı; bu da altyapı otomasyonunu (Terraform, Helm) ve servis mesh (Istio) gibi araçları zorunlu kıldı. Sonuçta, yüksek trafiğe sahip, farklı ekiplerin aynı anda bağımsız çalışması gerektiği senaryolarda mikroservis mantıklı; ama küçük bir ekip ve tek bir domain için monolitik kalmak, bakım maliyetini düşük tutar. Valla, geçişi planlarken “sıradan bir refactor değil, bir organizasyon dönüşümü” olarak görmek lazım.