Kurumsal Bulut Geçişinde Hibrit Mimari: Ne Nerede Çalışmalı

Beş yıllık ERP sistemini buluta taşımak ne kadar kolay? Satıcılar “lift and shift” deyip geçer. Gerçekte şirketlerin %60’ından fazlası geçiş sonrası beklenmedik maliyetlerle karşılaşır; bir kısmı on-premise’e geri döner. Hibrit mimari bu ikiliği çözmenin değil, yönetmenin yoludur. Ve pek çok kurumda bu bir geçiş aşaması değil, uzun vadeli kalıcı tercih haline gelmiştir.

Hibrit Mimari Nedir, Ne Değildir

Yaygın yanlış anlama: hibrit mimari, bazı şeyleri bulutta bazılarını veri merkezinde tutmak anlamına gelir ve geçici bir durumdur. Oysa büyük finans kurumlarına, telekomünikasyon şirketlerine ve kamu kurumlarına bakıldığında bu mimarinin kalıcı tercih olduğu görülür. Hassas müşteri verilerini kendi veri merkezinde tutarken analitik workload’ları AWS veya Azure’da çalıştırmak, hem regülasyon uyumluluğunu hem de maliyet esnekliğini aynı anda sağlar. BDDK ve KVKK gibi yerel düzenlemeler bazı veri kategorilerinin yurt dışına çıkmamasını zorunlu kıldığında hibrit mimari artık seçenek değil zorunluluktur.

Ağ Bağlantısı: VPN mi, Direct Connect mi?

On-premise ve bulut arasındaki bağlantı seçimi kritiktir ve yanlış seçim aylarca süren performans sorunlarına yol açar. Site-to-site VPN kurulumu hızlı ve ucuzdur (AWS’de ayda ~$36) ama bant genişliği internet kapasitesiyle sınırlıdır ve gecikme değişkendir. Büyük veri transferleri veya düşük gecikme gerektiren workload’lar için AWS Direct Connect veya Azure ExpressRoute gibi özel bağlantılar tercih edilmelidir. 1 Gbps Direct Connect bağlantısı ayda yaklaşık $200-400 arasında değişir ama gecikme tutarlı kalır, güzergah internet omurgasından geçmez ve SLA kapsamındadır.

Kimlik Yönetimini Tek Merkezde Toplamak

Hibrit ortamın en çok zorlandığı nokta kimlik ve erişim yönetimidir. Şirket içi Active Directory ile bulut IAM’ını ayrı yönetmek hem güvenlik açığı yaratır hem de operasyon yükünü ikiye katlar; şifre senkronizasyonu, ayrı hesap yönetimi ve denetim loglarının farklı sistemlerde dağılması kaçınılmaz hale gelir. Çözüm Azure AD Connect veya AWS IAM Identity Center ile federasyon kurmaktır. Çalışan şirket içi Active Directory kimliğiyle hem SAP sistemine hem AWS S3 bucket’ına Single Sign-On ile erişebilir. Ekstra parola yok, ekstra onboard/offboard adımı yok.

Workload Yerleşim Stratejisi: Neyi Nereye Koymalı

Her sistemi buluta taşımak doğru değildir. Kararı netleştiren bir çerçeve:

  • Buluta taşı: Trafik dalgalanan web uygulamaları, test ve geliştirme ortamları, büyük veri işleme pipeline’ları, felaket kurtarma kopyaları ve istatistiksel analiz workload’ları.
  • On-premise’de tut: Milisaniye gecikme gerektiren üretim makineleri kontrolü, yasal düzenleme kapsamındaki kişisel veriler, yüksek lisans maliyeti olan ve bulut modeline geçişi ekonomik olmayan legacy uygulamalar.
  • İkisinde birden çalıştır: Veritabanı on-premise, uygulama katmanı bulutta — VPN bağlantısı üzerinden, gecikme kabul edilebilir düzeydeyse bu mimari işe yarar ve veri egemenliği sorununu çözer.

Maliyet Görünürlüğü Olmadan Hibrit Mimari Kontrolden Çıkar

Tek bulut sağlayıcısı bile olsa maliyet takibi zordur; hibrit ortamda on-premise sermaye maliyeti ve bulut işletme maliyeti ayrı kalemler olarak görünür ve karşılaştırılması güçtür. Bunları birleştiren araçlar şart: AWS Cost Explorer ve Azure Cost Management kendi platformlarının giderini gösterir, ancak çapraz platform analizi için CloudHealth, Apptio Cloudability veya açık kaynak Infracost kullanılabilir. Aylık bütçe aşımı alarmı ve departman bazlı maliyet etiketleme (tagging) stratejisi kurulmadan hibrit geçişe girilmemelidir.

Gözlemlenebilirlik: İki Ortamı Tek Pencereden İzlemek

On-premise sunuculardaki Prometheus metrikleri ile AWS CloudWatch loglarını ayrı konsollardan takip etmek operasyonel körlüğe yol açar. Bir olay sırasında “sorun on-premise veritabanında mı, yoksa buluttaki uygulama katmanında mı?” sorusuna hızla yanıt veremezseniz MTTR (ortalama kurtarma süresi) uzar. Datadog veya Grafana + Loki + Tempo yığını her iki ortamdan veri çekebilir ve tek bir dashboard üzerinde korelasyon analizi yapılabilir. OpenTelemetry, vendor bağımlılığı olmadan her iki ortamdan trace ve metrik toplamak için standart bir yaklaşım sunmaktadır.

Felaket Kurtarma ve İş Sürekliliği

Hibrit mimarinin az konuşulan avantajlarından biri felaket kurtarma esnekliğidir. On-premise veri merkezi zarar gördüğünde kritik workload’lar buluta taşınabilir; bulut sağlayıcısında bir bölgesel kesinti yaşandığında on-premise altyapı devralabilir. Bu çift yönlü yedekleme modelini kurabilmek için düzenli “failover drillları” yapılmalı, hedef kurtarma süresi (RTO) ve hedef kurtarma noktası (RPO) her senaryo için ayrıca tanımlanmalıdır. Yalnızca teoride var olan bir felaket kurtarma planı gerçek bir kriz anında çalışmayabilir.

Hibrit mimarinin başarısı teknoloji seçiminden çok tasarım disiplinine bağlıdır. Neyin nerede çalışacağı, iki ortamın nasıl bağlanacağı ve nasıl izleneceği net kararlaştırılmadan başlanan geçişler genellikle iki ortamın da en kötü özelliklerini miras alır. İlk adım: mevcut workload envanteri çıkarmak ve her birini yukarıdaki kriterlere göre sınıflandırmaktır.