Topgolf sta passando da cluster Dell VxRail a sei nodi e 35 TB a cluster VergeOS a tre nodi e 5 TB in oltre 100 sedi. Il numero interessante non è soltanto il dimezzamento dei server: è il metodo usato per cambiare piattaforma senza trasformare ogni sede in un progetto diverso.

Il caso è utile anche per una PMI con tre host, un piccolo data center o alcune filiali. Uscire da VMware non significa scegliere un hypervisor più economico e convertire le macchine virtuali. Significa ricostruire l’elenco delle dipendenze, misurare le prestazioni, provare backup e ripristino, definire il rollback e soltanto dopo spostare i workload a ondate.

Topgolf ha un perimetro molto più grande di una PMI: ogni venue funziona come un edge data center autonomo e ospita servizi Kubernetes, server Windows e Linux, sistemi video, applicazioni di conformità e analisi in tempo reale. Proprio per questo il caso rende visibile una regola che vale a ogni scala: la migrazione riesce quando il nuovo ambiente viene validato come sistema operativo completo, non quando supera una demo del solo hypervisor.

Cosa dimostra davvero il caso Topgolf

Il case study pubblicato da VergeIO descrive una standardizzazione su oltre 100 venue, uffici e data center centrali. Nei siti, Topgolf sta sostituendo cluster VxRail a sei nodi con configurazioni VergeOS a tre nodi su hardware Dell PowerEdge. La capacità dichiarata scende da 35 TB a 5 TB grazie anche alla deduplicazione globale del nuovo stack.

Il progetto non riguarda solo il compute. VergeOS assorbe funzioni prima distribuite tra VMware, VxRail e Rubrik: virtualizzazione, storage, rete, snapshot, replica e protezione dei dati. Il team ha inoltre costruito automazioni via API e Terraform, organizzando aggiornamenti e disaster recovery per tre aree geografiche statunitensi.

I risultati operativi dichiarati sono concreti:

  • un aggiornamento dell’intera flotta richiede tre settimane invece di due o tre mesi;
  • una sequenza di spegnimento per perdita di alimentazione parte automaticamente e si completa in meno di 15 minuti, contro 30-45 minuti di intervento manuale;
  • in un test, una sede è stata migrata in un giorno e il cluster è stato aggiornato il giorno successivo durante l’orario di attività;
  • il team ha eliminato il prodotto di backup separato dopo avere validato snapshot, riparazione e replica integrati.

Questi numeri provengono dal fornitore scelto e dalle dichiarazioni del team Topgolf raccolte nello stesso case study. Non sono un benchmark indipendente e non vanno trasferiti nel business case di un’altra azienda. Ars Technica ha riportato risparmi superiori a 11,3 milioni di dollari, ma anche quel valore dipende dalla scala, dai contratti e dall’architettura di Topgolf. La parte riutilizzabile non è la cifra: è la sequenza di verifica.

Il trigger economico non basta per scegliere

Broadcom ha annunciato ufficialmente il passaggio delle offerte VMware a licenze in abbonamento e la fine della vendita delle licenze perpetue e dei relativi rinnovi Support and Subscription. La documentazione più recente di VMware vSphere Foundation 9.1 precisa inoltre che chi possiede licenze perpetue deve passare al modello subscription per aggiornare a quella versione.

Questo cambia il momento della decisione: non basta più confrontare un rinnovo con il costo storico. Bisogna mettere sul tavolo tre scenari distinti: rinnovare e restare, migrare verso una piattaforma alternativa oppure spostare una parte dei workload su servizi gestiti o cloud. Ogni scenario deve coprire lo stesso perimetro funzionale.

La mia take è netta: confrontare soltanto il prezzo per core produce un business case falso. La voce corretta è il costo annuo del servizio infrastrutturale, che comprende almeno:

  • licenze di hypervisor, gestione, storage, replica e backup;
  • hardware, garanzie, energia e capacità inutilizzata;
  • monitoraggio, patching e ore operative del team;
  • formazione e supporto durante la transizione;
  • costo di una finestra di fermo e valore del rollback;
  • uscita futura dalla nuova piattaforma.

