Yazılım Modernizasyonu: Monolit mi Mikroservis mi?

Yeniden yazma talebini ölçülebilir probleme çevirin

“Yazılım çok eski” ifadesi yaş belirtir; hangi problemin çözüleceğini söylemez. Sipariş ekranı mı yavaşlıyor? Yeni bir fiyat kuralını değiştirmek mi zor? Her dağıtımda ilgisiz özellikler mi etkileniyor? Önce bu soruları gerçek iş kayıtlarıyla cevaplayın. Birbirinden farklı problemler için aynı büyük dönüşüm projesini önermek, gereksiz kapsam yaratabilir.

Önerilen başlangıç belgesinde kritik akış, gözlenen sorun, iş etkisi, mevcut ölçüm ve kabul edilebilir hedef bulunsun. Ölçüm yoksa bunu açıkça yazın. “Kullanıcılar şikâyet ediyor” başlangıç sinyalidir; tek başına hangi bileşenin değişeceğini belirlemez. İşletmenin kaybettiği zamanı, tekrar yaptığı işi ve destek ekibinin hangi kayıtları düzelttiğini inceleyin.

Bu rehberdeki varsayımsal üretici, bayi siparişlerini ve fiyatlarını tek uygulamada yönetiyor. Raporların yoğun saatlerde sipariş işlemlerini zorladığını düşünüyor. Bu düşünce henüz ölçülmüş kök neden değil. İlk iş bütün sistemi bölmek değil, rapor ve sipariş akışlarının kaynak kullanımını inceleyen sınırlı bir teşhis çalışmasıdır.

Modüler monolit ile dağınık tek uygulamayı ayırın

Tek parça dağıtılan uygulama, bütün kodun birbirine karışmak zorunda olduğu anlamına gelmez. Önerilen modüler yaklaşımda sipariş, fiyatlandırma, müşteri ve raporlama sorumlulukları belirgin sınırlar içinde tutulur. Başka modülün verisine kontrolsüz erişim yerine tanımlı arayüzlerle ilişki kurulması hedeflenir. Bu sınırların test ve ekip kurallarıyla korunması gerekir.

Mikroservislerde bağımsız dağıtım bir avantaj olabilir; ancak ağ iletişimi, veri tutarlılığı ve işletim karmaşıklığı ek değerlendirme gerektirir. Microsoft’un mimari rehberi bu yarar ve ödünleşimleri birlikte ele alır. “Servis sayısı arttı, kalite arttı” sonucu çıkarılamaz. [1]

Örnek üreticide raporlama için ayrı okuma yapısı veya ayrı çalışan yeterli olabilir. Başka bir projede bağımsız ekiplerin farklı hızlarda değiştirdiği iş alanlarını ayırmak daha anlamlı olabilir. Her iki durumda da mimari karar, somut kısıt ve beklenen fayda üzerinden verilmelidir; kullanıcı sayısına bakıp otomatik karar üretilmemelidir.

Karar tablosunu bir başlangıç aracı olarak kullanın

Bu tablo otomatik seçim algoritması değildir. Aynı kuruluşta farklı alanlar için farklı çözümler seçilebilir. Bir bölümün bağımsız ölçek gerektirmesi, bütün uygulamanın aynı anda mikroservise taşınması gerektiğini göstermez. Kapsamı küçültmek bazen riski yönetmenin en doğrudan yoludur.

Ajans teklifinde yalnız hedef mimariyi değil, geçiş boyunca yaşanacak mimariyi de isteyin. Kullanıcılar eski ve yeni parçaları birlikte kullanırken kimlik, oturum, raporlama ve hata takibi nasıl işleyecek? Geçiş döneminin maliyeti ve destek yükü, nihai çözümün çizimi kadar önemlidir.

Önce mevcut davranışı belgeleyin

Eski sistemde dokümanda yazmayan ama günlük işi ayakta tutan kurallar bulunabilir. Örneğin belirli müşteriye özel fiyat önceliği, onay sonrası değişiklik sınırı veya geçmiş siparişte korunan ürün adı. Yeniden yazma sırasında bunların tesadüfen kaybolmaması için temsilî giriş ve çıktı örneklerini toplayın.

Bu çalışma eski hataları sonsuza kadar korumak anlamına gelmez. “Uyumluluk için korunacak”, “bilinçli değiştirilecek” ve “henüz açıklanamayan” davranışları ayırın. Değiştirilecek davranışın işletme onayı ve test beklentisi olsun. Böylece yeni sistemde farklı sonuç çıktığında bunun hata mı, kabul edilmiş değişiklik mi olduğu anlaşılır.

