Vendor Lock-in (Vektör Lock-in) Nedir?
Modern BT altyapılarında dışa bağımlılık, esneklik ve ölçeklenebilirliğin yanı sıra risk de getirir. Özellikle bulut servisleri, veri platformları, lisanslı yazılımlar gibi alanlarda kurumlar sıklıkla Vendor Lock-in ya da daha geniş tabiriyle Vektör Lock-in tuzaklarına düşebilmektedir.
1. Vendor Lock-in / Vektör Lock-in Nedir?
1) Tanım
Vendor Lock-in (Tedarikçi kilidi), bir kurumun BT altyapısı, yazılım, donanım veya hizmet düzeyinde belirli bir sağlayıcıya bağımlı hale gelmesi durumudur. Bu bağımlılık, genellikle teknik uyumsuzluklar, veri biçimi farklılıkları veya maliyetli geçiş prosedürleri nedeniyle ortaya çıkar.
2) Vektör Lock-in Nedir?
“Vektör Lock-in”, sadece tedarikçiye değil, aynı zamanda altyapı, yazılım mimarisi, API tasarımı, lisanslama modeli veya entegrasyon yöntemleri gibi çoklu teknik “vektörler” üzerinden oluşan kilitlenme halidir.
Özetle: Vendor Lock-in bir firmaya, Vektör Lock-in ise belirli bir teknoloji ekosistemine mahkûm kalmaktır.
2. Nasıl Oluşur?
1) Teknik Düzeyde
- Özgün API kullanımı: Örneğin Amazon S3’ün özel SDK’larını kullanan bir sistem, başka bir bulut sağlayıcısına geçerken API değişimi nedeniyle yeniden yazılmak zorunda kalabilir.
- Veri Formatı Uyuşmazlığı: Google BigQuery verilerini, Amazon Redshift’e doğrudan taşımak çoğu zaman zahmetlidir.
- Özgün komut seti: Microsoft SQL Server’dan PostgreSQL’e geçerken T-SQL bağımlılığı sorun yaratabilir.
- Konteyner Orkestrasyonunda farklar: AWS ECS ile Google Kubernetes Engine farklı mantıkla çalışır.
2) Ticari Düzeyde
- Yüksek çıkış maliyetleri (egress fees): Cloud’dan veri çıkarmak pahalıdır (örnek: AWS S3 egress pricing).
- Lisans anlaşmaları: Oracle gibi üreticilerin lisans koşulları, geçişi teknik olarak mümkün kılmasa da finansal olarak zorlaştırabilir.
- Minimum süre sözleşmeleri: 2–3 yıllık bulut anlaşmaları söz konusu olabilir.
3. Ne Zaman Risk Oluşturur?
1) Ölçek Büyürken
Küçük sistemlerde lock-in riski önemsiz olabilir. Ancak sistem büyüdükçe bağımlılık maliyet, güvenlik ve esneklik açısından ciddi tehdit haline gelir.
2) Kriz Anlarında
- Sağlayıcı servis kesintisi (örneğin, AWS outage, Dec 2021)
- Hukuki veya coğrafi yaptırımlar (örnek: ABD yaptırımlarıyla Huawei altyapısı)
- GDPR, KVKK gibi veri taşınabilirliği yasalarıyla çatışma
3) Regülasyon Uyumu Gerektiğinde
Finans, sağlık, kamu gibi alanlarda sistemlerin başka bir sağlayıcıya taşınabilir olması bir regülasyon şartı olabilir.
4. Gerçek Dünya Örnekleri
Örnek 1: Netflix
Netflix, AWS altyapısına bağımlıydı. 2020’de kendi multi-cloud failover sistemini geliştirmeye başladı çünkü tamamen AWS’ye bağımlı kalmak iş sürekliliği için riskliydi.
Örnek 2: Bir Banka (Kurgusal)
Bir banka, CRM altyapısını Salesforce üzerinde kurdu. API’ler ve veri şemaları tamamen Salesforce’a özgüydü. Başka bir platforma geçmek, milyon dolarlık dönüşüm gerektiriyordu.
Örnek 3: Sağlık Teknolojisi Girişimi
HIPAA uyumluluğu nedeniyle uygulamasını AWS’de kuran bir girişim, daha sonra Azure’a geçmek istedi. Ancak log yönetimi, erişim kontrol sistemi, hatta dosya şifreleme algoritmaları AWS’ye özgüydü.
5. Kurumlar Bu Durumu Nasıl Önleyebilir?
1) Açık Standartlara Dayalı Sistemler
- OpenAPI (Swagger) kullanımı
- Docker + Kubernetes gibi taşınabilirlik odaklı çözümler
- SQL yerine NoSQL + GraphQL yapılarının taşınabilirliği daha esnektir
2) Vendor Agnostic Tasarım
Uygulama, bir sağlayıcının API’sine değil; abstraction layer kullanan ara katmanlara bağlanmalıdır.
Örnek:
- Terraform kullanarak AWS, Azure, GCP arasında yapılandırmaları taşınabilir hale getirmek
- Ansible ile her sistemde çalışan dağıtım betikleri
3) Hibrit ve Multi-Cloud Stratejisi
- Ana uygulama AWS’de, yedek GCP’de
- Veriler iki bulut sağlayıcısında yedekli tutulur (Cloud Storage Sync)
- Load balancer + failover senaryoları
4) Çıkış Stratejisi (Exit Strategy)
Tüm sistemler için teknik geçiş belgeleri hazırlanmalı:
- Veri şemaları
- Kod bağımlılık listesi
- 3rd-party entegrasyon dokümantasyonu
Not: ISO/IEC 19941 standardı, bulut sistemleri için taşınabilirlik ve birlikte çalışabilirlik kurallarını tanımlar.