Nel caso Topgolf il risparmio nasce dalla combinazione: meno nodi, hardware non vincolato a un appliance HCI, eliminazione di licenze e strumenti separati, meno tempo per aggiornamenti e procedure automatizzate. Se una PMI cambia hypervisor ma conserva la stessa frammentazione tra storage, backup e console, potrebbe spostare il costo senza ridurlo.

Prima fase: inventario e baseline misurabile

La migrazione deve iniziare con un inventario esportabile, non con la shortlist dei vendor. Per ogni macchina virtuale servono proprietario, funzione aziendale, sistema operativo, vCPU, RAM, spazio allocato e usato, IOPS, latenza, finestre di backup, RPO e RTO. Vanno registrate anche le dipendenze esterne: VLAN, firewall, DNS, certificati, share, appliance, dongle USB, server di licenza e integrazioni con Active Directory.

Il punto debole è quasi sempre ciò che non compare in vCenter. Un gestionale può usare un IP hardcoded; un job mensile può contattare una share non documentata; il backup può avere il supporto ufficiale per VMware ma non per il target. Per questo la mappa delle dipendenze va osservata per più settimane e verificata con i proprietari applicativi.

Costruisci poi una baseline sui workload reali. Non servono cento metriche: CPU e memoria di picco, latenza storage, IOPS, traffico di rete, tempo di avvio, durata dei backup, tempo di ripristino e tasso di errore dell’applicazione sono sufficienti per il primo confronto. La baseline impedisce una frase pericolosa: «sembra andare bene».

Infine classifica le macchine in quattro gruppi: facili da migrare, compatibili con lavoro aggiuntivo, da modernizzare e da lasciare temporaneamente dove sono. Le applicazioni legacy, i database con licenze legate ai core e gli appliance virtuali certificati solo su VMware non devono finire nella prima ondata.

Seconda fase: un proof of concept con gate

Topgolf ha condotto un proof of concept di più mesi prima del rollout nazionale. Una PMI può usare un periodo più breve, ma non dovrebbe ridurre il perimetro dei test. Il pilot corretto include almeno un servizio di sviluppo, un’applicazione di produzione tollerante e un workload con I/O rappresentativo.

Prima di iniziare scrivi i criteri di accettazione. Un esempio pratico:

  • prestazioni entro il 10% della baseline, salvo miglioramenti documentati;
  • backup completato e ripristino di una VM provato;
  • failover e failback eseguiti, non soltanto descritti;
  • monitoraggio, log e alert visibili nella console operativa;
  • patch del cluster completata senza interrompere il servizio scelto;
  • rollback verso la sorgente eseguito almeno una volta;
  • proprietario dell’applicazione che approva il risultato.

Il rollback merita un criterio temporale. «Possiamo tornare indietro» non basta: serve sapere chi prende la decisione, quale errore la attiva, entro quanti minuti e quale copia dei dati diventa autorevole. Se il workload continua a ricevere scritture dopo il cutover, riaccendere la vecchia VM senza una procedura può creare una divergenza più grave del guasto iniziale.

Lo stesso rigore vale per l’automazione. Prima si prova il flusso manuale, poi si codifica il runbook, infine si forza un errore controllato. Topgolf ha ottenuto valore dalle API perché spegnimento, riavvio e notifiche sono diventati osservabili e ripetibili. Copiare uno script senza criteri di uscita trasforma invece un errore manuale in un errore più veloce.

Backup integrato non significa rischio eliminato

Nel caso Topgolf la piattaforma di destinazione ha sostituito Rubrik dopo una validazione estesa. È una scelta possibile, non una raccomandazione universale. Quando hypervisor, storage, snapshot e replica condividono lo stesso controllo, l’operatività si semplifica ma aumenta il rischio di dominio comune: una configurazione errata, una credenziale compromessa o un problema della piattaforma può toccare più livelli insieme.

