Bulutta tedarikçi bağımlılığı: ölçme, azaltma ve çıkış planı

Vendor lock-in nedir ve neden her zaman kötü değildir?

Vendor lock-in (tedarikçiye bağımlılık), bir bulut sağlayıcısının hizmetlerine o kadar sıkı bağlanmanız ki başka bir sağlayıcıya ya da kendi altyapınıza geçişin pahalı, yavaş veya riskli hale gelmesi durumudur. Bağımlılık sadece teknik değildir; veri çıkış ücretleri, sözleşme koşulları, ekibin yalnızca o platformu bilmesi ve süreçlerin onun araçlarına göre kurulmuş olması da bağımlılık yaratır.

Bağımlılık her zaman hata değildir. Sağlayıcının yönetilen hizmetlerini kullanmak işletme yükünü azaltır ve hız kazandırır; bu avantajın karşılığı bir miktar bağımlılıktır. Yönetimin amacı bağımlılığı sıfırlamak değil, bilinçli ve ölçülü tutmaktır. Her sistemi tamamen taşınabilir yapmak çoğu zaman en düşük ortak paydaya inmek ve sağlayıcının güçlü özelliklerinden vazgeçmek demektir.

Bağımlılık türleri: nerede kilitlenirsiniz?

Risk çerçevesi önce bağımlılığın türünü ayırmakla başlar.

• Veri bağımlılığı: Verinin özel biçimde saklanması ve çıkarılırken ücretlendirilmesi. Google Cloud ve AWS gibi büyük sağlayıcılar, platformdan tamamen ayrılan müşteriler için veri aktarım ücretinden feragat eden programlar duyurdu. Ancak bu programlar başvuru, verinin tamamının taşınması ve göçün belirli bir süre içinde tamamlanması gibi koşullara bağlıdır; sağlayıcıyı kullanmaya devam ederken oluşan sürekli çok bulutlu trafik genellikle kapsam dışında kalır. Bu yüzden veri bağımlılığında asıl soru artık yalnızca ücret değil, veri biçimi, hacim ve göç süresidir.
• Hizmet bağımlılığı: Yalnızca bir sağlayıcıda bulunan yönetilen hizmetlere (özel veritabanı motorları, sunucusuz çerçeveler, özel yapay zeka hizmetleri) uygulama mantığını bağlamak.
• Mimari bağımlılık: Uygulamanın sağlayıcıya özgü kimlik, ağ ya da olay modeline göre tasarlanması.
• Operasyonel bağımlılık: İzleme, dağıtım ve otomasyonun sağlayıcının araçlarına göre kurulması, ekibin başka ortamı hiç tanımaması.
• Sözleşmesel bağımlılık: Uzun taahhütler, indirim yapıları ve çıkış maddeleri.

Her türün azaltma yöntemi farklıdır. Veri bağımlılığı açık biçimlerle, hizmet bağımlılığı soyutlama katmanlarıyla, operasyonel bağımlılık ise ekip yetkinliğinin çeşitlendirilmesiyle ele alınır.

Adım adım: taşınabilirlik değerlendirmesi

Çıkış stratejisi, bir sistem tek tek ele alınarak yazılır.

Önce uygulama portföyü bağımlılık düzeyine göre sınıflandırılır: sıradan sanal makine üzerinde çalışan, standart bileşenler kullanan sistemler kolay taşınır; sağlayıcıya özgü hizmete gömülü sistemler zordur. Her sistem için, sağlayıcıya özgü bileşenlerin listesi çıkarılır ve her biri için bir karşılık aranır: açık kaynak eşdeğer, başka sağlayıcıda benzer hizmet ya da yeniden yazım gerektiği not edilir.

Sonra çıkış senaryosu tanımlanır: sağlayıcı fiyat artırırsa, hizmet kalitesi düşerse, mevzuat veri konumunu değiştirirse veya sağlayıcı hizmeti kapatırsa ne yapılır? Her senaryo için tahmini süre, emek ve veri çıkış maliyeti hesaplanır. Bu hesap, "kilitliyiz" cümlesini ölçülebilir bir riske çevirir ve hangi bağımlılığı kabul edip hangisini azaltacağınıza karar vermenize yardımcı olur.

Azaltma yöntemleri

