A legtöbb upgrade projekt még mindig hardver-projektként indul. Új generációs szerverek, nagyobb magszám, több memória, modernebb NVMe. A budget CAPEX soron látszik, a teljesítménynyereség mérhető, a projekt ütemezhető. A költségek viszont nem ott kezdődnek, ahol a doboz megérkezik.
Az elmúlt időszakban a VMware licencelési és csomagolási struktúra jelentősen átalakult, különösen a bundle-alapú modell irányába.
Ez azt jelenti, hogy a virtualizáció ma már nem minden esetben különálló komponensek összessége, hanem egy integrált csomag része. Ez önmagában nem probléma. A kérdés az, hogy mit jelent ez egy szerver upgrade során.
Vegyünk egy tipikus példát. Egy 4 node-os cluster, 2×14 core CPU-val node-onként. Ez összesen 112 licencelt core. A workload stabil, 50–60 százalékos kihasználtsággal. A refresh során az új szerver 2×32 core-os processzorral érkezik. Az új cluster így 256 core-ra nő.
A hardver ára arányos. A szoftver költsége viszont nem feltétlen.
Per-core licencelés mellett a licencelt core-szám több mint duplázódik. Ha a csomagolás bundle-alapú, a hozzá kapcsolódó komponensek – például menedzsment- vagy hálózati réteg – is magasabb szinten aktiválódnak. A hároméves TCO számításban ilyenkor a szoftver OPEX könnyen meghaladja a hardware beruházás többletköltségét.
Ez az a pont, ahol az upgrade nem teljesítmény-projekt, hanem költség-projekt.
A bundle hatás egyik jellemző következménye, hogy a korábban opcionális vagy modulárisan kezelt funkciók csomagba kerülnek. A döntési tér beszűkül. Ha a szerver upgrade magasabb magszámot hoz, a csomag magasabb szintje válhat szükségessé, még akkor is, ha a workload nem igényli az összes komponens teljes funkcionalitását.
Itt jelenik meg az első stratégiai kérdés: a core-szám növekedés valódi igényből fakad, vagy generációs kényszer? A modern CPU-k magas magszámmal érkeznek, de nem minden workload skálázódik lineárisan magokra. Ha a konszolidáció mértéke nem nő arányosan, a per-core licencelés aránytalan költségnövekedést eredményez.
A második kockázati pont a hosszú távú elköteleződés. Egy vmware upgrade sok esetben újabb többéves support- és subscription ciklust indít. Ha a licencelési modell bundle-alapon működik, a jövőbeni módosítások és részleges kivonások is komplexebbé válnak. Ez a fajta struktúra kiszámíthatóvá teszi a gyártó bevételét. A kérdés az, mennyire teszi kiszámíthatóvá a vállalati TCO-t.
A gyakorlatban a TCO elszállása nem egyetlen sorból áll. Több tényező összeadódása okozza.
- Core-növekedésből fakadó licencduplázódás.
- Bundle-csomag magasabb szintre ugrása.
- Support-szint emelkedése.
- Esetleges hálózati vagy storage-követelmény szigorodása.
Egy jól ismert döntési minta, hogy a refresh során a hardware kiválasztása után számolják újra a szoftverhatást. Ekkor viszont már a magszám adott. A mozgástér minimális.
Egy 3 éves projekció gyakran világosan megmutatja, hogy a server upgrade teljes költségének jelentős része nem a rackben, hanem a licencszerződésben jelenik meg.
Ez nem azt jelenti, hogy a VMware stack ne lenne megfelelő bizonyos környezetekben. A kérdés az, hogy az upgrade előtt valóban modellezett-e a licenc-, bundle- és core-hatás. Az infrastructure refresh sokszor azért válik váratlanul drágává, mert a költségmodell implicit volt. A platform maradt, a core-szám nőtt, a csomag szintje változott, a számla pedig csak később mutatta meg az összefüggést.
A szakmailag felelős döntési folyamat itt kezdődik: nem a hardware shortlistnél, hanem a teljes stack TCO modelljével. Ha a per-core licencelést hároméves horizonton újraszámoljuk, a support és subscription hatást hozzáadjuk, és a bundle-struktúrát is figyelembe vesszük, a refresh döntés karaktere megváltozik.
Az érdekes kérdés itt nem az, hogy drága-e a VMware. Hanem az, hogy létezik-e olyan platformmodell, ahol a compute-növekedés nem okoz aránytalan licencrobbanást, és ahol a storage, a virtualizáció és a menedzsment nem külön költségvonalon él.
Az integrált HCI-alapú platformok – például a Nutanix – éppen ezen a ponton hoznak eltérő költségstruktúrát. Nem külön SAN lifecycle, nem külön hypervisor komponens, hanem egységes data plane és egységes management stack. Ilyenkor a TCO nem kizárólag a core-szám függvénye, hanem az architektúra egyszerűsítéséből is építkezik.
A kérdés tehát nem az, hogy VMware vagy alternatíva. A kérdés az, hogy a következő refresh során melyik platformmodell ad nagyobb kontrollt a költség fölött.