Hybrid cloud multi cloud: hangisi uygun?

Bulut stratejisi artık yalnızca BT ekibinin teknik tercihi değil. Büyüyen işletmeler için veri yerleşimi, regülasyon, operasyon hızı ve bütçe planı doğrudan bu karara bağlı. En sık karşılaşılan ikilem ise şu: hybrid cloud multi cloud yaklaşımından hangisi iş hedefleriyle daha uyumlu?

Her iki model de tek bir sağlayıcıya tam bağımlılığı azaltabilir; ancak çalışma biçimleri farklıdır. Hybrid cloud, şirket içi altyapı ile en az bir genel bulut ortamının birlikte kullanılmasıdır. Multi cloud ise birden fazla genel bulut sağlayıcısının aynı organizasyonda, aynı anda değerlendirilmesidir. Örneğin muhasebe veritabanını şirket içindeki sanal sunucularda tutup müşteri portalını bulutta çalıştırmak hybrid cloud senaryosudur. E-ticaret uygulamasını bir sağlayıcıda, analitik iş yüklerini başka bir sağlayıcıda çalıştırmak ise multi cloud örneğidir.

Türkiye’de büyüyen şirketlerde karar çoğu zaman tek bir soruya indirgeniyor: “Hangi model daha güvenli?” Ancak pratikte güvenlik tek başına belirleyici değildir. Veri sınıflandırması, uygulama bağımlılıkları, ağ gecikmesi, lisans maliyeti, operasyon ekibinin yetkinliği ve felaket kurtarma hedefleri de tabloyu değiştirir. Sağlıklı seçim, 3 ila 5 yıllık büyüme senaryosuna göre yapılır.

Hybrid cloud ve multi cloud farkı: kavramları net ayırmak

Kavramlar karıştığında mimari kararlar da hatalı verilir. Hybrid cloud yapısında iki farklı dünya birlikte çalışır: on-premise sistemler ve bulut servisleri. Bu model, özellikle ERP, üretim sistemleri veya şirket içi dosya arşivi gibi mevcut yatırımlarını hemen terk etmek istemeyen işletmelerde yaygındır. Türkiye’de 10 yıldan uzun süredir çalışan bir ERP’nin bir gecede tamamen taşınması çoğu zaman gerçekçi olmaz.

Multi cloud ise farklı bulut sağlayıcılarının bilinçli biçimde birlikte kullanılmasıdır. Buradaki amaç bazen maliyet optimizasyonu, bazen de belirli servislerde uzmanlaşmış sağlayıcılardan yararlanmaktır. Örneğin bir ekip nesne depolamayı bir platformda, yapay zeka servislerini başka bir platformda, yedeklemeyi ise üçüncü bir hizmette konumlandırabilir.

Kısa teknik ayrım

• Hybrid cloud: On-prem + public cloud. VPN, MPLS, dedicated link veya site-to-site bağlantı gerekir.
• Multi cloud: En az iki public cloud. Kimlik yönetimi, ağ topolojisi ve gözlemlenebilirlik daha karmaşık hale gelir.
• Kritik fark: Hybrid model entegrasyon ağırlıklıdır; multi cloud yönetişim ağırlıklıdır.

Sahada sık görülen bir örnek verelim: İstanbul’daki bir distribütör, şirket içi SQL sunucusunu korurken bayi sipariş portalını buluta taşır. Bu hybrid cloud’dur. Aynı şirket daha sonra raporlama ve e-posta altyapısı için ikinci bir bulut sağlayıcısını devreye alırsa mimari multi cloud özellikleri de taşımaya başlar. Yani bu iki yaklaşım birbirini dışlamaz; zaman içinde birleşebilir.

Güvenlik açısından seçim kriterleri

Güvenlik değerlendirmesi, “hangi bulut daha güvenli” sorusundan çok “hangi iş yükü nerede daha güvenli yönetilir” sorusuyla başlamalıdır. Çünkü risk, verinin türüne göre değişir. Kişisel veri, finansal kayıt, üretim reçetesi, log verisi ve pazarlama görselleri aynı sınıfta değerlendirilmez.

