Multi-Cloud Stratejileri ve Vendor Lock-in

Multi-Cloud Stratejileri ve Vendor Lock-in

Bulut dünyasında "tek sağlayıcıya bağımlı kalmamak" sıkça dile getirilen bir hedeftir. Ancak multi-cloud (çoklu bulut) ile vendor lock-in (sağlayıcı bağımlılığı) arasındaki ilişki, sanıldığından çok daha karmaşıktır. Multi-cloud mimarisi kurmak, otomatik olarak lock-in'i ortadan kaldırmaz; hatta yanlış tasarlandığında maliyeti ve karmaşıklığı artırabilir. Bu yazıda, multi-cloud stratejilerini, gerçek lock-in risklerini ve portability (taşınabilirlik) için uygulanabilecek yaklaşımları ele alacağız.

1. Vendor Lock-in Gerçekte Nedir?

Vendor lock-in, bir sağlayıcıdan ayrılmanın maliyetinin, sağladığı değerden daha yüksek hale gelmesi durumudur. Ancak çoğu kurum platform bağımlılığı (platform dependency) ile gerçek lock-in arasındaki farkı karıştırır .

Gerçek Lock-in Belirtileri:

Tescilli veri platformları: Temiz bir dışa aktarma yolu olmayan, sağlayıcıya özel veri ambarları ve analitik motorları.
Sağlayıcıya özel orkestrasyon: Tek bir platformun primitiflerine bağlı serverless ve event workflow'ları.
Veri çıkış maliyetleri (egress): Veriyi taşımanın tek başına migrasyonu gerekçelendiremeyecek kadar pahalı olması.
Cezai sözleşmeler: Erken çıkışı veya tüketimin azaltılmasını cezalandıran sözleşme maddeleri .

Sağlıklı Bağımlılık (Lock-in Değil):
IaaS sanal makineleri, nesne ve blok depolama, yönetilen Kubernetes ve standart SQL/NoSQL veritabanları sağlayıcılar arasında büyük ölçüde taşınabilirdir. Bu hizmetleri kullanmak lock-in değil, normal platform bağımlılığıdır .

Gartner Uyarısı: Gartner, 2028'e kadar kuruluşların %25'inin bulut benimsemelerinden önemli ölçüde memnuniyetsizlik yaşayacağını öngörmektedir; bunun nedenleri arasında gerçekçi olmayan beklentiler, suboptimal uygulamalar ve kontrolsüz maliyetler yer almaktadır .

2. Multi-Cloud Desenleri

Google Cloud'un mimari rehberine göre multi-cloud iki temel desenle inşa edilir :

A. Partitioned Multi-Cloud (Bölümlenmiş Çoklu Bulut)

Farklı uygulamalar veya iş yükleri, farklı bulut sağlayıcılarında çalışır.

Kullanım Nedenleri:

Birleşme ve satın alma (M&A): İki şirketin uygulamaları farklı bulutlarda barındırılıyorsa .
Esneklik ve organizasyonel tercihler: Farklı departmanların kendi ihtiyaçlarına en uygun bulutu seçmesi.
Veri yerleşimi (data residency): Belirli bir ülkede ana sağlayıcının bölgesi yoksa, o bölgede hizmet veren başka bir sağlayıcı seçilir .
En iyi servis (best-of-breed): Her iş yükü için en uygun sağlayıcının seçilmesi.

B. Composite Architecture (Bileşik Mimari)

Tek bir iş yükü veya uygulama, birden fazla buluttaki bileşenleri kullanır . Bu yaklaşım daha karmaşıktır ve servisler arası iletişim, gecikme ve tutarlılık sorunları getirir.

3. Multi-Cloud'un Gerçek Maliyeti

Multi-cloud, göründüğü kadar "bedava esneklik" sunmaz. Gartner, multi-cloud yaklaşımının tek sağlayıcıya kıyasla önemli ölçüde daha yüksek altyapı maliyetleri ve daha yavaş benimseme getirdiğini tahmin etmektedir; bunun nedeni yinelenen hizmetler ve birlikte çalışabilirlik çalışmalarıdır .

Maliyet Kalemleri:

Yinelenen kaynaklar: Her bulutta paralel çalışan servisler.
Veri replikasyonu: Bölgeler arası ve sağlayıcılar arası veri transferi.
Uzmanlık bölünmesi: Ekiplerin birden fazla platformda yetkinlik kazanması.
Gözlemlenebilirlik: Merkezi olmayan log ve metrik toplama.
Güvenlik: Tutarlı politika uygulaması için ek araçlar.

Öneri: Multi-cloud, varsayılan bir strateji değil, bilinçli bir karar olmalıdır. Sadece şu durumlarda değerlidir :

Best-of-breed ihtiyacı: Bir platformdaki servis, alternatiflerinden belirgin şekilde üstünse.
Veri yerleşimi: Düzenleyici veya egemen bulut gereksinimleri verinin nerede yaşayacağını zorunlu kılıyorsa.
M&A gerçekliği: Bir satın alma, ikinci bir sağlayıcıyı zorunlu kılıyorsa.
Hedefli dayanıklılık: Birkaç kritik iş yükü, sağlayıcılar arası yedekliliği hak ediyorsa.

4. Portability (Taşınabilirlik) Stratejileri

Lock-in'i azaltmanın anahtarı, açık standartlar ve soyutlama katmanları kullanmaktır.

A. Kubernetes ile Taşınabilirlik

Kubernetes, sağlayıcıdan bağımsız bir API yüzeyi sunar. Yönetilen Kubernetes (EKS, AKS, GKE) kullanmak lock-in riskini azaltır; çünkü uygulamalar standart Kubernetes primitifleriyle tanımlanır ve farklı bulutlarda çalışabilir .

