„Máme odejít z VMware?“ zní rozhodně, ale obvykle je to špatná první otázka. Stovky různých aplikací, databází, závislostí, recovery požadavků a smluv redukuje na jediné platformní rozhodnutí. Užitečnější otázka zní: kde má každý workload běžet dál a co musí být splněno, než se přesune?
Tento rámec vědomě připouští čtyři výsledky. Některé workloady zůstanou na VMware. Některé přesuneme s minimem změn. U dalších dává smysl aplikační modernizace. Zbytek má být vyřazen místo migrace. To není nerozhodnost, ale řízení technologického portfolia.
Proč workload placement řešit právě teď
Ekonomiku infrastruktury už nelze popsat jednoduchým porovnáním „datacentrum versus public cloud“. Vedení musí zahrnout softwarové licence, private cloud, veřejný cloud, kapacitu datacentra, AI infrastrukturu i náklady na souběžný provoz během přechodu.
State of FinOps 2026 tento posun potvrzuje: 64 % respondentů řídí licensing, 57 % private cloud, 48 % náklady datacentra a 98 % AI spend. Pre-deployment architecture costing současně patří mezi nejžádanější schopnosti. Placement a ekonomika se proto musí potkat ještě před podpisem závazku.
Podobný směr ukazuje vyhledávání. V našem srpnovém porovnání předchozích 12 měsíců měl v Google Trends výraz „VMware cloud“ výrazně vyšší relativní zájem než „VMware alternative“. Další porovnání ukázalo silnější private a hybrid cloud než obecné „infrastructure modernization“. Trends používá normalizovaný index 0–100, ne absolutní počet hledání, ale směr je užitečný: firmy hledají provozní varianty, nejen náhradní produkt.
Čtyři výsledky workload placementu
| Rozhodnutí | Kdy dává smysl | Potřebné důkazy | Typický další krok |
|---|---|---|---|
| Ponechat | Stabilní, těsně provázaný, na latenci citlivý nebo regulovaný workload s přijatelnou ekonomikou. | Podporovaný lifecycle, otestované recovery, kapacitní plán a jasný vlastník. | Hardenovat, automatizovat, zdokumentovat a stanovit datum další revize. |
| Přesunout | Infrastrukturně vázaný workload, který může získat odolnost nebo flexibilitu bez redesignu aplikace. | Mapa závislostí, připravená landing zone, TCO, testovací plán a rollback. | Rehost nebo relocation v řízené migrační vlně. |
| Modernizovat | Aplikace omezená rychlostí releasů, škálováním, spolehlivostí nebo zastaralými komponentami. | Business case změny, product owner, engineering kapacita a měřitelný výsledek. | Replatform, kontejnerizace nebo selektivní refaktor. |
| Vyřadit | Duplicitní, nepodporovaný, nepoužívaný nebo málo hodnotný systém. | Data o používání, retenční plán, potvrzené závislosti a odpovědný schvalovatel. | Archivace nutných dat, odstranění integrací a bezpečný decommission. |
Rozhodnutí „ponechat“ nesmí znamenat „ignorovat“. Potřebuje datum expirace, lifecycle předpoklady a stejné důkazy o odolnosti jako migrovaný workload. Stejně tak není „modernizovat“ automaticky lepší než „přesunout“. Modernizace spotřebovává vzácnou produktovou a engineering kapacitu a musí soutěžit s dalšími investicemi.
Každý workload hodnoťte v pěti dimenzích
1. Obchodní kritičnost
Určete podporovaný proces, dopad na tržby nebo provoz, přijatelný výpadek, špičková období a výkonného vlastníka. Technický tým nemá odvozovat kritičnost z využití CPU nebo storage.
2. Technický fit a závislosti
Zmapujte upstream a downstream systémy, data gravity, latenci, závislost na hardwaru, podporu operačního systému a integrační vzory. Jednoduchý virtuální server může být složitý přesun, pokud jeho závislosti nikdo nezná.
3. Ekonomika a závazky
Porovnávejte realistickou jednotku služby, ne ceníkovou cenu virtuálního stroje. Zahrňte licence, support, facility, konektivitu, backup, lidi, commitments a dočasný překryv starého a nového prostředí. Předpoklady zapisujte tak, aby je finance mohly rozporovat.
4. Riziko, bezpečnost a kontrola dat
Hodnoťte recovery evidence, privileged access, segmentaci, šifrování, rezidenci, auditní požadavky a blast radius změny. Riziko může ospravedlnit přesun i setrvání; rozhodují důkazy.
5. Provozní připravenost
Ptejte se, kdo workload po rozhodnutí vlastní. Identity, observabilita, incident response, patching, deployment, alokace nákladů a SLO potřebují vlastníky v přechodném i cílovém stavu.
Navrhněte jeden provozní model dřív než dvě platformy
Hybridní infrastruktura selhává, když se každá platforma stane organizačním ostrovem. VMware má jeden přístupový model, Google Cloud druhý; monitoring končí na hranici; aplikační týmy používají v jednom prostředí tickety a ve druhém pipeline; finance nedokážou porovnat náklady.
Cílový model má definovat společné řízení napříč prostředím:
- Identity: jednotný lifecycle identit, least privilege a dohledatelné zvýšení oprávnění.
- Networking: jasné trust zóny, odpovědnost za routing, DNS, egress control a viditelné závislosti.
- Delivery: infrastructure as code, opakovatelné prostředí a schválené deployment paths.
- Operations: vlastnictví služby, SLO, telemetrie, incident command a testování recovery.
- Economics: porovnatelná alokace a forecast licencí, datacentra, cloudu a AI kapacity.
Tady se propojuje hybridní cloud s platform engineeringem. Katalog služeb nebo golden path není jen zlepšení developer experience. Může být rozhraním, které skryje rozdíly platforem a současně zachová jednotné guardraily.
Přidejte AI placement bez nafukování roadmapy
AI přináší druhou placement debatu. Přístup k modelům může zvýhodňovat public cloud, zatímco citlivá data, předvídatelná inference, latence nebo suverenita mohou vyžadovat privátní či hybridní nasazení. Google dnes výslovně nabízí Google Distributed Cloud pro AI v zákaznickém datacentru, na edge i v air-gapped prostředí.
Použijte stejnou disciplínu: určete hranici dat, cílovou latenci, požadovaný model, profil kapacity, jednotkovou ekonomiku a provozního vlastníka. Nekupujte private AI infrastrukturu bez změřeného workloadu a neposílejte regulovaná data do veřejného endpointu bez ověřeného control modelu.
Proměňte matici v roadmapu
- Nejprve stabilizujte. Uzavřete recovery, identity a observability mezery, které by jakoukoli změnu učinily nebezpečnou.
- Odstraňte zjevný odpad. Vyřaďte nepoužívané systémy a duplicitní kapacitu před sizingem cíle.
- Pilotujte reprezentativní workload. Musí být dost významný pro otestování provozního modelu a současně reverzibilní.
- Stavte vlny podle závislostí. Workloady neseskupujte jen podle oddělení nebo počtu serverů.
- Používejte decision gates. Před každou vlnou znovu ověřte hodnotu, ekonomiku, recovery evidence a připravenost týmu.
Užitečná roadmapa pracuje s horizonty 90, 180 a 365 dní. První má vytvořit důkazy a odstranit blokátory. Druhý škáluje ověřený vzor. Třetí řeší nejhodnotnější modernizaci, ne pouze zbytek serverů.
Nejčastější chyby
- Určení jediné cílové platformy před inventurou a mapou závislostí.
- Porovnávání ceny infrastruktury bez licencí, lidí a přechodného překryvu.
- „Dočasný hybrid“ bez provozního modelu a exit kritérií.
- Přesun technického dluhu vydávaný za modernizaci.
- Landing zone bez definice přístupu a odpovědnosti aplikačních týmů.
- Měření úspěchu počtem VM místo odolnosti, nákladů, rychlosti delivery a odstraněného rizika.
Nejmenší užitečný výstup
Obhajitelný workload placement nevyžaduje roční transformační program. Nejmenším užitečným výstupem je workload matice, orientační TCO, cílový control model, risk register a seřazená roadmapa s vlastníky. Musí být jasné, co víme, co předpokládáme a jaké důkazy ještě chybí.
Pokud u některých workloadů vyjde „zůstat na VMware a zlepšit provoz“, jde o platný výsledek. Jestli má jiná skupina přejít do Google Cloud, modernizovat se na GKE nebo být vyřazena, stejný rámec musí vysvětlit proč.
Zdroje a metodika
- FinOps Foundation: State of FinOps 2026 — rozsah technologických nákladů, priority a zapojení do rozhodování.
- Google Cloud: New innovations in Google Distributed Cloud — hybridní, sovereign a on-premises AI.
- Metodika Google Trends — normalizace, vzorkování a omezení malých objemů.
Nejdřív rozhodnutí o workloadech, potom migrační backlog.
Hybrid Infrastructure Blueprint od Cloudpeakify promění data o prostředí, nákladech a rizicích v placement matici, cílový provozní model a použitelnou roadmapu.