Hybrid cloud, hassas verileri şirket içinde tutmak isteyen kurumlara kontrol avantajı sağlar. Mesela insan kaynakları kayıtları on-prem kalırken, self-servis çalışan portalı bulutta çalışabilir. Bu ayrım, erişim yüzeyini daraltır. Fakat hibrit yapı kurulduğunda güvenlik kendiliğinden gelmez. Kimlik federasyonu, ağ segmentasyonu, şifreleme anahtarlarının yönetimi ve log korelasyonu doğru tasarlanmazsa hibrit mimari yeni açıklar da doğurabilir.

Multi cloud tarafında ise asıl zorluk politika tutarlılığıdır. İki farklı bulut sağlayıcısında güvenlik grupları, IAM rolleri, secret yönetimi ve log formatları değişebilir. Bir ekipte 4 kişilik operasyon kadrosu varsa, iki platformun güvenlik modelini aynı olgunlukta yönetmek zor olabilir. Bu durum, özellikle hızlı büyüyen KOBİ’lerde sık görülür.

Hangi durumda hybrid cloud daha güvenli olabilir?

• Veri sınıflandırması netse ve kritik veriler şirket içinde tutulacaksa
• Regülasyon veya iç denetim gereği belirli sistemlerde fiziksel kontrol isteniyorsa
• Eski uygulamalar yeniden yazılmadan korunacaksa

Hangi durumda multi cloud daha güvenli olabilir?

• Tek sağlayıcı arızasına karşı kritik servislerde dağıtık çalışma hedefleniyorsa
• Belirli güvenlik servisleri için farklı sağlayıcıların güçlü yönleri kullanılacaksa
• Tedarikçi bağımlılığı kurumsal risk olarak görülüyorsa

Felaket kurtarma hedefleri burada somut bir ölçüttür. Örneğin bir sistem için RPO 15 dakika, RTO 1 saat olarak tanımlandıysa, mimari bu hedefleri karşılayacak şekilde test edilmelidir. Kâğıt üstündeki tasarım yeterli sayılmaz. En az yılda 1 kez failover testi yapılmayan bir kurgu, gerçek kriz anında bekleneni vermeyebilir.

Maliyet tarafı: ilk yatırım değil, toplam sahip olma maliyeti

Bulut kararlarında en sık yapılan hata, yalnızca aylık sunucu faturasına bakmaktır. Oysa gerçek maliyet; ağ çıkış ücretleri, lisanslar, yedekleme, gözlemlenebilirlik araçları, güvenlik servisleri, personel zamanı ve olası yeniden platformlama işini de kapsar. 12 aylık tablo ile 36 aylık tablo aynı sonucu vermeyebilir.

Hybrid cloud, mevcut donanım yatırımı bulunan şirketlerde kısa vadede mantıklı görünebilir. Sunucuların amortismanı devam ederken yalnızca değişken yükleri buluta taşımak bütçeyi korur. Ancak iki ortamı birlikte işletmenin gizli maliyetleri vardır: çift izleme sistemi, çift yedekleme yaklaşımı, ağ hatları ve entegrasyon bakımı.

Multi cloud ise sağlayıcılar arasında fiyat karşılaştırması yapma esnekliği sunar; ancak operasyonel maliyetin yükselmesi de olasıdır. Farklı faturalama modelleri, etiketleme standartları ve veri çıkış ücretleri kontrol edilmezse beklenmedik artışlar yaşanır. Özellikle log, yedek ve analitik veri trafiği büyük hacimlere ulaştığında bu kalem daha görünür hale gelir. Aylık 5 TB veri çıkışı olan bir mimaride, yalnızca egress maliyeti bile planı etkileyebilir.

Maliyet hesabında bakılması gereken kalemler

