Bir sağlayıcıyla üç yıl çalıştın, her şey yolunda gitti. Sonra fiyatlar arttı ya da bir bölge kapandı ya da şirket politikası değişti; taşınmaya karar verdin ve o an fark ettin ki uygulaman artık taşınabilir değil. Veritabanı sağlayıcıya özgü bir servis, kimlik doğrulama onların sistemine bağlı, dosyalar onların depolama API'sıyla yazılıyor ve altyapı kodun yalnızca orada çalışıyor. Bu duruma vendor lock-in, Türkçesiyle satıcı kilidi denir.
Satıcı kilidi kötü bir karardan doğmaz; birbirinden makul görünen onlarca küçük kararın toplamıdır. Bu rehberde kilidin nasıl biriktiğini, hangi teknik seçimlerin bağımlılığı artırdığını, taşınabilirliğin gerçek maliyetini, çıkış stratejisinin nasıl yazıldığını ve pratikte hangi mimari alışkanlıkların seni özgür bıraktığını anlatacağım. Amaç bağımlılıktan tamamen kaçınmak değil — bu mümkün değil — bilinçli olarak ne kadar bağlandığını bilmektir.
Satıcı Kilidi Nasıl Birikir#
Kilit dört farklı katmanda oluşur ve her katmanın çıkış maliyeti farklıdır:
Veri kilidi. Verin sağlayıcının özel formatında ya da yalnızca onların API'sıyla erişilebilen bir serviste duruyorsa, taşımak için önce dışa aktarma yolu bulman gerekir. En ağır kilit türüdür çünkü veri hacmi büyüdükçe taşıma süresi ve maliyeti doğrusal artar.
API ve servis kilidi. Uygulaman sağlayıcıya özgü kuyruk, bildirim, kimlik doğrulama ya da fonksiyon servislerini doğrudan çağırıyorsa, her çağrı için yeni bir karşılık bulman gerekir.
Operasyon kilidi. Altyapını, izlemeni ve dağıtım hattını yalnızca o sağlayıcıda çalışan araçlarla kurduysan, taşınma teknik olarak mümkün ama operasyonel olarak baştan kurulum demektir.
Bilgi ve sözleşme kilidi. Ekibin yalnızca o platformu biliyorsa ya da uzun süreli taahhütle indirim aldıysan, teknik olarak taşınabilir bir sistem bile pratikte yerinde kalır.
| Kilit türü | Çıkış maliyeti | Önleme yöntemi |
|---|---|---|
| Veri | Yüksek (hacimle artar) | Standart format, düzenli ihracat |
| API / servis | Orta – yüksek | Soyutlama katmanı, standart protokol |
| Operasyon | Orta | Sağlayıcı bağımsız araçlar |
| Sözleşme | Düşük – orta | Kısa dönemli taahhüt, çıkış maddesi |
Bu tabloyu okurken şunu unutma: kilidin kendisi her zaman kötü değildir. Yönetilen bir veritabanı servisi kullanmak sana aylarca işletim emeği kazandırıyorsa, karşılığında aldığın bağımlılık bilinçli bir takastır. Kötü olan, bu takası hiç fark etmeden yapmaktır.
Hangi Kararlar Bağımlılığı Artırır#
Günlük geliştirme kararlarının bazıları taşınabilirliği sessizce tüketir. En sık karşılaştığım örnekler:
Sağlayıcıya özgü SDK'yı iş mantığının içine gömmek. Dosya yükleme kodu doğrudan bir bulut depolama SDK'sını çağırıyorsa, o kod başka bir yere taşınamaz. Doğrusu, bir arayüz tanımlayıp uygulamayı o arayüze bağlamaktır:
# İyi: standart protokol ve ortam değişkeniyle yapılandırma
STORAGE_ENDPOINT=https://depolama.firmaniz.com
STORAGE_BUCKET=uygulama-dosyalari
STORAGE_ACCESS_KEY=...
STORAGE_SECRET_KEY=...
# Bu şekilde S3 uyumlu her hizmet (MinIO dahil) aynı kodu çalıştırır
Kimlik doğrulamayı platforma devretmek. Kullanıcı hesapları sağlayıcının kimlik servisinde duruyorsa, taşınma sırasında parola hash'lerini alamayabilirsin ve tüm kullanıcılara parola sıfırlatmak zorunda kalırsın. Bu, teknik bir sorundan çok bir güven sorunudur.
Yalnızca o platformda çalışan fonksiyon/olay modelleri kullanmak. Olay tabanlı mimariler güçlüdür ama tetikleyici ve yürütme modeli sağlayıcıya özgüyse, taşıma neredeyse yeniden yazma anlamına gelir.
Altyapıyı elle kurmak. İronik biçimde, hiç otomasyon kullanmamak da bir kilit türüdür: neyin nasıl kurulduğu kimsenin kafasında net değilse, başka yerde tekrar kurmak arkeolojik bir çalışmaya dönüşür. Altyapıyı kodla tanımlamak (Ansible, Terraform benzeri araçlar) bu riski büyük ölçüde ortadan kaldırır. Sunucu kurulumunu tekrarlanabilir hale getirmenin pratik yolunu Ansible ile sunucu otomasyonu yazısında anlattım.
Taşınabilir Mimarinin Beş Kuralı#
Tam bağımsızlık hedefi gerçekçi değildir ve peşinden koşmak da pahalıdır. Bunun yerine maliyeti düşük, getirisi yüksek beş kural uygulanabilir:
- Uygulamayı konteynerleştir. Konteyner imajı, çalışma zamanını ve bağımlılıkları birlikte taşır; aynı imaj her IaaS ortamında çalışır. Bu tek adım, operasyon kilidinin büyük bölümünü çözer.
- Yapılandırmayı ortam değişkenleriyle ver. Sabit yol, gömülü uç nokta ve gömülü kimlik bilgisi bırakma. Aynı imaj farklı ortamlarda yalnızca değişkenlerle farklılaşsın.
- Standart protokolleri tercih et. PostgreSQL/MySQL protokolü, S3 uyumlu depolama, SMTP, Redis protokolü — bunların her birinin birden fazla uygulaması vardır ve hepsi taşınabilir.
- Durumu (state) az sayıda yerde topla. Verinin nerede olduğunu tek bakışta sayabiliyorsan taşıma planı yapmak kolaydır; onlarca yere dağılmışsa envanter çıkarmak bile haftalar alır.
- Çıkışı düzenli test et. Yılda bir kez verini tamamen dışa aktarıp başka bir ortamda ayağa kaldırmayı dene. Bu tatbikat, sözleşmedeki hiçbir maddenin veremeyeceği bir güvence verir.
Konteynerleştirilmiş, ortam değişkeniyle yapılandırılan ve standart protokol kullanan bir uygulamanın taşınması genellikle günler sürer. Aynı büyüklükte ama platforma gömülü bir uygulamada aynı iş aylara yayılabilir; fark tamamen bu beş kurala uyup uymamaktan çıkar.
Veri Taşınabilirliğini Somutlaştırmak#
En kritik katman veridir, çünkü kod yeniden yazılabilir ama veri yeniden üretilemez. Veri taşınabilirliğini somut hale getirmenin yolu, ihracatı düzenli olarak fiilen çalıştırmaktır.
# PostgreSQL: taşınabilir, sürüm bağımsız yedek
pg_dump -Fc -h db.firmaniz.com -U uygulama uygulama_db > uygulama_$(date +%F).dump
# MySQL/MariaDB: tutarlı anlık yedek
mysqldump --single-transaction --routines --triggers \
-h db.firmaniz.com -u uygulama -p uygulama_db > uygulama_$(date +%F).sql
# Nesne depolama: S3 uyumlu iki uç arasında senkron kopya
rclone sync kaynak:uygulama-dosyalari hedef:uygulama-dosyalari --progress
Yedek almak yeterli değildir; geri yüklemeyi test etmek gerekir. Yıllık tatbikatın şu üç adımı içermelidir:
- Üretimden bağımsız boş bir sunucuda yedeği geri yükle.
- Uygulamayı o veriye bağlayıp temel akışları (giriş, listeleme, kayıt) çalıştır.
- Geçen süreyi ve karşılaşılan engelleri yaz — bu, gerçek felaket anındaki tahmini süredir.
Bu tatbikat aynı zamanda felaket kurtarma planının da testidir; iki ihtiyaç aynı çalışmayla karşılanır. Yedekleme altyapısını nasıl kuracağını Borg ile sunucu yedekleme yazısında adım adım ele aldım.
Çıkış Stratejisi Yazmak#
Çıkış stratejisi, "buradan ayrılmayı planlıyoruz" belgesi değildir; ayrılmak gerektiğinde ne yapılacağını önceden yazan bir belgedir. Bir sayfayı geçmesine gerek yok, ama şu altı başlığı içermelidir:
| Başlık | Yazılması gereken |
|---|---|
| Veri envanteri | Hangi veri nerede, hangi formatta, ne kadar |
| İhracat yöntemi | Her veri kaynağı için komut ve tahmini süre |
| Bağımlılık listesi | Sağlayıcıya özgü kullanılan her servis ve karşılığı |
| Hedef ortam | Taşınılacak alternatif ve neden uygun olduğu |
| Kesinti bütçesi | Kabul edilebilir kesinti süresi ve geçiş planı |
| Sorumlular | Kimin neyi yapacağı ve karar verici |
Bu belgeyi yılda bir güncelleyip tatbikat sonuçlarını içine yazdığında, hem yönetime somut bir risk cevabı verebilir hem de gerçekten taşınman gerektiğinde sıfırdan başlamamış olursun. Bulut dağıtım modelleri arasında geçiş yapmayı düşünüyorsan, hangi modelin hangi bağımlılıkları getirdiğini public, private ve hybrid cloud modelleri yazısında karşılaştırdım.
Bağımlılık Ne Zaman Kabul Edilebilir#
Her bağımlılıktan kaçmak, kendi kendine sorun üretmenin bir yoludur. Yönetilen bir veritabanı yerine kendi kurduğun ve yedeğini unuttuğun bir sunucu, "bağımsız" olsa da daha risklidir. Karar verirken üç soruyu sormanı öneririm:
- Bu bağımlılığın karşılığında ne kazanıyorum? Aylarca işletim emeği tasarrufu makul bir karşılıktır; küçük bir kolaylık değildir.
- Bu bileşeni değiştirmem gerekirse ne kadar sürer? Cevabı bilmiyorsan, önce bunu araştır.
- Bu bileşen iş sürekliliğim için kritik mi? Kritikse alternatifini önceden belirlemiş olmalısın.
Pratik bir denge şudur: veri katmanında taşınabilirliği koru, yardımcı servislerde kolaylığı seç. Veritabanı, dosya depolama ve kimlik gibi katmanlarda standart protokollere bağlı kal; izleme, bildirim ve CI gibi katmanlarda ise sağlayıcının kolaylığından yararlan — bunların değiştirilmesi görece ucuzdur.
Maliyet tarafında da benzer bir denge vardır: uzun taahhütler indirim getirir ama çıkış esnekliğini azaltır. Taban kapasite için taahhüt verip dalgalanan kısmı esnek bırakmak, bu takası dengeler. Faturayı kalem kalem nasıl analiz edeceğini bulut maliyeti hesaplama yazısında anlattım.
Sık Yapılan Hatalar ve Tuzaklar#
En yaygın hata, kilidi yalnızca teknik bir konu sanmak. Ekibin yalnızca tek bir platformu biliyorsa, teknik olarak taşınabilir bir sistem bile taşınmaz. Bilgi çeşitliliği de bir taşınabilirlik yatırımıdır.
İkinci hata, soyutlama katmanını aşırıya kaçırmak. "Her şeyi değiştirilebilir yapalım" diyerek kurulan çok katmanlı soyutlamalar, kodu okunmaz hale getirir ve gerçekte hiç kullanılmayacak esneklik için sürekli maliyet ödetir. Soyutlamayı yalnızca gerçekten değiştirme ihtimali olan sınırlara koy.
Üçüncü tuzak, veri ihracatını hiç test etmemek. Sözleşmede "verilerinizi dışa aktarabilirsiniz" yazması, aktarımın makul sürede ve kullanılabilir formatta olacağı anlamına gelmez. Terabaytlarca veriyi çıkarmanın hem süresi hem çıkış trafiği maliyeti gerçek bir engel olabilir; bunu kriz anında değil, bugün ölç.
Dördüncü hata, çıkış planını bir kez yazıp rafa kaldırmak. Sistem her ay değişir; altı ay önce yazılmış envanter bugün eksiktir. Planı canlı tutmanın en ucuz yolu, her yeni bileşen eklendiğinde bağımlılık listesine tek satır yazmayı alışkanlık haline getirmektir.
Beşinci ve pahalı tuzak, taşınmayı tek seferde yapmaya çalışmak. Büyük geçişler risklidir; bileşen bileşen ilerlemek hem riski dağıtır hem her adımda öğrenme sağlar. Önce durumsuz bileşenleri taşı, veri katmanını en sona bırak.
Sıkça Sorulan Sorular#
Vendor lock-in tamamen önlenebilir mi#
Hayır ve amaç bu olmamalı. Herhangi bir sağlayıcıyla çalıştığın anda bir miktar bağımlılık oluşur; tamamen kaçınmaya çalışmak, kullanabileceğin faydalı hizmetlerden vazgeçmek ve kendi kendine işletim yükü yaratmak anlamına gelir. Doğru hedef, bağımlılığın ne kadar olduğunu bilmek, kritik katmanlarda taşınabilirliği korumak ve çıkış maliyetini önceden ölçmüş olmaktır.
Konteyner kullanmak beni lock-in'den kurtarır mı#
Büyük ölçüde operasyon kilidinden kurtarır ama veri kilidinden kurtarmaz. Konteyner imajın her yerde çalışır, bu doğru; ancak uygulaman sağlayıcıya özgü bir veritabanı ya da depolama servisine bağlıysa taşınma yine zordur. Konteynerleştirme taşınabilirliğin gerekli ama yeterli olmayan koşuludur; veri katmanında standart protokol kullanmak asıl belirleyici adımdır.
Sağlayıcı değiştirmek ne kadar sürer#
Mimariye ve veri hacmine göre günlerle aylar arasında değişir. Konteynerleştirilmiş, standart protokol kullanan ve verisi birkaç yerde toplanmış bir sistemde geçiş birkaç gün sürebilir. Platforma özgü servislere derinlemesine bağlanmış bir sistemde ise her servis için karşılık bulmak, veri dönüştürmek ve test etmek gerekir; bu aylara yayılır. Büyük veri hacimlerinde aktarımın kendisi de günler alabilir.
Veri ihracatı için sağlayıcıdan ne talep etmeliyim#
Sözleşmede üç şeyin yazılı olmasını iste: verinin hangi formatta dışa aktarılabileceği, aktarımın azami süresi ve hizmet sonlandığında verinin ne kadar süre erişilebilir kalacağı. Buna ek olarak, ihracatın kendisi için ek ücret alınıp alınmadığını da netleştir — bazı durumlarda çıkış trafiği ücreti tek başına ciddi bir kalem oluşturur.
Küçük bir projede bu konuyla uğraşmalı mıyım#
Kapsamlı bir çıkış stratejisi yazmana gerek yok, ama iki basit alışkanlık küçük projede bile karşılığını verir: yapılandırmayı ortam değişkenleriyle ver ve verinin düzenli, standart formatta bir yedeğini kendi kontrolündeki bir yerde tut. Bu ikisi neredeyse hiç maliyet çıkarmaz ve proje büyüdüğünde en zor düzeltilen iki hatayı baştan önler.
Açık kaynak kullanmak lock-in riskini sıfırlar mı#
Riski belirgin biçimde azaltır ama sıfırlamaz. Açık kaynak bir veritabanı ya da depolama yazılımı kullanıyorsan, aynı yazılımı başka bir sağlayıcıda ya da kendi sunucunda çalıştırabilirsin; bu gerçek bir özgürlüktür. Yine de veri hacmi, operasyonel bilgi ve ekibin alışkanlıkları hâlâ bir çıkış maliyeti üretir. Açık kaynak, kilidi teknik olmaktan çıkarıp pratik bir maliyet sorununa indirger.
Kapanış#
Satıcı kilidi kaçınılması gereken bir felaket değil, ölçülmesi gereken bir risktir. Aklında tutman gereken dört alışkanlık şunlar: uygulamayı konteynerleştirip yapılandırmayı dışarıdan ver, veri katmanında standart protokollere bağlı kal, veri ihracatını yılda bir kez fiilen test et ve bağımlılık listesini her yeni bileşende tek satırla güncelle. Bu dördü, taşınmanın süresini aylardan günlere indirir.
Taşınabilir bir temel kurmak istiyorsan tam kontrolün sende olduğu VDS ve sanal sunucu paketlerimiz standart protokollerle çalışmanı kolaylaştırır; esneklik ve hızlı ölçeklenme arıyorsan bulut sunucu tarafına bakabilirsin. Mevcut altyapını başka bir sağlayıcıdan taşımayı düşünüyorsan site taşıma hizmetimiz geçişi üstlenir, kurulum sonrası işletimi bize bırakmak istersen sunucu yönetimi hizmetimiz devreye girer.