Teknik Liderlik & Mimari
Monolitik Yapılardan Mikroservislere Geçişte Yapılan Ölümcül Hatalar ve Strangler Fig Paterninin Doğru Kullanımı
Problem Tanımı
Teknoloji dünyasında hızlı büyüme, çoğu zaman mevcut sistemlerin sınırlarını zorlar. Kullanıcı tabanınız genişledikçe, transaction sayınız arttıkça ve geliştirici ekibiniz büyüdükçe, başlangıçta sizi hızlı kılan "monolitik" (tek parça) yazılım mimariniz bir darboğaza dönüşür. Yeni bir özellik eklemek haftalar sürer, küçük bir veritabanı sorgusu hatası tüm platformun çökmesine neden olur, CI/CD pipeline'ları saatlerce bekletir. Bu noktada yönetim kurulu ve teknik liderler haklı bir refleksle mikroservis mimarisine geçiş kararı alırlar.
Ancak sorun, bu geçiş kararının kendisinde değil, uygulanış biçimindedir. Çoğu şirket, monolitik sistemin fişini bir gece çekip yerine yepyeni ve mükemmel çalışacağı varsayılan mikroservisleri koymaya çalışarak (Big Bang rewrite) operasyonel intihara kalkışır.
Piyasadaki Yanlış Yaklaşım
"Hadi her şeyi sıfırdan mikroservis olarak yeniden yazalım."
Bu yaklaşım, teknoloji endüstrisindeki en tehlikeli yanılgılardan biridir. Çoğu "ajans" veya tecrübesiz teknik ekip, müşterisine sıfırdan yepyeni bir sistem yazmayı teklif eder. Neden yanlış?
- İş Sürekliliğinin Kesilmesi: Yeni sistem yazılırken, mevcut sistemdeki acil iş ihtiyaçları (yeni özellikler) dondurulur. Rakipler ilerlerken şirket teknolojik bir şantiyeye hapsolur.
- Domain Knowledge Kaybı: Yıllar içinde monolitik sisteme yazılmış ince iş kuralları (edge cases) genellikle dokümante edilmemiştir. Sıfırdan yazılan sistem, bu kritik iş kurallarını atlar ve müşteri kayıplarına yol açar.
- Big Bang Dağıtımı (Deployment): İki sene süren geliştirme sonrası tek gecede geçiş yapılır ve ertesi sabah sistem kaçınılmaz olarak çöker, veri kayıpları yaşanır.
Teknik Analiz
Mikroservis mimarisi, kod satırlarıyla değil iş alanlarının (bounded contexts) doğru izole edilmesiyle ilgilidir. Conway Kanunu bize, sistem mimarilerinin şirketlerin iletişim yapılarını kopyaladığını söyler. Monolitik bir veri tabanını mikroservislere bölmeden sadece API'leri ayırmak, size mikroservis değil, "dağıtık bir monolit" (distributed monolith) verir. Bu durum, monolitik sistemin esnek olmama sorununa bir de ağ gecikmesi (network latency) ve karmaşık sunucu yönetimi sorunlarını ekler.
Sistemi parçalara ayırırken veri tabanındaki "Foreign Key" ilişkilerini API çağrılarına çevirmek, event-driven (olay güdümlü) asenkron mimariler kullanmamak, servisler arası sıkı bağlılık (tight coupling) yaratır. Geçiş sürecinde asıl olan kodu taşımak değil, "state"i (veriyi) güvenli şekilde ayırmaktır.
Doğru Sistem Yaklaşımı: Strangler Fig Pattern
Martin Fowler tarafından kavramsallaştırılan Strangler Fig Pattern, Avustralya'daki incir ağaçlarının büyüme stratejisinden ilham alır. Ağaç, mevcut büyük bir ağacın (monolit) gövdesine sarılarak büyür, zamanla kök salar ve en sonunda eski ağaç çürüyüp yok olduğunda yeni ve bağımsız bir yapı olarak ayakta kalır.
Teknoloji penceremizden bu şu anlama gelir: Sistemin tamamını değiştirmek yerine, bir "API Gateway" (Yönlendirici) konumlandırmak ve sadece seçilen spesifik bir modülü (örneğin sadece "Ödeme Sistemi"ni) yeni bir mikroservis olarak dışarı almaktır. Yeni gelen istekler API Gateway üzerinden, eğer ödeme ise yeni servise, diğer tüm işlemler ise eski monolite yönlendirilir.
Bu sayede risk sıfıra indirgenir. Yeni teknoloji yavaş ve güvenli bir şekilde parça parça eskisinin yerini alır.
Uygulama Adımları
Gerçek bir teknoloji partneri olarak, bu dönüşümü şu mimari adımlarla kurguluyoruz:
- Facade (API Gateway / Reverse Proxy) Entegrasyonu: Sistemin önüne, tüm trafiği karşılayacak NGINX, Kong veya AWS API Gateway gibi bir katman eklenir. İstemciler (Frontend / Mobil) arkada monolit mi mikroservis mi olduğunu bilmez.
- Domain-Driven Design (DDD) ile Sınırların Belirlenmesi: Koddan önce iş kuralları analiz edilir. "Sepet", "Kullanıcı", "Ödeme" sınırları (Bounded Contexts) netleştirilir. Ayrılması en kolay ve en bağımsız parça (low-hanging fruit) ilk hedef seçilir.
- Veri Tabanının Ayrıştırılması (Database per Service): En kritik adım burasıdır. Aynı anda iki yere (hem eski monolit DB'ye hem yeni mikroservis DB'ye) yazma işlemleri (Dual Write) yapılandırılarak veri senkronizasyonu sağlanır. Debezium gibi CDC (Change Data Capture) araçları kullanılarak Kafka/RabbitMQ üzerinden veriler asenkron olarak yeni yapıya taşınır.
- Trafiğin Kademeli Yönlendirilmesi (Canary Release): Gateway üzerinden trafiğin önce %5'i yeni servise yönlendirilir. Loglar, hata oranları ve metrikler (Prometheus/Grafana) izlenir. Sorun yoksa bu oran %20, %50 ve %100'e çıkarılır. Bir hata anında anında eski monolite (rollback) dönülebilir.
- Monolitten İlgili Parçanın Budanması: Trafik %100 yeni servise geçtiğinde ve veri akışı stabil olduğunda, eski monolitikteki ilgili kod blokları ve tablolar (dead code) temizlenir. İşlem sıradaki domain için tekrarlanır.
Sonuç & Stratejik Çıkarım
Ölçeklenebilir bir yapıya geçiş, devasa çaplı bir "yeniden yazma" projesi değil, mühendislik disiplini ve iş sürekliliği harmonisidir. Kurumlar, sistemlerini dönüştürürken "kod yazan" birilerine değil, veri güvenliğini, kesintisiz hizmeti ve maliyet verimliliğini yönetebilen "mimarlar" ile çalışmalıdır. Teknoloji çözüm ortağı olarak yaklaşımımız, işletmeyi asla duraklatmadan, tekerleği otobüs saatte 100 kilometre hızla giderken değiştirebilme stratejisine dayanır.
Mimarinizi Dönüştürme Vakti Geldi mi?
Mevcut monolitik sistemlerinizi sıfır kesintiyle modern mimarilere taşıyacak özel stratejinizi oluşturalım.