Ancak Dikkat: Kubernetes dağıtımları arasında farklılıklar vardır (CNI, CSI, ingress controller). Tam taşınabilirlik için upstream Kubernetes ile uyumlu, sağlayıcıya özel CRD'lerden kaçınan bir yaklaşım benimsenmelidir .

B. Açık Kaynak Veritabanları

Tescilli yönetilen veritabanları (ör. DynamoDB, Cosmos DB) yerine PostgreSQL, MySQL, MariaDB gibi açık kaynak veritabanları tercih edilmelidir. Bu veritabanları, Kubernetes üzerinde çalıştırıldığında sağlayıcıdan bağımsız hale gelir .

C. Infrastructure as Code (IaC)

Terraform, Pulumi veya Ansible gibi araçlarla altyapıyı kod olarak tanımlamak, sağlayıcılar arasında tutarlılık sağlar ve migrasyonu kolaylaştırır .

D. Açık Standartlar ve API'ler

CloudEvents: Olay verileri için standart format.
OpenTelemetry: Gözlemlenebilirlik verileri için standart.
Open Policy Agent (OPA): Politika yönetimi için standart.
JDBC/ODBC: Veritabanı erişimi için standart arayüzler .

E. Merkezi Kimlik ve Gözlemlenebilirlik

Kimlik: Okta, Entra ID veya Keycloak ile sağlayıcılar arası tutarlı kimlik yönetimi .
Gözlemlenebilirlik: Grafana, Prometheus veya Datadog ile bulut-agnostik izleme .

5. Multi-Cloud Yönetim Platformları

A. Azure Arc

Azure Arc, Azure dışındaki kaynakları (diğer bulutlar veya on-prem) Azure Resource Manager'a projekte ederek tek bir yönetim düzlemi sunar .

Yönetilen Kaynaklar:

Sunucular ve sanal makineler
Kubernetes kümeleri
Azure veri servisleri (Azure SQL Managed Instance)
SQL Server

Avantaj: Azure Policy, RBAC ve Monitor gibi tanıdık araçları Azure dışındaki kaynaklara da uygulayabilirsiniz .

B. Google Anthos

Anthos, Google tarafından yönetilen, Kubernetes tabanlı bir hibrit/multi-cloud platformdur. AWS ve Azure üzerinde çalışan GKE kümelerini Google Cloud Console'dan yönetmeyi sağlar .

Özellikler:

Anthos Service Mesh (Istio tabanlı)
Anthos Config Management
Multi-Cloud API (AWS ve Azure'daki GKE kümelerini yönetme)

6. Ne Zaman Multi-Cloud, Ne Zaman Tek Bulut?

Senaryo	Öneri
Küçük-orta ölçekli işletme, tek sağlayıcı yeterli	Tek bulut (maliyet ve basitlik)
M&A sonrası iki farklı bulut mirası	Partitioned multi-cloud
Veri yerleşimi düzenlemeleri	Partitioned multi-cloud (bölgesel sağlayıcı seçimi)
Best-of-breed servis ihtiyacı	Composite architecture (dikkatli tasarım)
Kritik iş yükleri için sağlayıcı bağımsızlığı	Kubernetes + açık kaynak + IaC
Yönetim karmaşıklığını azaltmak	Azure Arc veya Anthos

Altın Kural: Multi-cloud, bir sigorta poliçesi değil, bilinçli bir mimari karardır. Çoğu orta ölçekli kurum için doğru yaklaşım, tek bulutta kalmak ama taşınabilirliği korumak (Kubernetes, açık kaynak veritabanları, IaC) ve çıkış maliyetini bilmektir .

7. En İyi Pratikler

Pratik	Açıklama
Lock-in Envanteri Çıkarın	Hangi iş yükleri tescilli servislere bağımlı? Veri çıkış maliyeti ne?
Portability Seviyesini Belirleyin	Tam, kısmi veya minimal taşınabilirlik; her uygulama için netleştirin
Açık Standartları Tercih Edin	CloudEvents, OpenTelemetry, OPA, JDBC/ODBC
Kubernetes'i Upstream Uyumlu Kullanın	Sağlayıcıya özel CRD'lerden kaçının
Açık Kaynak Veritabanları Kullanın	PostgreSQL, MySQL, MariaDB
IaC ile Altyapıyı Tanımlayın	Terraform, Pulumi, Ansible
Merkezi Kimlik ve Gözlemlenebilirlik Kurun	Okta/Entra ID, Grafana/Prometheus
Çıkış Maliyetini Hesaplayın	Egress, migrasyon süresi, yeniden yazım maliyeti
Multi-Cloud'u Bilinçli Seçin	Varsayılan değil, gerekçeli karar

Sonuç

Multi-cloud ve vendor lock-in, birbirinden bağımsız kavramlardır. Multi-cloud mimarisi kurmak, otomatik olarak lock-in'i çözmez; hatta yanlış tasarlandığında maliyeti ve karmaşıklığı artırabilir. Gerçek lock-in, tescilli yönetilen servislerde, veri çıkış maliyetlerinde ve cezai sözleşmelerde yatar. Portability ise açık standartlar (Kubernetes, CloudEvents, OpenTelemetry), açık kaynak veritabanları (PostgreSQL, MySQL) ve IaC (Terraform) ile sağlanır. Azure Arc ve Google Anthos, çoklu bulut yönetimini kolaylaştıran güçlü araçlardır. Unutmayın: Multi-cloud bir amaç değil, iş ihtiyaçlarına hizmet eden bir araçtır. Çoğu kurum için doğru strateji, tek bulutta kalmak ama taşınabilirliği korumak ve çıkış maliyetini bilmektir.