Son dönemde BT yöneticilerinin en sık duyduğu sorulardan biri şu: “VMware yenileme teklifi geldi, ne yapmalıyız?” Açıkçası bu sorunun tek bir doğru cevabı yok, ama yanlış sıralanmış bir cevabı var: önce platform seçip sonra ne taşıyacağını düşünmek. Ben genelde tersinden başlıyorum. Bu yazıda alternatif platformları tek tek övmeyeceğim; onun yerine hangi platformu seçerseniz seçin, karar vermeden önce kendinize sormanızı önerdiğim soruları sizinle paylaşmak istiyorum 🙂

Önce neyin değiştiğini doğru okuyalım

Broadcom’un satın almasından sonra lisanslama paketli ve çekirdek bazlı bir modele döndü. Bu değişimin etkisi herkes için aynı olmadı. Network World’de yayımlanan bir değerlendirmede, kurumların büyük bölümünün fiyatlarda yüzde 25’in üzerinde artış gördüğü, ama aynı zamanda çoğunun VMware’den bir anda değil kademeli olarak ayrıldığı aktarılıyor. Bu bana çok mantıklı geliyor, çünkü gerçekçi bir geçişte kimse pazartesi sabahı her şeyi söküp başka yere taşımıyor. Dolayısıyla asıl mesele “VMware’den çıkmak” değil, yenileme tarihinizle uyumlu, gerçekçi bir yol haritası çıkarmak.

Önce elimizde ne var, ona bakalım

Envanter çıkarmak sıkıcı geliyor, biliyorum. Ama bulduğum en güvenilir başlangıç noktası bu. Kaç sanal makine var, hangileri gerçekten çalışıyor, hangileri “belki lazım olur” diye duruyor, hangi hostlar hangi lisansa bağlı? Bu çalışmada beklenenden fazla atıl makine çıkması çok olağandır. Taşıyacağınız yükü ne kadar küçültürseniz, hem yeni platform maliyeti hem de geçiş riski o kadar düşüyor. Yani en ucuz geçiş, taşımanıza gerek olmayan makineyi kapatmak.

Hangi iş yükü neye bağımlı?

Sanal makinenin kendisini taşımak çoğu zaman işin kolay kısmı. Zor olan, etrafındaki bağımlılıklar: yedekleme yazılımı, izleme araçları, ağ sanallaştırma, güvenlik duvarı entegrasyonları, felaket kurtarma kurgusu, hatta otomasyon betikleri. Bunlardan biri yeni platformu desteklemiyorsa geçiş projesi bir anda üçe katlanabiliyor. Ben her iş yükü için bir bağımlılık listesi çıkarmayı ve bunu üreticilerin güncel uyumluluk matrisleriyle karşılaştırmayı öneriyorum. Özellikle yedekleme ve DR tarafını en başta doğrulayın; çünkü orada yaşanan sürpriz, kesinti anında ortaya çıkıyor.

Peki ekibimiz bu platformu işletebilir mi?

Bence bu, tablolarda en az görünen ama en çok can yakan soru. Proxmox, Nutanix AHV ya da Hyper-V; hepsi teknik olarak işini yapıyor. Fark, ekibinizin hangisinde rahat olduğunda ortaya çıkıyor. Linux ve komut satırı kültürü güçlü bir ekibiniz varsa açık kaynak seçenekler size cömert bir esneklik sunar. Windows ağırlıklı bir yapıdaysanız Hyper-V’nin tanıdık yönetim modeli öğrenme eğrisini ciddi biçimde kısaltır. Hazır, bütünleşik bir deneyim ve tek elden destek arıyorsanız Nutanix gibi ticari çözümler cazip olabilir. Burada dürüst olmak gerekirse, “en iyi platform” yok; “ekibimin en az hata yapacağı platform” var.

Toplam maliyet gerçekte ne olacak?

