Hibrit bulut nedir? On-premise ve cloud birlikte nasıl kullanılır?

Kısaca

Hibrit bulut, on-premise veya private cloud altyapısı ile public cloud kaynaklarının bağlantılı bir mimaride birlikte çalışmasıdır. Amaç her sistemi cloud'a taşımak değil, her iş yükünü latency, veri konumu, bağlantı, maliyet ve operasyon gereksinimine göre doğru ortamda çalıştırmaktır. Dynamis Teknoloji, hibrit mimariyi iki ayrı platformu yan yana koymak yerine ortak ağ, kimlik, güvenlik, gözlemlenebilirlik ve kurtarma modeliyle tasarlar.

Hibrit bulut iki ayrı ortamı tek işletim modelinde birleştirir

NIST, hybrid cloud'u birbirinden ayrı kalan iki veya daha fazla cloud altyapısının veri ve uygulama taşınabilirliğini sağlayan teknolojiyle birbirine bağlandığı deployment modeli olarak tanımlar.

Pratikte şirketlerde hibrit yapı çoğu zaman şu bileşenlerden oluşur:

• şirket içi veri merkezi veya on-premise sunucular
• private cloud
• bir public cloud sağlayıcısı
• iki ortam arasında VPN veya özel bağlantı
• ortak kimlik ve erişim politikaları
• merkezi log, monitoring ve alarm yapısı
• yedekleme ve felaket kurtarma planı

Hibrit mimarinin değeri "iki ortam kullanmak" değildir. Değer, iş yükünü gereksinimine göre konumlandırabilmek ve iki ortamı tek operasyon modeliyle yönetebilmektir.

Hibrit bulut ile multicloud aynı şey değildir

Hibrit bulut ile multicloud farklı mimari kavramlardır.

Hibrit bulut, on-premise veya private cloud ile public cloud'un birlikte kullanılmasını ifade eder.

Multicloud ise aynı organizasyonun birden fazla public cloud sağlayıcısını kullanmasıdır.

Bir şirket aynı anda her iki modeli de kullanabilir. Örneğin Active Directory ve bazı veritabanları private cloud'da kalırken uygulamanın bir bölümü AWS'de, analitik sistemi Azure'da çalışabilir.

Ancak birden fazla platform kullanmak tek başına mimari avantaj sağlamaz. Her yeni ortam ağ, kimlik, izleme, maliyet, yetki ve operasyon karmaşıklığı ekler.

İş yükü yerleşimi gereksinime göre yapılır

Hibrit mimaride ilk karar "hangi cloud'u kullanalım?" değil, "hangi workload nerede çalışmalı?" olmalıdır.

Microsoft'un hybrid architecture rehberi iş yükü ve veri yerleşiminde latency, data gravity, bandwidth, servis erişilebilirliği, dayanıklılık ve yerel sistem bağımlılıklarının değerlendirilmesini önerir.

Pratik bir başlangıç matrisi:

Bu tablo kural değil, discovery başlangıcıdır. Aynı uygulamanın farklı bileşenleri farklı ortamlarda çalışabilir.

Bazı iş yükleri on-premise kalmaya devam edebilir

AWS hybrid cloud rehberi bazı uygulamaların düşük latency, yerel veri işleme, yüksek veri transfer maliyeti veya regülasyon gereksinimleri nedeniyle on-premise kalabileceğini belirtir.

Aşağıdaki workload'lar yerel ortamda kalmaya aday olabilir:

• üretim hattına veya fiziksel ekipmana doğrudan bağlı sistemler
• bağlantı kesilse bile çalışmaya devam etmesi gereken uygulamalar
• çok yüksek hacimli veriyi yerelde üreten ve işleyen sistemler
• cloud'a sürekli veri taşımanın ekonomik olmadığı iş yükleri
• mevcut lisans veya donanım bağımlılığı nedeniyle hemen taşınamayan sistemler
• kurum politikası veya özel mevzuat gereksinimi olan veri kümeleri

On-premise kalmak, cloud stratejisinin başarısız olduğu anlamına gelmez. Doğru karar bazı sistemleri bilinçli biçimde yerelde bırakmak olabilir.

Cloud tarafı elastik kapasite ve yönetilen servisler için güçlüdür

Public cloud, kapasitenin hızlı değiştiği veya managed servislerin operasyon yükünü azaltabildiği iş yüklerinde daha güçlü aday olabilir.

Örnekler:

• dönemsel trafik alan web uygulamaları
• geliştirme ve test ortamları
• kısa süreli yüksek compute ihtiyacı
• managed database kullanabilecek uygulamalar
• merkezi log ve analiz platformları
• object storage
• disaster recovery kapasitesi
• yeni ürün ve proof-of-concept ortamları