• Açık standartlar ve taşınabilir biçimler: Standart veritabanı protokolleri, açık dosya biçimleri ve genel kabul görmüş arayüzler tercih edilir.
• Konteyner ve orkestrasyon: Uygulamalar konteynerle paketlenir; böylece çalışma ortamı sağlayıcıya göre değişse de uygulama aynı kalır. Bu yöntem hesaplama katmanını taşınabilir kılar ama veri ve yönetilen hizmet bağımlılığını çözmez.
• Soyutlama katmanları: Uygulama, doğrudan sağlayıcı hizmetini çağırmak yerine kendi arayüzünü çağırır; arkadaki gerçekleştirme değiştirilebilir. Bu, kodda ek emek ister ve yalnızca gerçekten değiştirilme ihtimali olan bileşenlerde mantıklıdır.
• Kod olarak altyapı: Altyapı tanımları sağlayıcıdan bağımsız bir araçla yazıldığında yeniden kurmak kolaylaşır; ancak kaynak tanımları sağlayıcıya özgü olduğu için tam taşınabilirlik sağlamaz.
• Çok bulutlu mimari: Kritik bileşenleri birden fazla sağlayıcıya dağıtmak bağımlılığı azaltır, fakat operasyonel karmaşıklığı ve maliyeti artırır; her kurum için doğru değildir.

Sözleşme stratejisi ve çıkış planı

Teknik önlemler kadar sözleşme de önemlidir. Sözleşme görüşmesinde veri çıkış koşulları, veri iadesi biçimi, geçiş desteği, fiyat değişikliği bildirim süresi ve sonlandırma hakkı gibi maddeler açıkça sorulur. Uzun süreli taahhüt indirimi cazip olabilir; ancak taahhüt, çıkış esnekliğini azaltır ve bu fark iş gerekçesinde görünmelidir.

Çıkış planı belgelenir ve zaman zaman gözden geçirilir. Plan; kritik verinin nasıl dışarı alınacağını, hangi hizmetlerin yerine ne konacağını, kimin karar vereceğini ve sürecin hangi sırayla işleyeceğini içerir. Çıkışı hiç denememiş bir kurumun planı kâğıt üzerinde kalır; bu yüzden küçük bir sistemin gerçekten başka ortama taşınmasını denemek, planın doğruluğunu ölçmenin en güvenilir yoludur.

Örnek senaryo ve sık yapılan hatalar

Örneğin bir e-ticaret şirketi, siparişleri sağlayıcıya özgü bir NoSQL veritabanında, ürün görsellerini nesne depolamada ve iş akışlarını sağlayıcının sunucusuz orkestrasyon hizmetinde tutuyor. Değerlendirme sonucu: görseller açık biçimde olduğu için taşınması kolay; sipariş verisi veri modeli dönüşümü ve göç süresince iki sistemin birlikte çalıştırılması nedeniyle zor; iş akışı ise yeniden yazım gerektirir. Şirket, sipariş verisi için periyodik bir dışa aktarım kurar, iş akışlarının iş mantığını kendi kod katmanına alır ve sözleşmede çıkış maddesi ister. Böylece kilitlenmeyi sıfırlamaz, ama ölçülü ve izlenebilir tutar.

Sık yapılan hatalar: bağımlılığı hiç değerlendirmeden en kapsamlı sağlayıcıya gömülmek; tersine, hiç bağımlılık istememek için üretkenliği feda etmek; çıkış maliyetini yalnızca hesaplama değil veri ve emek olarak da düşünmemek; sağlayıcının ücretsiz çıkış programının koşullarını okumadan ya bu ücreti hiç yok sanmak ya da hâlâ en büyük engel saymak; sözleşmeyi yalnızca fiyat üzerinden görüşmek; taşınabilirlik planını bir kez yazıp bırakmak.

Nasıl öğrenilir?

Önce kendi kurumunuzdaki bir sistemin sağlayıcıya özgü bileşenlerini listeleyin ve her birine "değişirse ne olur" sorusunu sorun. Ardından açık standartlar, konteyner teknolojisi ve kod olarak altyapı konularını öğrenin; bunlar taşınabilirlik araçlarının çekirdeğidir. İleri düzeyde çıkış maliyeti modelleme ve sözleşme müzakeresi gelir.

Mindset kataloğunda Bulut Çıkış Stratejisi ve Vendor Lock-in Yönetimi programı bağımlılık türleri ve risk çerçevesi, taşınabilirlik değerlendirmesi, çıkış maliyeti analizi ile sözleşme stratejisi ve azaltma planı modüllerinden oluşuyor.