Bulut Göçü & Uygulama Modernizasyonu: Cloud Migration

Bakımı zorlaşan eski uygulama, kapasitesi dolmuş on-prem sunucu odası, her donanım yenilemesinde gelen büyük yatırım kalemi, Türkiye'deki orta ve büyük ölçekli işletmelerin teknoloji altyapısında çok yaygın bir tablo. Yıllar içinde büyümüş bir monolit uygulama tek bir sunucuda çalışıyor; onu yazan ekip çoktan dağılmış, kimse dokunmaya cesaret edemiyor, en küçük değişiklik bile haftalar sürüyor. Sunucular yaşlanıyor, UPS ve klima maliyeti birikiyor, yedekleme stratejisi "umarım çalışır" seviyesinde. Talep arttığında ölçeklenmek için yeni fiziksel sunucu sipariş edip aylarca beklemek gerekiyor. Dijital dönüşümün altyapı tarafında ilk müdahale ettiğimiz alan budur: on-prem ve eski monolitten çıkıp, riski yöneterek kademeli geçen, ölçeklenebilir, gözlemlenebilir ve maliyeti kontrol altında olan bir bulut mimarisine taşınmak.

Yaklaşımımız

Bulut göçü projelerinde işe kod yazarak değil, mevcut sistemin gerçek envanterini çıkararak başlamayı öneriyoruz. Hangi uygulamalar çalışıyor, birbirlerine nasıl bağlılar, hangi veritabanları var, trafiğin gerçek deseni ne, bunları çıkarmadan atılan her adım sonradan sürpriz üretiyor. Bu envanter üzerinden her iş yükü için 6R çerçevesinde bir karar veriyoruz: rehost (olduğu gibi taşı), replatform (küçük dokunuşlarla iyileştir), refactor (mimariyi yenile), repurchase (hazır SaaS'a geç), retain (şimdilik on-prem tut) ya da retire (kapat). Her uygulamayı refactor etmek zorunda değiliz; çoğu durumda doğru karar rehost ile hızlı taşıyıp, gerçek darboğaz neredeyse oraya yatırım yapmaktır. Hangi uygulamanın hangi muameleyi hak ettiğini iş değeri ve risk dengesine göre belirliyoruz.

İkinci kritik karar strangler-fig ile kademeli geçiş. Eski monoliti bir gecede mikroservise çevirmeye çalışan "büyük patlama" projeleri Türkiye'de de dünyada da en sık başarısız olan yaklaşım. Bunun yerine monolitin önüne bir API gateway / reverse proxy koymayı öneriyoruz; ardından her seferinde tek bir iş yeteneğini (fatura, kullanıcı yönetimi, raporlama gibi) ayrı bir servise çıkarıp trafiği parça parça yönlendiriyoruz. Eski kod, çıkarılan parça stabil çalışana kadar yedek olarak kalıyor. Böylece her adım küçük, test edilebilir ve geri alınabilir; iş süreçleri aylarca süren bir yeniden yazıma kilitlenmiyor. Bu yaklaşımın güzelliği, ilk haftadan itibaren üretimde değer görmeniz. Tüm sistemin bitmesini beklemiyorsunuz.

Üçüncü katman konteynerleştirme ve ölçeklenebilirlik. Uygulamaları Docker ile konteynerleştirip Kubernetes üzerinde çalıştırmayı öneriyoruz; böylece "benim makinemde çalışıyor" sorunu ortadan kalkıyor, dağıtım her ortamda aynı oluyor. Kubernetes HPA (Horizontal Pod Autoscaler) ile yük arttığında otomatik ölçekleniyor, düşük trafikte küçülüyor. Sabit büyük sunucu kirası yerine gerçek kullanım kadar ödeme. Altyapının tamamını Terraform ile kod olarak (IaC) yönetiyoruz; her kaynak versiyonlanmış, gözden geçirilebilir ve tekrar üretilebilir hale geliyor, "elle kurulmuş ve kimsenin nasıl olduğunu bilmediği" sunucu kalmıyor. AWS, Azure ya da GCP arasındaki seçimi mevcut yetkinliğinize, veri yerelliği gereksinimlerinize ve maliyet profilinize göre birlikte yapıyoruz.

Son katman CI/CD, gözlemlenebilirlik ve güvenli dağıtım. Her değişiklik GitHub Actions ya da GitLab CI ile otomatik test edilip dağıtılıyor; gece yapılan riskli manuel sürümler yerine, gün içinde küçük ve sık dağıtımlar geliyor. Prometheus + Grafana ile metrikleri, OpenTelemetry ile dağıtık izleri (distributed tracing) topluyoruz; bir istek hangi servislerden geçti, nerede yavaşladı net görünüyor. Üretime çıkışta blue-green ya da canary deploy kullanıyoruz: yeni sürüme trafiği önce yüzde 5, sorun yoksa yüzde 25, sonra tam açıyoruz. Bir aksilikte saniyeler içinde eski sürüme dönülebiliyor. Hedefimiz: dağıtım sıradan ve sıkıcı bir işlem olsun, herkesin nefesini tuttuğu bir gece operasyonu değil.

Tercih Ettiğimiz Teknolojiler

Tipik tercihlerimiz aşağıdaki gibi; mevcut yığınınıza, bulut sağlayıcı tercihinize ve iş yükü profilinize göre uyarlıyoruz.