Broadcom, VMware'den çıkış aracını sessizce kaldırdı

Ağustos 2026'nın sonlarından bu yana, Broadcom'un geliştirici portalındaki VMware VDDK kütüphanesinin indirme sayfaları 404 döndürüyor; ne bir duyuru, ne bir kullanımdan kaldırma bildirimi, ne de belirtilmiş bir alternatif var. Kütüphanenin kendisi çoğu kişi için bilinmeyen bir şey, ancak ona bağımlı araçlar öyle değil: VMware sunucuları için imaj düzeyinde yedekleme ürünleri ve VMware'den başka platformlara geçmek için kullanılan araçlar. Pratik sonuç şu: VMware'den çıkmayı değerlendiren bir şirket, resmî çıkış yolunu kapalı buldu. Ve ders, VMware kullanıcısı olsun ya da olmasın her sistem sahibi için geçerli: Bir tedarikçiye bağımlılığınız abonelik ücretiyle ölçülmez. Ayrılmanın size ne kadar zamana, paraya ve uzmanlığa mal olacağıyla ölçülür.

VDDK nedir ve adını hiç duymamış olsanız bile neden önemlidir

VDDK, Virtual Disk Development Kit'in kısaltmasıdır. Hipervizör dışındaki yazılımların VMware sanal disklerini okuyup yazmasını sağlayan kütüphanedir. Daha basit bir ifadeyle: Bir sanal sunucunun kopyasını almak ya da onu başka bir yere taşımak isteyen her programın geçtiği köprüdür.

Bu yüzden Broadcom ile belirgin bir bağlantısı olmayan araçların merkezinde yer alır. VMware'den KVM'ye geçiş çalışmalarının çoğunun dayandığı açık kaynaklı dönüştürme motoru virt-v2v, onu bir giriş aktarım yöntemi olarak destekler. Apache CloudStack'in geçiş yolu, önce tam bir OVF dosyasını dışa aktarmak yerine disk bloklarını doğrudan aktarmak için onu kullanır. Ve bir vSphere sanal makinesinin imaj düzeyinde kopyasını alan her yedekleme ürünü, zincirin bir yerinde ondan geçer.

Asıl mesele şu: VMware'i çalıştırmaya devam etmek için VDDK'ya ihtiyacınız yok. Hızla ayrılmak ve karar verirken çalıştırdığınız şeyi korumak için ona ihtiyacınız var.

Gerçekte ne oldu

ShapeBlue, değişikliği 25 Ağustos 2026'da belgeledi: Apache CloudStack'in resmî yönetim kılavuzunun kütüphaneyi indirmek için yönlendirdiği sayfa hata veriyor; 8 ve 9 sürümlerine özel yollar dâhil portaldaki diğer tüm VDDK yolları da öyle. Avrupa'dan ve Amerika Birleşik Devletleri, Brezilya, Finlandiya ve Japonya'daki çıkış düğümleri üzerinden test ettiler ve her yerde aynı sonucu aldılar; yani bu yerel bir arıza ya da coğrafi bir engelleme değil.

Daha da tuhafı, değişikliği açıklayan bir Broadcom duyurusu yok. Aşamalı bir kullanımdan kaldırma bildirimi yok, bir saklama politikası yok ve bir müşterinin ya da küçük bir tedarikçinin kütüphaneyi edinmesi için belirtilmiş bir yol yok. Resmî CloudStack kılavuzu kullanıcıları hâlâ artık çalışmayan bir bağlantıya yönlendiriyor. Bu makaleyi yazarken bağlantıyı kendimiz kontrol ettik ve 404 aldık; CloudStack kılavuz sayfası ise normal şekilde yükleniyor.

Sistemi çalıştırmak için kütüphaneye ihtiyacınız yok. Ayrılmak için ona ihtiyacınız var. Yokluğunu önemli kılan da tam olarak budur.

Neden bir geçici çözüm yok

Normalde herkesin ihtiyaç duyduğu bir dosya kaybolduğunda teknik topluluk etrafından dolaşmanın bir yolunu bulur: Biri onu yansılar, biri paketler ve hikâye bir dokümantasyon sayfasında dipnot olarak biter. Ancak VDDK lisansı genel yeniden dağıtıma izin vermiyor. Hiçbir Linux dağıtımı onu içermiyor, hiçbir konteyner imajı onu paketlemiyor ve imzalı bir yeniden dağıtım sözleşmesi olmayan hiçbir yedekleme tedarikçisi onu kurulum programına koyamıyor.