• 36 aylık toplam sahip olma maliyeti
• Ağ bağlantı ve veri çıkış ücretleri
• Yedekleme saklama süresi: 30 gün, 90 gün, 1 yıl gibi
• Gözlemlenebilirlik araçları: log, metric, trace
• Operasyon ekibinin eğitim ve yönetim kapasitesi

Pratik bir senaryo düşünelim. Ankara’da saha operasyonu olan bir şirket, 2 uygulamasını buluta taşıyor. İlk ay sunucu maliyeti düşüyor; ancak farklı ortamlardaki logları tek panelde toplamak için ek lisans gerekiyor. Ardından yedeklerin ikinci bölgede saklanması isteniyor. İlk bakışta ucuz görünen kurgu, 6 ay sonra daha pahalı hale gelebiliyor. Bu yüzden karar öncesinde PoC kadar FinOps bakışı da şart.

Esneklik ve ölçeklenebilirlik: büyüme planı hangi modeli çağırıyor?

Esneklik, yalnızca kaynak artırıp azaltma yeteneği değildir. Yeni lokasyon açma, yeni kanal devreye alma, dış sistemlerle entegrasyon kurma ve mevsimsel yükleri yönetme de bu kapsama girer. Türkiye’de e-ticaret, dağıtım ve SaaS işlerinde bu ihtiyaç oldukça belirgindir.

Hybrid cloud, kademeli dönüşüm için güçlü bir seçenektir. Eski sistemleri bir anda değiştirmeden yeni servisleri bulutta geliştirmeye imkân tanır. Mesela mevcut ERP on-prem kalır; bayi sipariş uygulaması, mobil servisler ve API katmanı bulutta çalışır. Bu yaklaşım, 6 ila 12 aylık geçiş projelerinde riski azaltır.

Multi cloud ise sağlayıcı bazlı servis bağımlılığını dengelemek isteyen ekipler için daha esnek olabilir. Bir sağlayıcıda konteyner altyapısı, diğerinde veri ambarı, bir başkasında CDN ya da AI servisi kullanılabilir. Ancak bu esneklik, ancak güçlü bir platform mühendisliği disiplini varsa faydaya dönüşür. Aksi halde her yeni servis ek karmaşıklık yaratır.

Esneklik kararında şu sorular işe yarar

• Önümüzdeki 12 ayda kaç yeni uygulama devreye alınacak?
• Yük artışı öngörülebilir mi, yoksa kampanya dönemlerinde 5-10 kat sıçrama oluyor mu?
• Uygulamalar konteyner tabanlı mı, yoksa monolitik yapı hâlâ baskın mı?
• Veri eşzamanlama ihtiyacı saniyeler düzeyinde mi, saatlik mi?

Örneğin B2B sipariş platformu geliştiren bir şirket düşünelim. Gündüz yoğunluğu ile gece yoğunluğu arasında 4 kat fark varsa ve uygulama zaten API-first tasarlanmışsa, bulut tarafında otomatik ölçeklenme ciddi avantaj sağlar. Ancak üretim hattına bağlı düşük gecikmeli bir uygulama varsa, bazı bileşenleri tesise yakın tutmak daha sağlıklı olabilir.

Türkiye’de büyüyen işletmeler için karar matrisi

Kararı hızlandıran en iyi yöntem, tüm başlıkları aynı ağırlıkta tartışmak yerine puanlama yapmaktır. Basit bir 100 puanlık matris bile yön verebilir. Örneğin güvenlik ve regülasyon 30 puan, maliyet 25 puan, esneklik 20 puan, ekip yetkinliği 15 puan, tedarikçi bağımlılığı 10 puan olarak belirlenebilir. Her mimari bu başlıklarda ayrı ayrı değerlendirilir.

Hybrid cloud daha uygun olabilir, eğer:

• On-prem yatırımınız hâlâ iş görüyor ve hemen terk edilmeyecekse
• ERP, muhasebe, üretim gibi çekirdek sistemlerde yeniden yazım maliyeti yüksekse
• Hassas veri ile internet açık servisleri ayırmak istiyorsanız
• Geçişi parça parça yapmak daha gerçekçi görünüyorsa