Sabit kaynak ihtiyacını cloud'a taşımak otomatik olarak maliyet avantajı yaratmaz. İş yükünün çalışma biçimi, lisanslama ve veri transferi toplam maliyeti belirler.

Ağ bağlantısı hibrit mimarinin kritik bağımlılığıdır

İki ortam arasındaki bağlantı tasarlanmadan hibrit mimari production-ready sayılmaz.

Temel seçenekler:

• site-to-site VPN
• sağlayıcının private/dedicated bağlantı hizmetleri
• SD-WAN veya kurumsal WAN entegrasyonu

Bağlantı seçiminde yalnız bant genişliğine bakmayın. Şunları birlikte değerlendirin:

• latency
• jitter
• packet loss
• yedek bağlantı
• route yönetimi
• DNS çözümleme
• MTU
• şifreleme
• firewall kuralları
• veri transfer maliyeti

Uygulama her HTTP isteğinde on-premise database'e gidiyorsa 20-30 ms ek network latency bile kullanıcı deneyimini ve toplam transaction süresini etkileyebilir. Bu nedenle uygulama ve veri katmanını ayrı ortamlara bölerken gerçek trafik akışını ölçün.

DNS ve kimlik tasarımı iki ortamda tutarlı olmalıdır

Hibrit ortamda en sık sorun çıkaran katmanlardan ikisi DNS ve kimlik yönetimidir.

Plan içinde şu soruların yanıtı bulunmalıdır:

• Private DNS zone hangi ortamda authoritative?
• On-premise sistemler cloud içindeki private isimleri nasıl çözüyor?
• Cloud workload'ları yerel servisleri hangi resolver üzerinden buluyor?
• Active Directory veya Entra ID entegrasyonu nasıl çalışıyor?
• Service account ve workload identity nasıl yönetiliyor?
• Privileged access hangi ekipte?
• Acil erişim hesabı var mı?

Kimlik yapısı iki ayrı admin dünyasına bölünürse least privilege, audit ve incident response zorlaşır.

Güvenlik politikası ortamdan bağımsız uygulanmalıdır

Hibrit modelde "on-premise güvenli, cloud riskli" veya tam tersi yaklaşım doğru değildir. Kontroller workload ve veri sınıfına göre uygulanmalıdır.

Ortak güvenlik baseline'ı şu alanları kapsamalıdır:

• MFA
• privileged access
• network segmentation
• firewall policy
• patch management
• endpoint/workload protection
• secret management
• encryption
• audit logging
• vulnerability management
• backup protection

Cloud hesabında ayrı, on-premise ortamda ayrı ekiplerin birbirinden bağımsız politika uygulaması governance boşluğu oluşturabilir.

Gözlemlenebilirlik tek operasyon görünümünde toplanmalıdır

Hibrit ortamı yönetirken iki farklı monitoring ekranına sahip olmak yeterli değildir.

Operasyon ekibinin en az şu sinyalleri ortak bir incident bağlamında görebilmesi gerekir:

• application latency
• error rate
• CPU ve memory
• disk ve IOPS
• network latency ve packet loss
• VPN veya private link durumu
• database connection
• authentication failure
• backup sonucu
• certificate süresi

Microsoft, Azure dışındaki kaynakların ortak yönetim ve governance katmanına alınması için Azure Arc gibi hibrit yönetim araçları sunar. Kullanılan ürün değişebilir; önemli olan envanter, policy ve telemetry'nin ortam sınırında kaybolmamasıdır.

Hibrit mimari felaket kurtarmayı destekler ancak otomatik çözmez

İki ortamınız olması disaster recovery planınız olduğu anlamına gelmez.

Kurtarma tasarımında şu kararlar ayrıca verilmelidir:

• hangi workload hangi ortamda yeniden başlayacak?
• RPO nedir?
• RTO nedir?
• veri hangi yöntemle replike ediliyor?
• DNS veya traffic cutover nasıl yapılacak?
• kimlik servisi erişilebilir mi?
• kapasite önceden ayrılmış mı?
• failback nasıl yapılacak?

Production private cloud'da çalışırken public cloud'u recovery kapasitesi olarak kullanmak mümkündür. Tersi de mümkündür. Ancak runbook, veri tutarlılığı ve gerçek restore/failover testi yoksa ikinci ortam yalnızca ek altyapıdır.

Hibrit bulut her zaman daha ucuz değildir

Hibrit mimari maliyeti düşürebilir, ancak iki ortamı birden işletmek ek maliyet de yaratabilir.

Toplam maliyette şunları hesaplayın:

• on-premise donanım amortismanı
• veri merkezi ve enerji
• public cloud compute/storage
• data transfer
• private bağlantı veya VPN
• lisanslama
• backup
• monitoring
• güvenlik araçları
• iki ortamı bilen operasyon ekibi

