"Basit bir değişiklik" neden altı hafta sürüyor?
Kamu kurumlarıyla çalışırken sıkça karşılaştığımız bir senaryo var: bir formdaki tek bir alanı değiştirmek, ekibin üç farklı modülü test etmesini, beş farklı onay sürecinden geçmesini ve haftalarca sürecek bir regresyon testine girmesini gerektiriyor.
Sorunun kaynağı genelde ekibin yetkinliği değil. Sorun, yıllar içinde büyümüş, her yeni ihtiyaç için üzerine bir kat daha eklenmiş monolitik bir sistem. Tek bir kod tabanında, tek bir veritabanında, birbirine sıkı sıkıya bağlı düzinelerce modül barındıran bu yapılarda, en küçük değişiklik bile sistemin tamamını riske atıyor.
Bu durum kamu kurumlarında özellikle ağırlaşıyor: düzenleyici onay süreçleri, sınırlı bütçe döngüleri ve yüksek hizmet kesintisi maliyeti, "büyük patlama" tarzı bir yeniden yazım projesini hem riskli hem de siyasi olarak savunulamaz kılıyor.
Microservise geçişin yanlış başlangıcı: hepsini birden değiştirmek
Birçok kurum microservis mimarisine geçmeye karar verdiğinde, ilk dürtü "sistemin tamamını yeniden yazalım" oluyor. Bu yaklaşım iki nedenle başarısız oluyor: birincisi, mevcut sistemin tüm işlevini durdurmadan yeniden inşa etmek pratikte mümkün değil; ikincisi, büyük bütçeli ve uzun vadeli bir proje, bir sonraki bütçe döngüsünde veya yönetim değişikliğinde iptal riski taşıyor.
Bizim önerdiğimiz ve pratikte sonuç veren yaklaşım, dört aşamalı kademeli bir geçiş.
Aşama 1: Keşif — neyi, neden böldüğünüzü bilin
Geçişe başlamadan önce yapılması gereken iş, kod yazmak değil haritalama. Mevcut monolitin hangi modülleri birbirinden bağımsız çalışabilir, hangileri sıkı bağımlı? Hangi modül en sık değişiyor ve bu nedenle en fazla risk taşıyor? Hangi modül en yüksek trafiği alıyor ve ölçeklendirme baskısı en çok orada hissediliyor?
Bir kamu kurumu için yürüttüğümüz keşif çalışmasında, vatandaş başvuru modülünün sistemin geri kalanından bağımsız çalışabilecek en net sınırlara sahip olduğunu ve aynı zamanda en sık değişen modül olduğunu belirledik. Bu iki özellik, onu ilk ayrıştırma adayı yaptı — bağımsızlığı geçişi kolaylaştırıyor, sık değişmesi ise ayrıştırmanın faydasını hemen görünür kılıyor.
Aşama 2: Pilot modül — küçük, görünür, geri alınabilir
İlk microservis, en kritik modül değil, en öğretici modül olmalı. Amaç, ekibe yeni mimariyle çalışma deneyimi kazandırmak ve kurumun üst yönetimine "bu yaklaşım işe yarıyor" diye gösterebileceği somut bir kanıt üretmek.
Pilot modül seçilirken üç kritere baktık: sistemin geri kalanından bağımsız çalışabilmesi, hizmet kesintisi durumunda etkisinin sınırlı kalması, ve sonuçlarının (performans, geliştirme hızı) ölçülebilir olması. Vatandaş başvuru modülü bu üç kriteri karşıladığı için pilot olarak seçildi ve monolitten ayrıştırılarak bağımsız bir servis haline getirildi — eski sistemle paralel çalışacak şekilde, geri alma planı her zaman hazır tutularak.
Aşama 3: Kademeli geçiş — strangler fig deseni
Pilot başarılı olduktan sonra, geri kalan modüller için "strangler fig" (boğan incir) deseni uygulanıyor: yeni trafik kademeli olarak monolitten yeni servislere yönlendiriliyor, monolit aynı anda hem eski hem yeni mimariyle birlikte çalışmaya devam ediyor. Hiçbir noktada sistem tamamen durdurulup yeniden başlatılmıyor.
Bu yaklaşımın kamu kurumları için kritik avantajı şu: her aşama bağımsız olarak onaylanabilir, bütçelendirilebilir ve gerektiğinde durdurulabilir. Bir bütçe döngüsünde üç modül ayrıştırılır, sonraki döngüde ekip ve bütçe el verdiğince devam edilir. Geçiş, tek bir büyük proje yerine sürdürülebilir bir program haline geliyor.
Aşama 4: Ekip eğitimi — mimari değişmeden önce alışkanlık değişmeli
En çok atlanan ve en çok geri tepen aşama bu. Microservis mimarisi, monolitik geliştirmeden farklı bir zihniyet gerektiriyor: servisler arası iletişim, dağıtık veri yönetimi, bağımsız dağıtım (deployment) süreçleri. Bu yetkinlikler olmadan kurulan microservisler, "dağıtık monolit" denilen ve eski sorunları yeni bir karmaşıklık katmanıyla birleştiren bir yapıya dönüşüyor.
Kamu kurumlarında bu riski azaltmak için pilot aşamasında ekibe doğrudan mentorluk yapılması, geçiş hızından daha belirleyici oluyor. Eğitim yatırımı yapılmadan hızlandırılan geçişler, kısa vadede "tamamlandı" görünse de orta vadede bakım yükü olarak geri dönüyor.
Büyük patlamadan kaçının, programı kurumsallaştırın
Monolitten microservise geçiş, kamu kurumları için bir proje değil bir program olarak ele alınmalı — başlangıcı ve bitişi net olan değil, her bütçe döngüsünde ölçülebilir ilerleme gösteren bir yapı.
Keşifle başlayan, pilotla kanıtlanan, kademeli geçişle ölçeklenen ve ekip eğitimiyle sürdürülebilir kılınan bu dört aşama, hizmet kesintisi riskini en aza indirirken kurumun yazılım geliştirme hızını gözle görülür şekilde artırıyor. Sabırsızlık burada en büyük risk; doğru sıra ise en güvenilir garanti.