Oltre la migrazione delle VM: cosa accade dopo la migrazione

Ho affrontato questo argomento decine di volte con i team responsabili dell'infrastruttura. Capita che abbiano appena completato o che siano nel bel mezzo di una migrazione di VM da un hypervisor obsoleto. La parte difficile è quasi terminata. O almeno così pensano.

Ecco l'aspetto di cui la maggior parte delle persone non parla: la migrazione in sé è la parte facile. È un'operazione tattica. Ha un inizio, una fase centrale e una fine ben definiti. Ciò che viene dopo, ovvero la modernizzazione della gestione dell'infrastruttura, è la fase in cui risiede il vero lavoro e, onestamente, la maggior parte del valore.

I cambiamenti del settore alla base di queste migrazioni rappresentano un'opportunità strategica per un'infrastruttura moderna. Grazie all'efficienza delle licenze, all'ottimizzazione dei costi e alla flessibilità dei fornitori, le organizzazioni scelgono Red Hat OpenShift Virtualization a un ritmo senza precedenti, con un aumento delle adozioni del 178% dall'inizio del 2024. Sebbene molte discussioni si concentrino esclusivamente sulla migrazione, il valore reale risiede nell'innovazione che avviene dopo il trasferimento.

Invece di considerare la migrazione come l'obiettivo finale, le organizzazioni lungimiranti la vedono come un trampolino di lancio. Questa transizione non riguarda solo la risoluzione delle sfide passate, ma serve a creare una base su cui sfruttare appieno le funzionalità di una piattaforma applicativa moderna e unificata, pronta per il futuro.

Ecco come si presenta, in pratica, la roadmap più ampia.

Fase 1: organizza il tuo ambiente Linux

Dopo la migrazione, dovresti valutare la proliferazione incontrollata dei sistemi operativi. La maggior parte delle organizzazioni utilizza un insieme di distribuzioni, versioni e contratti di supporto accumulati in anni di crescita organica piuttosto che per una scelta deliberata. Per chiarezza: in quanto azienda open source, non siamo qui per dirti che l’omologazione sia sempre la soluzione. L'eterogeneità offre vantaggi concreti. Può ridurre le modalità di errore condivise e limitare il raggio d'azione di una singola categoria di difetti. Questa diversità è in parte intenzionale e giustificabile.

Ma nelle grandi aziende, spesso non è così. Deriva da un debito tecnico. È l'istanza di Ubuntu creata per un progetto nel 2019 che ora esegue processi critici. È il sistema CentOS a cui nessuno ha applicato le patch dopo l'annuncio della fine del ciclo di vita (end of life, EOL). È il sistema Windows XP di cui nessuno conosce l'esatta funzione, ma che se andasse offline causerebbe seri problemi.

Dopo aver standardizzato il livello dell'hypervisor, il passaggio naturale successivo consiste nell'esaminare l'ambiente del sistema operativo guest. L'esecuzione di Red Hat Enterprise Linux (RHEL) insieme a Red Hat OpenShift offre un modello operativo più coerente: gestione delle patch unificata, percorsi di supporto coerenti e applicazione delle policy efficace in tutto l'ambiente. Dal sondaggio Global Tech Trends 2024 di Red Hat è emerso che il 45% delle aziende mette la modernizzazione dello stack applicativo in cima alle priorità. Le iniziative di modernizzazione efficaci seguono tutte lo stesso principio: eliminare la diversità ingiustificata dei sistemi operativi e mantenere quelli con un’utilità concreta per il business.

Fase 2: smetti di gestire la nuova piattaforma come quella precedente

Questo è l'errore che riscontriamo più spesso. I team completano la migrazione e poi continuano a gestire il nuovo ambiente esattamente come quello precedente. Stessi processi manuali. Stessi cicli di applicazione delle patch basati sui ticket. Stesse modifiche ad hoc tramite console.

L'ambiente post-migrazione è un foglio bianco. È probabilmente l'occasione migliore per definire correttamente la tua strategia di automazione.

Con Red Hat Ansible Automation Platform i team possono ridurre i tempi di implementazione manuale da settimane a ore. Nel momento in cui i playbook sono disponibili, il provisioning, l'applicazione delle patch e la conformità diventano automatici.

Se il tuo team opera già in ambito GitOps, Red Hat Advanced Cluster Management for Kubernetes applica lo stesso principio alla virtualizzazione. La policy diventa codice, archiviato in Git. Niente più variazioni di configurazione causate dalla console. Ciò si traduce in un controllo più rigoroso delle variazioni, rollout più rapidi e operazioni di manutenzione più prevedibili.

Ecco la verità: l'automazione non è solo un’opzione nel percorso di modernizzazione. È l'elemento che rende possibili le fasi successive.

Fase 3: esegui i carichi di lavoro dove è più opportuno

Non tutti i carichi di lavoro devono rimanere in una macchina virtuale (VM) per sempre. Alcuni sono ideali per la containerizzazione. Ma l'obiettivo non è containerizzare tutto. L'obiettivo è eseguire ogni carico di lavoro dove ha più senso.

OpenShift ti consente di gestire VM e container sulla stessa piattaforma, quindi non devi scegliere tra il "lift-and-shift di tutto" e la "riscrittura completa in ottica cloud native". Questa falsa alternativa ha causato un enorme spreco di tempo e denaro in tutto il settore. PNC Bank è un ottimo esempio di approccio pragmatico. Ha adottato nuovi standard e ridotto i tempi di consegna da otto settimane a un obiettivo di 10 giorni.

Questa è la fase in cui molti team si bloccano. La tecnologia non è la parte difficile. La difficoltà consiste nel capire quali carichi di lavoro spostare, quando e in quale ordine. Affidarsi a chi ha già affrontato questo percorso può fare la differenza tra un ciclo di modernizzazione di sei mesi e uno di 13. La ricerca di Forrester lo conferma. Un'organizzazione composita ha ridotto i tempi di deployment di OpenShift e di migrazione delle VM da 13 mesi a sette, grazie a una guida esperta.

Fase 4: pensa all'IA prima che sia necessario farlo

Il punto è questo: chi ha implementato l'IA con successo non l'ha fatto su un'infrastruttura disorganizzata. Secondo Gartner®, la spesa mondiale per l'IA nel 2026 raggiungerà i 2.500 miliardi di dollari.

Non suggerisco di fare progetti per l'IA prima di aver terminato la migrazione, ma i team che hanno ottenuto i risultati migliori avevano una base comune: un'infrastruttura pulita e automatizzata. I carichi di lavoro di IA sono esigenti in termini di elaborazione, storage e osservabilità. È preferibile risolvere questi problemi su una piattaforma Kubernetes native standardizzata piuttosto che sganciarci da ciò che abbiamo ereditato negli anni.

La migrazione sposta. La modernizzazione trasforma.

La migrazione ti allontana da una piattaforma che non vuoi più utilizzare. La modernizzazione crea la piattaforma di cui hai effettivamente bisogno. Si tratta di concetti fondamentalmente diversi e il divario tra loro è il punto in cui risiedono il vero lavoro e il valore reale.

Comunicato stampa di Gartner: Gartner prevede che la spesa mondiale per l'IA raggiungerà i 2.500 miliardi di dollari nel 2026, 15 gennaio 2026

GARTNER è un marchio di Gartner, Inc. e/o delle sue affiliate.