Bu da tabloyu tamamlıyor: Tek bir URL, koca bir yazılım ekosistemi için katı bir bağımlılığa dönüştü ve bu bağımlılığı yaratan lisans, bariz çözümü engelleyen lisansla aynı. İkili dosyaları başka bir yerde yansılamak hiçbir şeyi düzeltmez; yalnızca hukuki riski onları barındıran kişiye aktarır.

Zarar da eşit dağılmıyor. Ortaklık ilişkisi olan büyük bir yedekleme tedarikçisinin arayabileceği biri var. Üç kişilik bir geçiş danışmanlığı şirketinin, açık kaynaklı bir projenin ya da kendi iş yüklerini dönüştüren bir müşterinin elinde ise bir forum gönderisi ve bir hata sayfası var.

Asıl ders: Çıkış maliyeti bağımlılığın ölçüsüdür

Sistem satın alma kararlarının çoğu fiyatlar ve özellikler karşılaştırılarak verilir. Bu, değerlendirmenin yarısıdır. Eksik yarısı tek bir sorudur: Üç yıl sonra bu tedarikçiden ayrılmaya karar verirsek bunun bize maliyeti ne olur?

VDDK'da yaşananlar, çıkış maliyetinin sabit olmadığını gösteriyor. Bir tedarikçi onu sonradan, tek taraflı olarak ve bazen hiçbir duyuru yapmadan artırabilir. Beş yıl önce VMware ile sözleşme imzalayan bir şirket fiyatı ve performansı değerlendirdi. Ürünün sahipliğinin değişeceğini de, çıkış aracının portaldan sessizce kaybolacağını da bilmiyordu.

Çıkış maliyetinizi pratikte nasıl ölçersiniz

Her yeni sözleşmeden önce ve mevcut her sözleşmeyi yenilemeden önce şu soruları sorun ve yanıtları yazılı olarak alın:

  • Verilerim açık bir formatta dışa aktarılabiliyor mu? Bir elektronik tabloya kısmi bir döküm değil; verilerin ve kayıtlar arasındaki ilişkilerin, başka bir sistemin okuyabileceği bir formatta tam olarak dışa aktarılması.
  • Çıkış aracı tedarikçinin kendisine mi ait? Dışarı çıkan tek yol, ayrılmak istediğiniz tarafın kontrol ettiği bir araçtan geçiyorsa bir çıkış planınız yok demektir. Bir umudunuz var.
  • Sözleşme aniden sona ererse elimde ne kalır? İlişki herhangi bir nedenle sona erdiğinde verilerin ve dokümantasyonun belirli bir süre içinde teslim edilmesini garanti eden açık bir madde isteyin.
  • Gerçekten ayrılmayı denedik mi? Hiç test edilmemiş bir çıkış planı plan değildir. Yılda en az bir kez tam bir dışa aktarma yapın ve başka bir yere aktarılabildiğini doğrulayın.
  • Geçiş, rakamlarla ne kadar sürer? Günleri ve maliyeti dürüstçe tahmin edin. Yanıt "bilmiyoruz" ise bu da bir yanıttır ve bağımlılığınızın düşündüğünüzden yüksek olduğu anlamına gelir.

Origami'de bunu nasıl ele alıyoruz

Biz bir teknoloji şirketiyiz ve müşteri sistemlerini, kodun ve verilerin müşteriye ait olduğu ilkesiyle kuruyoruz. Pratikte bu; başka herhangi bir ekibin okuyabileceği standart bir veritabanı, talep üzerine değil sistemle birlikte teslim edilen dokümantasyon ve verinin parçalarını değil tamamını dışa aktaran API'ler anlamına gelir. Bunu ilişki geçici olduğu için söylemiyoruz; ayrılabileceğini bilen bir müşterinin kendi isteğiyle kalan bir müşteri olduğu için söylüyoruz.

Ve sık sık olduğu gibi üçüncü taraf bir ürüne bağımlı olmak gerektiğinde, tasarım belgesine o taraf ortadan kalkarsa ne olacağını yazıyoruz: alternatifin ne olduğunu, geçişin ne kadar süreceğini ve sistemin hangi bölümlerinin etkileneceğini. Bu, belgede tek bir sayfadır, ancak bir sürprizle planlı bir manevra arasındaki farktır.

Kaynaklar