Prima di eliminare il backup separato, verifica quattro proprietà: copie immutabili, credenziali e ruoli distinti, una destinazione fuori dal cluster e un ripristino provato su un ambiente isolato. Uno snapshot non è automaticamente un backup e una replica non protegge da ogni cancellazione se propaga lo stesso evento al sito secondario.

Per una PMI manterrei almeno una copia fuori dal dominio amministrativo della nuova piattaforma durante tutta la migrazione e per il periodo di stabilizzazione. Solo dopo due o tre cicli di ripristino riusciti valuterei il consolidamento. Il risparmio sulla licenza di backup vale meno di una sola giornata di dati non recuperabili.

La prova deve includere anche il disastro scomodo: perdita di un nodo, indisponibilità della rete, credenziale revocata, immagine corrotta e ripristino di un singolo file. Misura il tempo dal ticket alla disponibilità del dato. È questo il valore che il responsabile aziendale può confrontare con l’RTO concordato.

Terza fase: migrazione a ondate e uscita controllata

Una volta approvato il pilot, organizza le ondate per dipendenze e rischio, non per reparto. Ogni gruppo deve avere un runbook con orari, responsabili, ultimo sync, spegnimento della sorgente, validazione tecnica, test applicativo e decisione di chiusura. Le VM originali restano spente e protette da riavvii accidentali finché il gate della nuova ondata non è superato.

Topgolf ha standardizzato la stessa architettura nei siti e scagliona le operazioni per fuso orario. Una PMI può applicare lo stesso principio con template di rete, naming, policy di backup, dashboard e checklist identiche. La standardizzazione riduce il numero di decisioni durante la notte del cutover e rende gli incidenti della prima ondata una correzione per le successive.

Dopo ogni migrazione confronta le metriche con la baseline, esegui un restore e aggiorna CMDB, monitoraggio e documentazione. Non dismettere host e licenze finché non è trascorso il periodo di stabilizzazione concordato. Prima del rinnovo verifica inoltre date, clausole di recesso e supporto: la scadenza commerciale non deve diventare il calendario tecnico del progetto.

Un piano minimo di 30 giorni può essere organizzato così:

  1. Giorni 1-7: inventario, contratti, metriche e mappa delle dipendenze.
  2. Giorni 8-14: target di prova, rete, storage, backup e monitoraggio.
  3. Giorni 15-21: pilot, rollback, restore e test con il proprietario applicativo.
  4. Giorni 22-30: business case corretto con i dati del pilot e piano delle ondate.

Al giorno 30 la decisione può ancora essere «restiamo su VMware». Non è un fallimento: è una scelta fondata su costi e rischi osservati. Il vero errore è firmare il rinnovo per inerzia o migrare per reazione, senza sapere quali funzioni il vecchio stack stava già svolgendo.

La lezione operativa per le PMI

Il caso Topgolf non dimostra che VergeOS sia la risposta per ogni azienda. Dimostra che un’uscita da VMware diventa gestibile quando l’organizzazione riduce le varianti, prova il sistema completo e misura ogni gate. La piattaforma di destinazione può essere diversa; la disciplina non cambia.

La prima domanda da fare a un fornitore non è «quanto costa?», ma «come provo backup, aggiornamento, failover e ritorno alla sorgente sui miei workload?». La seconda è «quali componenti e competenze dovrò aggiungere per ottenere ciò che oggi considero implicito?». Solo la terza riguarda il prezzo per core.

In pratica: prepara l’inventario prima della scadenza, scegli un pilot con basso raggio d’impatto, conserva una copia indipendente dei dati e non dismettere la sorgente al primo avvio riuscito. Il risparmio si materializza dopo che il nuovo stack è ripetibile e supportabile. Prima di quel punto è soltanto una previsione nel foglio di calcolo.

Fonti