Gerçek müşteri verisini geliştirici bilgisayarlarına kontrolsüz dağıtmayın. Örnekleri uygun şekilde anonimleştirin veya aynı kuralı temsil eden sentetik kayıtlar oluşturun. Amaç veri hacmini kopyalamak değil, iş davranışını test edilebilir hale getirmektir.

Aşamalı geçişi bir yönlendirme kararı olarak tasarlayın

Strangler Fig yaklaşımı, eski sistemin işlevlerini zaman içinde yeni bileşenlere geçirirken isteklerin uygun uygulamaya yönlendirilmesini ele alır. Microsoft, aşamalı yenilemenin yanında yönlendirme katmanının darboğaz veya hata noktası olabileceğine de dikkat çeker. Bu nedenle geçiş katmanı ayrıca tasarlanmalıdır. [2]

Örnek projede ilk aday, veri değiştirmeyen bir ürün arama akışı olabilir. Belirli bir kullanıcı grubunda yeni akış denenir; sonuçlar tanımlı kurallarla karşılaştırılır. Ardından daha riskli yazma işlemleri ayrı geçiş planıyla ele alınır. Bu sıralama bir öneridir; her proje için arama ilk adım olmak zorunda değildir.

Karşılaştırma yaparken aynı isteği iki sisteme göndermenin yan etkisini düşünün. Bir okuma sonucunu karşılaştırmak ile iki ayrı sistemde sipariş oluşturmak aynı şey değildir. Yeni sistem gölge değerlendirme için kullanılıyorsa gerçek bildirim, ödeme veya stok hareketi üretmediği doğrulanmalıdır.

Veri sahipliği geçişin en kritik anlaşmasıdır

Bir müşteri kaydını hem eski hem yeni sistem değiştirebiliyorsa, hangi değerin esas alınacağı belirli olmalıdır. Her varlık için okuma kaynağı, yazma sahibi, senkronizasyon yönü ve hata çözümü yazın. “İki tarafı senkron tutacağız” ifadesi, çakışma kuralı olmadan eksik bir plandır.

Şema değişikliklerini de geçiş dönemine göre planlayın. Yeni sürümün beklediği alanı eklemek, eski sürümün çalışmasını bozmamalıdır. Eski alanın kaldırılması için ona bağımlı kodların ve entegrasyonların devreden çıktığı doğrulanmalıdır. Uygulama sürümünü geri almak, silinmiş veya anlamı değiştirilmiş veriyi otomatik geri getirmez.

Bu nedenle geri dönüş belgesi uygulama, veritabanı ve dış sistem etkilerini ayrı ele alsın. Geçiş sırasında oluşan yeni siparişler eski sisteme nasıl aktarılacak? Aktarılamayan bir kayıt varsa kullanıcı ne görecek? Bu sorulara prova ortamında yanıt verilmeden “tek tıkla geri döneriz” sözü yeterli değildir.

Kısa bir mimari karar kaydı hazırlayın

Önerilen kayıt şu alanlardan oluşur: problem, kısıtlar, seçenekler, seçilen yaklaşım, beklenen fayda, kabul edilen maliyet, test planı ve yeniden değerlendirme koşulu. Örneğin “raporlama ayrı çalışan olarak ayrılıyor; sipariş verisinin yazma sahibi değişmiyor” kararı belirli bir sınır çizer.

Yeniden değerlendirme koşulunu belirsiz büyüme söylemi yerine gözlenebilir duruma bağlayın. Ekiplerin ortak dağıtım bekleme süresi, belirli işin kuyrukta kalması veya yeni özellik değişikliğinin etki alanı takip edilebilir. Hedefler projenin ölçülen durumuna göre seçilmeli; başka firmanın sayıları doğrudan taşınmamalıdır.

Eski sistemi tamamen yeniden yazmak hiç doğru değil mi?

Doğru olabilir. Ancak mevcut davranışın kapsamı, veri geçişi ve paralel kullanım maliyeti anlaşılmalıdır. Yeniden yazma seçeneği diğer seçeneklerle aynı iş hedefi üzerinden karşılaştırılmalıdır; yalnızca yeni teknoloji vaadiyle seçilmemelidir.

Mikroservis olmadan büyük ürün geliştirilebilir mi?

Mimari uygunluğu tek bir büyüklük etiketi belirlemez. İş alanlarının ilişkisi, ekibin yapısı, yükün dağılımı ve işletim gereksinimleri değerlendirilmelidir. İyi modernizasyon, en fazla parçayı üretmek değil; gerekli değişikliği daha anlaşılır ve yönetilebilir hale getirmektir.