Lisans bedeli maliyetin sadece bir kısmı. Geçiş sırasında paralel çalışan iki ortamın maliyeti, eğitim, yeni destek sözleşmeleri, yedekleme lisanslarının yeniden düzenlenmesi, gerekirse donanım yenilemesi ve ekibin proje süresince başka işlere ayıramayacağı zaman da hesaba girmeli. Ücretsiz bir platformun “bedava” olmadığını, destek ve işletme emeğinin bir yerden ödendiğini unutmayın. Bunun tersi de doğru: pahalı görünen bir çözüm, işletme yükünü azalttığı için toplamda ucuz çıkabilir. Üç ile beş yıllık bir toplam sahip olma maliyeti çıkarıp mevcut yenileme teklifiyle yan yana koymanızı tavsiye ederim.

Pilotu hangi iş yüküyle yapmalı

İlk taşıma için kritik üretim sistemini seçmeyin, ama tamamen önemsiz bir test makinesi de seçmeyin; ikisi de size gerçekçi bilgi vermez. Benim tercih ettiğim yaklaşım, orta ölçekli, kendi sahibi ve net kabul kriterleri olan bir uygulamayla başlamak. Pilotta performansı, ağ davranışını, yedekleme ve geri dönüş sürelerini ölçün; ayrıca geri dönüş planınızı gerçekten deneyin. Bir geçişin güvenli olduğunu, geri dönebildiğinizi gördüğünüz anda anlarsınız.

Hepsini taşımak zorunda mıyız?

Birçok kurum için cevap hayır. Karma bir yapı, yani bir kısım iş yükü mevcut platformda, bir kısmı yeni platformda ya da bulutta kalacak şekilde kademeli ilerlemek, hem riski dağıtıyor hem de müzakere gücünüzü koruyor. Elbette bunun bir bedeli var: iki ayrı platformu yönetmek operasyonel karmaşıklık getiriyor ve ekibin her ikisinde de yetkin kalması gerekiyor. Yine de zorunlu bir “büyük patlama” geçişine kıyasla çoğu zaman daha sağlıklı buluyorum. Önemli olan, hedef durumu ve bitiş tarihini baştan yazılı hale getirmek; yoksa geçici çözüm kalıcı hale geliyor.

Tedarikçiye ne sormalı

Hangi platformu seçerseniz seçin, satış sunumunun dışında kalan soruları sormaktan çekinmeyin. Destek seviyesi anlaşmaları (SLA) neyi kapsıyor? Türkiye’de yerel destek ve yetkin iş ortağı var mı? Ürün yol haritası ve sürüm destek süreleri ne kadar öngörülebilir? Fiyatlandırma modeli üç yıl sonra değişirse elinizde hangi koruma var? Verilerinizi ve sanal makine disklerinizi başka bir platforma çıkarmak ne kadar kolay, yani kilitlenme riski nasıl? Bu soruların cevapları, bence fiyattan daha çok şey söylüyor.

Takvimi unutmayalım

Geçiş projelerinin en sık düştüğü hata, işe yenileme tarihine üç ay kala başlamak. Orta ölçekli bir kurumda envanter, pilot, eğitim ve kademeli taşıma kolayca bir yılı buluyor; büyük yapılarda daha da uzun sürebiliyor. Bu yüzden önce kendi yenileme tarihinizi ve mevcut sürümünüzün destek bitiş tarihini yazın, sonra geriye doğru plan yapın. Gerekirse kısa süreli bir yenilemeyle zaman satın alıp acele kararlardan kaçınmak, kötü bir geçişten çok daha ucuz.

Benim önerim

Platform karşılaştırma tablolarına bakmaya başlamadan önce bu sorulara yazılı cevap verin. Cevapları yazdığınızda zaten hangi seçeneğin size uyduğu büyük ölçüde belli oluyor. Sizin kurumunuzda en çok hangi soru takıldı, yedekleme bağımlılıkları mı, ekip yetkinliği mi, yoksa maliyet mi? Yorumlarda paylaşırsanız birlikte konuşuruz. Keyifli okumalar 🙂

Kaynaklar

Network World: Some enterprises are dropping VMware, just not all at once