Quando un cliente mi chiede di valutare Azure Local, nella maggior parte dei casi la conversazione parte da un’esigenza concreta: sostituire VMware, rinnovare un datacenter oppure individuare un’alternativa alla piattaforma di virtualizzazione esistente.
È un punto di partenza assolutamente legittimo, soprattutto in una fase in cui molte organizzazioni stanno riconsiderando le proprie strategie infrastrutturali. Ma è anche il momento nel quale cerco di allargare la prospettiva. Perché valutare Azure Local confrontando soltanto le funzionalità di virtualizzazione significa rischiare di trascurare una parte importante del valore della soluzione.
A volte emerge anche un certo scetticismo quando si scopre che alla base di Azure Local c’è Hyper-V. È una reazione che comprendo: alcune percezioni sono ancora legate a esperienze di molti anni fa e non sempre tengono conto dell’evoluzione tecnologica della piattaforma.
Più in generale, mi accorgo spesso che Azure Local è ancora relativamente poco conosciuto, soprattutto nelle sue potenzialità più ampie. È una delle osservazioni che ci ha spinto a scrivere Azure Local Unleashed: contribuire a far conoscere una soluzione il cui valore, secondo noi, va ben oltre la sostituzione di un hypervisor.
Azure Local non dovrebbe essere considerato semplicemente una piattaforma sulla quale eseguire virtual machine, ma un elemento attraverso il quale far evolvere il modello operativo dell’infrastruttura.
Dalla scelta dell’hypervisor alla scelta del modello operativo
Per molti anni, le decisioni infrastrutturali sono state prevalentemente centrate sull’hypervisor. Le domande principali riguardavano le funzionalità di virtualizzazione, l’alta disponibilità, le prestazioni, lo storage e la compatibilità con l’ambiente esistente.
Era un approccio coerente con un IT nel quale l’obiettivo principale consisteva nel consolidare server e rendere più efficienti i datacenter.
Oggi lo scenario è diverso. Le applicazioni possono essere distribuite tra public cloud, datacenter aziendali, stabilimenti produttivi e sedi remote. Alcune dipendono da sistemi legacy, altre utilizzano container e servizi cloud-native. Alcune richiedono un controllo diretto dei dati, mentre altre traggono il massimo beneficio dall’elasticità e dai servizi gestiti del public cloud.
In questo contesto, la scelta della piattaforma non può essere ridotta alla domanda «dove eseguo le VM?». Deve tenere conto anche di come quelle risorse verranno gestite, protette, monitorate e modernizzate nel tempo.
È qui che vedo il cambiamento più interessante introdotto da Azure Local. La piattaforma permette di mantenere workload e dati negli ambienti controllati dall’organizzazione, adottando al tempo stesso strumenti e principi operativi coerenti con l’ecosistema Azure.
Non significa replicare integralmente il public cloud all’interno del datacenter, né ottenere automaticamente le stesse funzionalità disponibili in Azure. Significa piuttosto ridurre, dove possibile, le differenze operative tra ambienti che continueranno a essere fisicamente distinti.
Il primo elemento di valore: governance e operations
Tra i vantaggi di Azure Local, quello che considero più significativo è la possibilità di contribuire alla costruzione di un modello di governance e gestione coerente tra ambienti distribuiti.
Nella mia esperienza, raramente è il primo elemento che convince un cliente a prendere in considerazione la piattaforma. All’inizio prevalgono quasi sempre le caratteristiche infrastrutturali: costi, prestazioni, disponibilità, migrazione e compatibilità con i workload esistenti. Il valore della governance diventa generalmente più evidente quando si approfondisce come l’infrastruttura dovrà essere gestita nel tempo.
Pensiamo a un’organizzazione con numerose sedi produttive. Avere un cluster affidabile in ogni stabilimento è importante, ma non è sufficiente. Bisogna mantenere configurazioni coerenti, conoscere lo stato delle risorse, applicare controlli di sicurezza, pianificare gli aggiornamenti e verificare la conformità ai requisiti aziendali.
In questo scenario, tecnologie come Azure Arc ed Azure Policy permettono di estendere funzionalità di gestione e governance a risorse distribuite, coordinando inventario, policy e controlli attraverso il modello Azure.
È importante, però, fare una distinzione.
Azure Arc non è una funzionalità esclusiva di Azure Local. Può essere utilizzato anche con server tradizionali, ambienti VMware e cluster Kubernetes esterni ad Azure, estendendo a queste risorse diverse funzionalità di gestione, sicurezza e governance.
Il valore distintivo di Azure Local è quindi più ampio della semplice integrazione con Azure Arc. Azure Local nasce come piattaforma infrastrutturale integrata con Azure: il modello di provisioning delle risorse supportate, la gestione della piattaforma e del suo ciclo di vita, insieme alle funzionalità di governance e ai servizi compatibili, concorrono a costruire un’esperienza operativa più coerente con il cloud.
La differenza non sta quindi soltanto nel rendere visibili in Azure risorse esistenti, ma nel progettare l’infrastruttura locale come parte integrante di un modello operativo più esteso.
Il beneficio non consiste semplicemente nel disporre di una console comune. Consiste nel ridurre, nel tempo, il numero di eccezioni, procedure e strumenti differenti che un’organizzazione deve mantenere.
È un passaggio importante, perché la complessità di un’infrastruttura distribuita non dipende soltanto dal numero di server. Dipende soprattutto dalla capacità di governarli in maniera coerente.
Il secondo elemento: controllo locale e sovranità
Un altro aspetto fondamentale è la possibilità di mantenere l’esecuzione delle applicazioni vicino ai dati, agli utenti o ai processi produttivi.
In determinati scenari, questa necessità non deriva da una preferenza per l’on-premises, ma da requisiti oggettivi: latenza, dipendenze applicative, connettività, continuità operativa, sovranità del dato o vincoli normativi.
Questo è particolarmente evidente nel manufacturing, dove applicazioni IT e sistemi di fabbrica devono spesso convivere. Alcuni workload possono essere collocati nel public cloud, mentre altri devono rimanere vicini agli impianti per garantire prestazioni e continuità.
Azure Local permette di affrontare queste esigenze senza considerare necessariamente l’infrastruttura locale come un ambiente separato dal percorso di innovazione dell’organizzazione.
Anche il tema della sovranità assume una rilevanza crescente. La possibilità di mantenere dati e capacità di elaborazione all’interno di ambienti controllati dal cliente può contribuire a soddisfare requisiti specifici di localizzazione, sicurezza e controllo operativo.
È importante però ricordare che la localizzazione del dato non equivale automaticamente alla sovranità. Entrano in gioco anche giurisdizione, accessi amministrativi, responsabilità operative, dipendenze tecnologiche e requisiti di connettività.
Di conseguenza, Azure Local può rappresentare un componente di un’architettura orientata alla sovranità, ma non dovrebbe essere considerato da solo una garanzia di conformità. Il risultato dipende dalle scelte progettuali e dal modello operativo adottato.
Il valore, quindi, non è semplicemente quello di mantenere le applicazioni on-premises. È poterlo fare all’interno di una strategia tecnologica che combina controllo locale e integrazione con il cloud, secondo i requisiti effettivi dell’organizzazione.
Il terzo elemento: una piattaforma che può evolvere con le applicazioni
Il terzo elemento riguarda la capacità di accompagnare la modernizzazione applicativa nel tempo.
Un progetto Azure Local può iniziare con un’esigenza molto tradizionale: sostituire un’infrastruttura di virtualizzazione e migrare le macchine virtuali esistenti. Non c’è nulla di sbagliato in questo approccio. Il punto è non considerarlo necessariamente come il risultato finale.
Le applicazioni legacy non possono sempre essere modernizzate rapidamente. Spesso dipendono da vendor, versioni software, integrazioni o processi aziendali che richiedono tempi lunghi. Forzare una trasformazione immediata può introdurre rischi difficilmente giustificabili.
Azure Local permette di impostare un percorso graduale. Le VM possono rappresentare la base iniziale, mentre nuove esigenze applicative possono essere affrontate attraverso Kubernetes e altri servizi supportati dalla piattaforma.
Questo consente di far convivere, dove tecnicamente possibile, applicazioni tradizionali e workload più moderni, lasciando che ciascuno evolva secondo tempi e priorità differenti.
Il vantaggio è poter valorizzare l’investimento infrastrutturale iniziale anche per esigenze che non erano necessariamente presenti al momento dell’adozione.
Naturalmente, la disponibilità dei singoli servizi deve essere valutata rispetto alla versione della piattaforma, ai prerequisiti e allo scenario specifico. La coerenza con Azure non implica infatti una piena equivalenza tra i due ambienti.
Il principio rimane però importante: non progettare l’infrastruttura soltanto per ciò che deve eseguire oggi, ma anche per le possibilità di evoluzione che potrà offrire domani.
Un caso reale: quando sostituire VMware non era il vero obiettivo
Un’esperienza concreta può aiutare a comprendere meglio questo cambio di prospettiva.
Abbiamo lavorato con una multinazionale manifatturiera italiana, caratterizzata da diversi stabilimenti produttivi e da un ambiente IT articolato. L’organizzazione aveva già una presenza significativa nel public cloud, con numerosi workload in Azure, servizi di virtual desktop, machine learning e alcune applicazioni ospitate anche su AWS.
Non si trattava quindi di un cliente che doveva ancora scoprire il cloud. Esisteva già una strategia strutturata, accompagnata da attività di governance su costi, compliance, gestione operativa, standard architetturali e documentazione.
La criticità principale era invece nell’infrastruttura on-premises: un ambiente VMware cresciuto nel tempo, composto da sistemi eterogenei, alcuni dei quali ormai datati, con problemi di prestazioni, limiti di scalabilità e una complessità gestionale crescente.
La necessità iniziale era individuare una soluzione alternativa. Tuttavia, anziché partire direttamente dal confronto delle funzionalità delle piattaforme, abbiamo impostato la valutazione sulla base dei requisiti e degli obiettivi dell’organizzazione.
Il primo elemento era la necessità di mantenere localmente alcuni workload legati ai processi produttivi. Il secondo riguardava la continuità con le competenze già presenti nel team IT. Il terzo era la possibilità di integrare la nuova piattaforma con l’ecosistema Azure e con il modello di governance già adottato. A questi si aggiungevano naturalmente sostenibilità economica, prestazioni, affidabilità e possibilità di evoluzione futura.
Abbiamo quindi analizzato differenti alternative: mantenere VMware attraverso un rinnovo dell’infrastruttura, valutare Azure VMware Solution, migrare i workload direttamente in Azure IaaS, adottare Hyper-V su Windows Server oppure introdurre Azure Local.
Ogni soluzione presentava vantaggi e compromessi.
Il rinnovo di VMware avrebbe garantito continuità tecnologica e operativa, ma non avrebbe necessariamente risolto alcune delle criticità economiche e strategiche alla base della valutazione.
Azure VMware Solution avrebbe permesso di mantenere il modello VMware, spostando però i workload nelle region Azure. Una possibilità interessante per determinati scenari, ma non necessariamente coerente con le esigenze di latenza e autonomia degli stabilimenti.
La migrazione diretta verso Azure IaaS aveva senso per alcune applicazioni, ma non per quelle che dovevano continuare a essere eseguite localmente.
Hyper-V su Windows Server rappresentava un’alternativa concreta, anche grazie alle competenze già presenti nel team e al patrimonio di licensing disponibile. Una parte del modello operativo, tuttavia, avrebbe richiesto ulteriori integrazioni tra strumenti e processi di gestione.
Azure Local è emerso come un’opzione particolarmente coerente con l’insieme dei requisiti: esecuzione locale, competenze Hyper-V già disponibili, integrazione con Azure e possibilità di adottare un modello di governance trasversale.
Anche il licensing rappresentava un elemento favorevole. Il cliente disponeva infatti di licenze Windows Server Datacenter con Software Assurance, che, in presenza dei requisiti di idoneità previsti da Microsoft, consentono di utilizzare Azure Hybrid Benefit per ridurre specifiche componenti di costo della piattaforma.
L’aspetto più interessante, però, non è stato il confronto tra le singole alternative.
È stato il metodo utilizzato per scegliere.
Abbiamo definito insieme al cliente criteri di valutazione condivisi, attribuendo a ciascuno un peso coerente con le priorità dell’organizzazione. Questo ci ha permesso di confrontare piattaforme differenti senza limitarci a una semplice matrice di funzionalità.
Non cercavamo la soluzione con il maggior numero di caratteristiche tecniche, ma quella che rispondeva meglio ai requisiti e al modello operativo che l’organizzazione intendeva costruire.
Il risultato della valutazione non riguardava quindi soltanto la possibile sostituzione di VMware. Riguardava l’opportunità di rendere più coerente il governo dell’infrastruttura locale con una strategia ibrida già esistente.
Ed è proprio questo il tipo di valore che rischia di non emergere quando Azure Local viene confrontato con altre soluzioni esclusivamente come piattaforma di virtualizzazione.
Valutare il valore senza ignorare i compromessi
Naturalmente, Azure Local non è la scelta migliore per qualsiasi scenario.
Uno dei primi aspetti da considerare è l’hardware. La piattaforma richiede configurazioni validate e supportate, quindi il riutilizzo di sistemi già presenti nel datacenter può risultare complesso o non praticabile. È un elemento importante, soprattutto quando il cliente desidera valorizzare investimenti hardware ancora recenti.
Un secondo fattore è la gestione del ciclo di vita. Azure Local è una piattaforma in continua evoluzione e richiede una gestione strutturata degli aggiornamenti. Questo permette di beneficiare di miglioramenti e nuove funzionalità, ma richiede anche processi operativi, pianificazione e competenze adeguate.
È quindi essenziale valutarne non soltanto il deployment iniziale, ma anche la sostenibilità della gestione nel tempo.
Lo stesso vale per la connettività verso Azure. L’integrazione con il cloud è parte integrante del valore della piattaforma, ma il livello di dipendenza e le funzionalità disponibili devono essere analizzati rispetto allo specifico modello di deployment.
Infine, c’è il tema economico. Azure Local può presentare vantaggi significativi rispetto ad altre piattaforme, specialmente in presenza di condizioni di licensing favorevoli. Tuttavia, limitare il confronto al costo dell’hardware e delle licenze significa trascurare una parte importante della decisione.
Quando si valutano piattaforme differenti, il rischio è costruire una tabella molto lunga e limitarsi a contare le funzionalità disponibili. È un esercizio utile per verificare i requisiti tecnici, ma raramente sufficiente per una decisione strategica.
Bisogna invece domandarsi quale soluzione renda più sostenibili, nel tempo, automazione, monitoraggio, sicurezza, policy, aggiornamenti e gestione delle risorse distribuite.
Il vero confronto non è soltanto tra piattaforme, ma tra i modelli operativi che quelle piattaforme permettono di costruire.
Modernizzare l’infrastruttura significa anche modernizzare il modo di gestirla
Valutare Azure Local soltanto attraverso il confronto con altre piattaforme di virtualizzazione rischia di limitare la discussione a ciò che la tecnologia permette di fare oggi, trascurando ciò che potrebbe consentire di costruire domani.
Le caratteristiche infrastrutturali rimangono fondamentali. Prestazioni, affidabilità, supportabilità e costi devono continuare a guidare qualsiasi valutazione. Ma la scelta dovrebbe considerare anche il modo in cui l’organizzazione intende gestire, proteggere e modernizzare la propria infrastruttura nei prossimi anni.
Le evoluzioni della piattaforma, dai servizi applicativi agli scenari edge e AI, possono ampliare progressivamente le opportunità disponibili. Non tutte queste capacità sono necessariamente adatte o disponibili per ogni scenario, ma rappresentano un elemento da considerare quando si progetta un’infrastruttura destinata a durare nel tempo.
È questa la prospettiva che abbiamo voluto sviluppare anche in Azure Local Unleashed: andare oltre la tecnologia per comprenderne il ruolo all’interno di una strategia di modernizzazione più ampia.
Nel prossimo articolo partiremo proprio da una delle situazioni in cui questo cambio di prospettiva può produrre i risultati più concreti: il rinnovo dell’infrastruttura. Perché un hardware refresh può essere molto più di una semplice sostituzione tecnologica.