Yazılım dünyasında mikroservis kelimesi uzun süredir modernliğin eş anlamlısı gibi kullanılıyor. Pek çok ekip, sistemini küçük servislere bölmenin otomatik olarak daha ölçeklenebilir, daha hızlı ve daha dayanıklı bir ürün getireceğini varsayıyor. Gerçek ise daha nüanslıdır. Mikroservisler bazı sorunları çözerken yeni ve ciddi karmaşıklıklar da getirir. Bu yazı, acentelere yazılım sağlayan bir platformun mimari evrimini düşünürken monolitten mikroservise geçişin ne zaman anlamlı olduğunu ve bu geçişin nasıl güvenli yapılabileceğini tartışıyor.
Monolit kötü bir şey değildir
Monolit, bütün işlevlerin tek bir uygulama içinde birlikte geliştirilip birlikte yayınlandığı mimaridir. Ürünün erken aşamalarında bu yapı çoğu zaman en doğru tercihtir: Geliştirme hızlıdır, hata ayıklama kolaydır, veritabanı işlemleri tek bir yerde tutarlı biçimde yürür ve operasyon yükü düşüktür. Müşteri kartı, teklif ekranı ve poliçe kaydı aynı kod tabanında yaşadığında, bir özelliği uçtan uca değiştirmek tek bir yayınla mümkündür.
Sorunlar genellikle büyümeyle başlar. Ancak büyüme, tek başına bölme gerekçesi değildir. Bölmeden önce sorunun gerçekten mimariden mi, yoksa kod düzeninden mi kaynaklandığını anlamak gerekir.
Ayrıştırma ihtiyacına işaret eden sinyaller
Aşağıdaki belirtilerin birkaçı bir arada görülüyorsa, belirli parçaların ayrı servislere taşınmasını değerlendirmek anlamlı olabilir:
- Farklı ölçeklenme ihtiyaçları: Teklif motoru yoğun saatlerde çok fazla kaynak tüketirken müşteri yönetimi ekranları hafif bir yükle çalışıyor. Bütün uygulamayı teklif motoru için büyütmek kaynak israfına yol açıyor.
- Farklı teknoloji gereksinimleri: Bir bileşen, örneğin tarayıcı tabanlı otomasyon veya uzun süren arka plan işleri, ana uygulamanın çalışma ortamına uymayan bir teknoloji gerektiriyor.
- Hata izolasyonu ihtiyacı: Bir bileşendeki bellek sızıntısı veya çökme, ilgisiz ekranları da erişilemez hale getiriyor.
- Yayın çatışmaları: Farklı ekipler aynı kod tabanında çalışıyor ve bir ekibin değişikliği diğerinin yayınını sürekli bekletiyor.
Bu listede "mikroservis daha moderndir" gibi bir madde yoktur. Ayrıştırma kararı, somut ve ölçülebilir bir soruna dayanmalıdır.
Ara yol: Modüler monolit
Birçok sorun, sistemi ağ üzerinden haberleşen servislere bölmeden de çözülebilir. Modüler monolitte uygulama tek bir dağıtım birimi olarak kalır ama içeride net sınırlarla ayrılmış modüllerden oluşur. Her modül kendi verisinin sahibidir ve diğer modüllerle yalnızca tanımlı arayüzler üzerinden konuşur. Bir modülün başka bir modülün tablolarına doğrudan sorgu atması yasaktır.
Bu yaklaşımın iki büyük faydası vardır. Birincisi, kod tabanının karmaşıklığı mikroservislerin operasyon yükü olmadan azalır. İkincisi, ileride gerçekten bir modülü ayrı servise taşımak gerektiğinde sınırlar zaten çizilmiş olduğu için geçiş çok daha kolay olur. Modüler monolit, mikroservise giden yolun en güvenli ilk adımıdır.
Sınırları nereden çizmeli?
Servis veya modül sınırları teknik katmanlara göre değil, iş alanlarına göre çizilmelidir. "Veritabanı servisi" veya "doğrulama servisi" gibi teknik ayrımlar, her özellik değişikliğinde birden fazla servisin aynı anda değiştirilmesini gerektirir. Acente yazılımı için doğal iş alanı sınırları şöyle olabilir:
- Kimlik, oturum ve yetkilendirme
- Müşteri ve iletişim yönetimi
- Teklif motoru ve sigorta şirketi entegrasyonları
- Poliçe ve yenileme takibi
- Tahsilat, abonelik ve faturalama
- Bildirim ve iletişim kanalları
- Raporlama ve analitik
Teklif motoru içinde de trafik, kasko ve DASK akışları ayrı alt modüller olarak ele alınabilir; çünkü her birinin girdi doğrulaması ve şirket tarafındaki sorgu akışı farklıdır.
Kademeli geçiş: Boğan incir yöntemi
Bütün sistemi bir seferde yeniden yazmak, yazılım projelerinin en riskli girişimlerinden biridir. Bunun yerine "boğan incir" (strangler fig) olarak bilinen kademeli yöntem önerilir. Adını, bir ağacın etrafını zamanla saran ve sonunda onun yerini alan incir türünden alır. Uygulama adımları şöyledir:
- Monolitin önüne bir yönlendirme katmanı konur. Başlangıçta bütün istekler monolite gider.
- Ayrıştırılacak ilk iş alanı seçilir. Genellikle en bağımsız ve en net ölçeklenme ihtiyacı olan alan, örneğin teklif motoru, iyi bir adaydır.
- Yeni servis geliştirilir ve ilgili istekler yönlendirme katmanında yeni servise çevrilir.
- Bir süre iki yapı yan yana çalışır, sonuçlar karşılaştırılır.
- Yeni servis güven kazandıktan sonra monolitteki eski kod kaldırılır.
Her adım geri alınabilir olduğu için risk sınırlı kalır ve ürün geliştirme durmadan devam eder.
Mikroservislerin gizli maliyetleri
Ayrıştırma kararı verilirken şu maliyetler de hesaba katılmalıdır:
- Dağıtık veri tutarlılığı: Tek veritabanı işlemiyle yapılan işler artık birden fazla servise yayılır; saga veya outbox gibi desenler gerekir.
- Ağ güvenilmezliği: Fonksiyon çağrısı olan işlem artık ağ çağrısıdır; zaman aşımı, yeniden deneme ve devre kesici ihtiyacı doğar.
- Gözlemlenebilirlik: Bir isteğin birden fazla servisten geçen yolunu izlemek için dağıtık izleme altyapısı kurmak gerekir.
- Operasyon yükü: Her servisin dağıtımı, izlenmesi, güvenlik güncellemeleri ve yapılandırması ayrı ayrı yönetilir.
Veritabanını ayırmak: En zor adım
Kodu ayrı bir servise taşımak görece kolaydır; asıl zorluk verinin ayrılmasıdır. Yeni servis hâlâ monolitin veritabanındaki tabloları doğrudan okuyorsa gerçek bir ayrışma gerçekleşmemiştir. Bu durumda iki uygulama aynı şemaya bağımlı kalır ve bir tablo değişikliği ikisini birden etkiler. Sağlıklı bir geçişte önce yeni servisin kendi veri deposu oluşturulur, ardından veri bir senkronizasyon süreciyle taşınır ve son aşamada monolitin bu tablolara erişimi kaldırılır. Geçiş süresince hangi sistemin verinin asıl sahibi olduğu her an net olmalıdır.
InsureHub'ın yaklaşımı
InsureHub, sigorta acentelerine yazılım sağlayan bir platform olarak bütünü mikroservislere bölmek yerine ayrıştırmayı gerçek ihtiyaç olan yerlerde uygular. Uzun süren ve farklı kaynak profiline sahip teklif motoru, ana web uygulamasından ayrı çalışan bir servis olarak ele alınır; Acente CRM ve yönetim ekranları ise tutarlı ve hızlı geliştirilebilen bir yapıda kalır. Bu denge, sigorta teklif programı tarafındaki yoğunluğun diğer ekranları etkilememesine yardımcı olur.
Kendi teknik yol haritanızı değerlendirirken sorulacak soru "mikroservise geçmeli miyiz?" değil, "hangi somut sorunu çözmek istiyoruz ve bunun en basit çözümü nedir?" olmalıdır.