Örneğin düşük maliyet gerekçesiyle database'i on-premise tutup application katmanını cloud'a taşırsanız, sürekli veri trafiği ve latency yeni bir operasyon maliyeti yaratabilir.

Bu nedenle hibrit kararını yalnız VM fiyatıyla vermeyin.

KVKK ve veri konumu iş yükü bazında değerlendirilmelidir

KVKK, tüm kişisel verilerin her durumda Türkiye'de tutulmasını zorunlu kılan genel bir veri yerelleştirme kuralı değildir.

Kişisel verinin yurt dışına aktarılacağı senaryolarda Kanun'un 9. maddesindeki şartların değerlendirilmesi gerekir. 2024'te yürürlüğe giren değişikliklerle standart sözleşmeler ve bağlayıcı şirket kuralları gibi uygun güvence mekanizmaları düzenlenmiştir.

Bu nedenle hibrit mimaride:

• hangi veri kişisel veri?
• hangi ülkede işleniyor veya saklanıyor?
• hangi sağlayıcı ve alt işleyen erişiyor?
• veri yurt dışına aktarılıyor mu?
• aktarım için hangi hukuki mekanizma kullanılıyor?
• retention ve silme politikası nedir?

sorularını hukuk/uyum sorumlularıyla birlikte değerlendirin.

Teknik ekip "KVKK var, her şeyi Türkiye'de tutalım" veya "şifreli olduğu için sorun yok" şeklinde tek başına hukuki sonuç çıkarmamalıdır.

Hibrit bulut yerine tam migration bazı durumlarda daha sadedir

Hibrit mimari bir ara aşama veya kalıcı model olabilir. Her şirketin kalıcı olarak iki ortam işletmesi gerekmez.

Migration strategy kararını ayrıca Cloud migration strategy: rehost, replatform ve refactor rehberinde ele alıyoruz.

Dynamis'te hibrit mimari workload bazında tasarlanır

Dynamis'te hibrit cloud değerlendirmesi mevcut altyapının ve iş yüklerinin envanteriyle başlar.

Discovery sırasında:

• workload ve bağımlılıklar
• latency
• veri hacmi ve data gravity
• network
• identity
• lisanslama
• veri konumu ve uyum gereksinimi
• RPO/RTO
• backup
• monitoring
• mevcut operasyon kapasitesi

birlikte değerlendirilir.

Ardından her workload için kalıcı konum, bağlantı modeli, güvenlik sınırı ve operasyon sahibi belirlenir. Gereksiz yere iki ortam işletmek yerine hibrit model yalnız gerçek bir teknik veya iş gereksinimi çözdüğünde kullanılır.

Tasarım, geçiş ve sürekli operasyon kapsamını birlikte değerlendirmek için Hibrit bulut hizmetini inceleyebilirsiniz.

Sık yapılan hatalar

Her şeyi aynı anda cloud'a taşımak: Yerel dependency ve latency gereksinimleri gözden kaçabilir.

Hibrit modeli geçici ağ bağlantısı sanmak: Kimlik, DNS, security, monitoring ve recovery ortak modele dahil edilmezse iki ayrı altyapı oluşur.

İki ortam var diye disaster recovery hazır sanmak: Failover ve restore test edilmeden kurtarma hedefi doğrulanmış olmaz.

Data transfer maliyetini hesaba katmamak: Sürekli ortamlar arası trafik beklenenden pahalı olabilir.

KVKK'yı otomatik veri yerelleştirme kuralı gibi yorumlamak: Veri kategorisi, aktarım ve uygun güvence şartları ayrı değerlendirilmelidir.

Service bağımlılıklarını ölçmeden workload'u bölmek: Application ile database arasındaki latency production performansını bozabilir.

Sırada ne var

• Cloud migration strategy: rehost, replatform ve refactor: hangi workload'un tamamen taşınacağını, hangisinin yerinde kalacağını belirleyin.
• Bulut göçü sırası: migration wave planı: bağımlılıkları ve riski migration sırasına dönüştürün.
• Özel bulut mu, genel bulut mu? KVKK açısından karar: veri konumu ve altyapı modelini KVKK açısından değerlendirin.
• Cloud Migration hizmeti: tam veya aşamalı migration planını değerlendirin.
• Hibrit bulut hizmeti: on-premise, private cloud ve public cloud arasında doğru işletim modelini kurun.

Kaynaklar

• NIST SP 800-145: The NIST Definition of Cloud Computing
• NIST: Hybrid cloud glossary
• AWS Prescriptive Guidance: Best practices for building a hybrid cloud architecture
• Microsoft Learn: Azure hybrid options and workload placement
• KVKK: Yurt dışına aktarım