Buluta geçiş, yalnızca sunucuları başka bir ortama taşımaktan ibaret değildir. Asıl mesele, iş yüklerinin nasıl çalıştığını anlayıp buna uygun mimariyi seçmektir. Aynı uygulama, şirket içi yapıda kabul edilebilir maliyetle çalışırken bulutta gereksiz harcama yaratabilir. Tersi de mümkündür; yıllardır performans sorunu yaşayan bir sistem, doğru servis ayrıştırması ve otomasyon sayesinde daha esnek hale gelebilir.
Başarılı bir geçişte üç eksen öne çıkar: maliyet kontrolü, güvenlik gereksinimleri ve ölçeklenebilirlik ihtiyacı. Örneğin ayda 2 kez yoğun trafik alan bir B2B sipariş portalı ile saniyede sabit işlem yapan bir ERP modülü, aynı altyapı yaklaşımını gerektirmez. Burada verilecek karar yalnızca teknik ekipleri değil; operasyonu, bütçeyi ve denetim süreçlerini de etkiler.
İyi bir strateji, “hangi bulut sağlayıcısı?” sorusundan da önce başlar. İlk olarak mevcut tablo netleştirilmelidir. Hangi uygulama kaç kullanıcıya hizmet veriyor, hangi veriler regülasyon açısından hassas, kesinti toleransı kaç dakika, bağımlılıklar neler? Bu sorular yanıtlanmadan yürütülen buluta geçiş projeleri, çoğu zaman taşıma sonrasında yeniden mimari kurma ihtiyacı doğurur.
Buluta geçiş öncesi mevcut durum nasıl analiz edilir?
İlk adım, envanter çıkarmaktır. En az şu 4 başlık dokümante edilmelidir: uygulamalar, veri tabanları, entegrasyonlar, altyapı bağımlılıkları. Buradaki amaç yalnızca liste yapmak değildir; her bileşenin iş üzerindeki etkisini ölçmektir. Örneğin bir üretim planlama uygulaması 15 dakika durduğunda operasyon etkileniyorsa, bu bilgi mimari kararı doğrudan belirler.
Analiz sırasında şu somut veriler toplanmalıdır:
- CPU, RAM, disk ve ağ kullanımının en az 30 günlük ölçümü
- Yoğun saatlerdeki eşzamanlı kullanıcı sayısı
- Uygulama başına veri büyüklüğü ve aylık artış miktarı
- RPO ve RTO hedefleri. Örneğin RTO: 1 saat, RPO: 15 dakika
- Mevcut lisans bağımlılıkları ve üçüncü taraf entegrasyonları
30 günlük veri, çoğu senaryoda başlangıç için yeterlidir; mevsimsel yük yaşayan yapılarda ise 90 günlük ölçüm daha sağlıklı sonuç verir. E-ticaret, saha servis veya kampanya odaklı platformlarda bu fark kritik önem taşır. Çünkü ortalama kullanım, kapasite planlaması açısından yanıltıcı olabilir.
İş yüklerini sınıflandırmak neden önemlidir?
Her sistemi aynı sepete koymak, maliyetli bir hatadır. Genellikle iş yükleri şu şekilde sınıflandırılır: sabit yük taşıyan uygulamalar, ani trafik artışı yaşayan sistemler, regülasyona tabi veri işleyen yapılar, eski teknoloji bağımlılığı bulunan uygulamalar. Örneğin .NET Framework üzerinde çalışan, yerel dosya paylaşımı kullanan bir iç operasyon uygulaması ile konteyner tabanlı yeni bir müşteri portalı aynı geçiş modeliyle ele alınmamalıdır.
Bu sınıflandırma, hangi sistemin önce taşınacağını da belirler. Düşük riskli ve bağımlılığı az olan uygulamalar ilk dalga için uygundur. Kritik ERP çekirdeği veya üretim hattına bağlı servisler ise çoğu durumda daha sonraya bırakılır.
Hangi bulut mimarisi hangi senaryoda daha doğru?
Buluta geçişte en sık karşılaşılan seçenekler public cloud, private cloud ve hibrit mimaridir. Tek bir “en doğru” model yoktur. Karar; veri hassasiyeti, performans beklentisi ve yönetim modeline göre verilir.
Public cloud: esneklik ve hızlı ölçek ihtiyacı için
Kampanya dönemlerinde 3 kat trafik artışı yaşayan bir B2B platform düşünelim. Böyle bir platform için otomatik ölçeklenebilen public cloud altyapısı mantıklıdır. Trafik düştüğünde kaynaklar azaltılabilir. Yalnız burada maliyetin kontrolsüz büyümemesi için autoscaling sınırları, log saklama süreleri ve veri çıkış maliyetleri baştan planlanmalıdır.
Public cloud; web uygulamaları, API servisleri, mobil arka uçları, SaaS ürünleri ve analitik iş yükleri için sık tercih edilir. Dakikalar içinde ortam kurulabilmesi önemli bir avantaj sağlar. Yine de “kurması kolay” olan yapıların “yönetmesi kolay” olduğu varsayılmamalıdır.
Private cloud: sıkı kontrol ve özel gereksinimler için
Bazı şirketlerde verinin lokasyonu, ağ segmentasyonu veya donanım düzeyinde ayrışma zorunlu olabilir. Finans, sağlık, savunma bağlantılı süreçler ya da kurum içi denetim baskısının yüksek olduğu yapılarda private cloud yaklaşımı öne çıkar. Burada kaynak esnekliği public cloud kadar yüksek olmayabilir; buna karşılık kontrol seviyesi artar.
Örneğin 7/24 çalışan bir fabrika üretim izleme sistemi, gecikmeye hassassa ve tesisteki OT ağıyla yakın çalışıyorsa, iş yükünün bir bölümünü kurum içinde tutmak daha doğru olabilir.
Hibrit mimari: pratikte en sık görülen yaklaşım
Birçok işletme için en gerçekçi seçenek hibrit yapıdır. Müşteri arayüzü ve raporlama servisleri bulutta çalışırken, kritik veri tabanı veya düşük gecikme gerektiren çekirdek servisler kurum içinde kalabilir. Özellikle eski sistemlerin tamamen yeniden yazılmasının 9 ila 18 ay sürebildiği projelerde hibrit geçiş, riski azaltır.
Bu yaklaşımda ağ tasarımı kritik hale gelir. VPN, özel hat, kimlik federasyonu ve merkezi loglama doğru kurgulanmazsa hibrit mimari beklenen faydayı sağlamaz.
Maliyet hesabı yapılırken nelere bakılmalı?
Buluta geçişte en sık görülen yanılgı, yalnızca sanal sunucu fiyatlarına bakmaktır. Oysa toplam sahip olma maliyeti; işlem gücü, depolama, ağ çıkışı, yedekleme, izleme, lisans ve operasyonel yönetim kalemlerinden oluşur. Küçük görünen bazı giderler, 12 aylık tabloda belirgin hale gelir.
Sağlıklı bir hesap için en az 3 senaryo çıkarılmalıdır: mevcut kullanım, %30 büyüme, pik yük. Örneğin aylık 2 TB log üreten bir sistemde log saklama süresi 90 gün yerine 365 gün seçilirse maliyet anlamlı ölçüde artabilir. Benzer şekilde internet çıkış trafiği yüksek olan video, dosya veya rapor indirme senaryolarında veri transfer bedeli göz ardı edilmemelidir.
Maliyet optimizasyonu için teknik önlemler
- Kapatılabilir test ortamlarını zamanlanmış otomasyonla durdurmak
- Yönetilen veri tabanı servislerini doğru boyutlandırmak
- Nesne depolama katmanlarında erişim sıklığına göre yaşam döngüsü politikası tanımlamak
- Konteyner ve sunucularda right-sizing uygulamak
- Gereksiz yüksek erişilebilirlik kurulumlarından kaçınmak
Örneğin hafta içi mesai saatlerinde kullanılan bir test ortamı, günde 14 saat kapatıldığında aylık maliyet üzerinde hissedilir bir fark yaratır. Bu tür küçük görünen kararlar, özellikle çoklu ortam kullanan ekiplerde daha da önem kazanır.
Güvenlik ve uyumluluk tarafında hangi kararlar kritik?
Bulut güvenliği, sağlayıcının tüm sorumluluğu üstlendiği bir alan değildir. Burada paylaşımlı sorumluluk modeli vardır. Sağlayıcı fiziksel altyapıyı ve temel servis katmanını korurken; kimlik yönetimi, erişim politikaları, veri sınıflandırması, uygulama güvenliği ve log denetimi genellikle müşteri tarafında kalır.
En az şu kontroller uygulanmalıdır:
- MFA ile güçlendirilmiş kimlik erişimi
- Rol tabanlı yetkilendirme ve en az ayrıcalık ilkesi
- Veri at-rest ve in-transit şifreleme
- Merkezi log toplama ve en az 90 gün saklama
- Yedeklerin düzenli geri yükleme testi
Teknik olarak en sık gözden kaçan konu, ağ güvenliğinden çok erişim yönetimidir. Pek çok olay, yanlış yapılandırılmış hesaplar veya geniş yetkiler üzerinden ortaya çıkar. Örneğin bir geliştirme hesabına üretim veri tabanına yazma izni verilmesi, bulut ortamında ciddi risk oluşturur.
Regülasyon ve veri konumu nasıl ele alınmalı?
Eğer kişisel veri, finansal kayıt veya sektörel denetime tabi bilgi işleniyorsa, veri yaşam döngüsü en baştan tasarlanmalıdır. Verinin nerede tutulduğu, kimlerin eriştiği, ne kadar süre saklandığı ve nasıl silindiği dokümante edilmelidir. Yalnızca teknik koruma yeterli değildir; süreç tarafı da izlenebilir olmalıdır.
Bu yüzden geçiş planında güvenlik mimarı, yazılım ekibi ve iş birimi temsilcileri birlikte çalışmalıdır. Güvenlik kararlarının sadece altyapı ekibine bırakılması, çoğu zaman eksik sonuçlar doğurur.
Ölçeklenebilirlik için uygulama mimarisi nasıl seçilir?
Bulut, otomatik olarak ölçeklenen sihirli bir kutu değildir. Monolitik ve durum bağımlı bir uygulama, doğrudan taşındığında aynı darboğazları bulutta da üretir. Gerçek ölçeklenebilirlik için uygulama katmanının nasıl bölüneceği belirleyicidir.
Örneğin günde 50 bin API çağrısı alan bir sipariş sistemi için stateless uygulama katmanı, ayrı cache kullanımı ve kuyruğa alınmış arka plan işlemleri iyi sonuç verir. Buna karşılık ayda birkaç yüz kullanıcıya hizmet veren iç uygulamalarda aşırı mikroservisleşme, gereksiz karmaşa yaratabilir.
Ne zaman rehost, ne zaman refactor?
Rehost, yani uygulamayı büyük değişiklik yapmadan taşımak, kısa sürede kazanım elde etmek için uygundur. Özellikle veri merkezi sözleşmesi bitmek üzereyse veya donanım yenileme baskısı varsa hızlı bir çözüm olabilir. Ancak uzun vadede maliyet ya da performans problemi sürüyorsa refactor gündeme gelir.
Refactor; uygulamanın belirli parçalarını bulut uyumlu hale getirmeyi içerir. Örnek olarak oturum bilgisini yerel sunucudan merkezi cache'e almak, dosya depolamayı nesne depolamaya taşımak veya rapor üretimini kuyruk tabanlı çalıştırmak verilebilir. Bu işler birkaç hafta ile birkaç ay arasında sürebilir; fakat doğru uygulandığında hem esneklik hem de operasyon kolaylığı sağlar.
Adım adım buluta geçiş yol haritası
Pratikte işe yarayan yaklaşım genellikle 5 aşamalıdır:
- Keşif ve ölçüm: 30-90 günlük envanter, performans, bağımlılık analizi
- Önceliklendirme: Düşük riskli iş yükleriyle pilot kapsam belirleme
- Mimari tasarım: Ağ, güvenlik, yedekleme, izleme ve CI/CD kurgusu
- Geçiş ve test: Veri taşıma, performans testi, geri dönüş planı
- Optimizasyon: İlk 60 gün maliyet, güvenlik ve kapasite iyileştirmeleri
Özellikle pilot aşama kritiktir. Tek seferde tüm sistemleri taşımak yerine, bir müşteri portalı veya raporlama servisiyle başlamak daha sağlıklı sonuç verir. Böylece ekip gerçek operasyon yükünü görür; erişim modeli, izleme politikaları ve dağıtım süreçleri üretimde test edilmiş olur.
Kapanışta temel ilke nettir: buluta geçiş, teknoloji seçiminden çok bir tasarım disiplinidir. Doğru mimari; iş yükünü, veri hassasiyetini ve büyüme beklentisini birlikte değerlendirir. Yalnızca hızlı taşımaya odaklanan projeler kısa vadede ilerler, ardından revizyon gerektirir. İyi planlanmış bir yaklaşım ise maliyeti görünür kılar, güvenlik seviyesini yükseltir ve gelecekteki ölçek ihtiyacını daha az sürprizle karşılar.