Multi cloud daha uygun olabilir, eğer:

• Tek sağlayıcı riski kurumsal düzeyde yönetilmek isteniyorsa
• Farklı sağlayıcılardaki uzman servislerden yararlanma hedefi varsa
• Platform ekibiniz IaC, CI/CD ve merkezi gözlemlenebilirlik konularında olgunsa
• Uygulamalar taşınabilir mimari prensipleriyle geliştiriliyorsa

Bazı işletmeler için en gerçekçi yanıt “önce hybrid, sonra seçici multi cloud” olur. Özellikle özel yazılım geliştiren ekiplerde bu yol daha kontrollüdür. Önce çekirdek sistemler ile yeni nesil servisler ayrıştırılır. Ardından gerçekten ihtiyaç varsa ikinci sağlayıcı devreye alınır. Sırf trend olduğu için çoklu bulut kurgusu kurmak, çoğu zaman teknik borcu büyütür.

Uygulama mimarisi ve operasyon ekibi kararı nasıl değiştirir?

Mimari tercih, uygulamanın yapısından bağımsız düşünülemez. Monolitik bir uygulamayı sırf buluta taşımak için lift-and-shift yapmak her zaman verim sağlamaz. Benzer şekilde, iki bulut arasında çalışan mikroservis yapısı kurmak da her ekip için uygun değildir.

Burada ölçülebilir iki nokta var. İlki dağıtım sıklığı. Eğer ekip ayda 1 kez yayın alıyorsa, ileri seviye multi cloud karmaşıklığı büyük ihtimalle gereksizdir. Haftada birkaç kez dağıtım yapan, test otomasyonu güçlü ekiplerde ise daha gelişmiş kurgu yönetilebilir. İkincisi olay müdahale süresi. Uyarı geldiğinde sorunun hangi katmanda olduğunu 15 dakikada bulamayan bir ekip için ikinci bulut ortamı eklemek operasyonu daha da zorlaştırır.

Altyapı-as-code yaklaşımı burada temel gerekliliktir. Terraform, Pulumi ya da benzeri araçlarla tanımlanmamış bir çoklu ortam yönetimi sürdürülebilir olmaz. Aynı şekilde merkezi kimlik yönetimi, secret vault kullanımı ve standart CI/CD pipeline’ları olmadan güvenli ölçeklenme beklemek risklidir.

Sonuç: doğru seçim, işletmenin olgunluğuna göre değişir

Hybrid cloud multi cloud karşılaştırmasında tek bir evrensel doğru yok. Hybrid cloud, mevcut yatırımlarını koruyarak kontrollü dönüşüm yapmak isteyen ve hassas iş yüklerini ayrıştırma ihtiyacı duyan işletmeler için çoğu zaman daha gerçekçi bir başlangıçtır. Multi cloud ise güçlü operasyon yetkinliği olan, tedarikçi riskini bilinçli yöneten ve servis bazlı optimizasyon arayan kurumlarda anlam kazanır.

Karar verirken teknoloji modasına değil, iş yükü haritasına bakın. Hangi verinin nerede duracağı, hangi uygulamanın ne kadar gecikmeye toleranslı olduğu, kesinti halinde kabul edilebilir sürelerin ne olduğu ve ekibin bunu nasıl yöneteceği netleşmeden yapılan tercih pahalıya mal olabilir. Sağlam bir analiz, küçük bir PoC ve 36 aylık maliyet modeliyle ilerleyen şirketler genellikle daha az sürpriz yaşar.

Eğer kurumsal web, mobil uygulama, ERP/CRM entegrasyonları veya API tabanlı özel yazılım projelerinde bulut mimarisini iş hedefleriyle uyumlu kurgulamak istiyorsanız, kararın yalnızca altyapı tarafı değil uygulama tasarımı tarafı da birlikte ele alınmalıdır. Uzun ömürlü sonuç çoğu zaman burada çıkar.