Durante gli incontri con clienti e IT decision maker mi capita ancora spesso di sentire frasi come: “Il datacenter lo manteniamo solo per i workload legacy” oppure “Prima o poi vorremmo portare tutto in Azure”.
Sono affermazioni comprensibili. Per molti anni, del resto, il percorso verso il cloud è stato raccontato come una progressione quasi lineare: dal datacenter tradizionale all’hybrid cloud e, infine, al public cloud. In questa rappresentazione, l’ibrido era soprattutto una fase intermedia, una condizione temporanea destinata progressivamente a scomparire.
La realtà che vedo oggi nei progetti è diversa.
Hybrid is not a transition strategy; it is becoming a deliberate operating model.
Questo non significa che il public cloud abbia perso centralità. Al contrario, continua a rappresentare la scelta migliore per moltissimi workload. Significa però smettere di considerare cloud e on-premises come due destinazioni alternative e iniziare a ragionare su un modello nel quale applicazioni e dati possono essere distribuiti intenzionalmente in ambienti differenti.
La domanda, quindi, non dovrebbe più essere “cloud oppure on-premises?”, ma “dove ha più senso eseguire questo specifico workload?”
Ogni workload ha esigenze differenti
Il punto di partenza dovrebbe essere sempre il workload. Applicazioni differenti hanno caratteristiche differenti e, allo stesso modo, public cloud e infrastrutture locali offrono benefici distinti. L’obiettivo non è stabilire a priori quale modello sia migliore, ma far incontrare le esigenze dell’applicazione con le caratteristiche della piattaforma.
È da questa combinazione che nasce la possibilità di rendere ogni workload contemporaneamente efficace ed efficiente.
Ci sono, ad esempio, scenari nei quali la prossimità fisica continua a essere determinante. Uno dei casi che incontro frequentemente riguarda il settore manufacturing. Immaginiamo un’organizzazione con un datacenter principale a Bologna e stabilimenti produttivi distribuiti in diversi Paesi. Alcune applicazioni MES devono necessariamente rimanere vicine agli impianti che controllano, perché latenza, continuità della connettività e dipendenze dai sistemi locali possono avere un peso molto maggiore dell’elasticità offerta dal public cloud.
In uno scenario di questo tipo, spostare un workload nel cloud semplicemente perché “la strategia è cloud-first” rischierebbe di significare adattare l’applicazione alla piattaforma, invece di scegliere la piattaforma in funzione dell’applicazione.
Ed è esattamente il contrario di ciò che dovrebbe avvenire.
Latenza e connettività non sono gli unici fattori
La prossimità è soltanto uno dei criteri da considerare. Un altro elemento importante è il costo.
Esiste una convinzione piuttosto diffusa secondo cui il cloud sia intrinsecamente più economico dell’infrastruttura locale oppure, all’opposto, che migrare verso il cloud sia necessariamente molto costoso. Entrambe le affermazioni, se considerate in termini assoluti, hanno poco significato.
Un workload stabile e prevedibile può avere un profilo economico molto diverso da uno caratterizzato da forti variazioni della domanda. Un’applicazione che necessita di grande elasticità presenta esigenze differenti rispetto a un sistema destinato a utilizzare sostanzialmente la stessa capacità per molti anni. Per questo motivo, le decisioni dovrebbero basarsi su una reale analisi del Total Cost of Ownership (TCO), e non su convinzioni costruite in passato o su percezioni non supportate dai dati.
Altrettanto importanti sono data sovereignty e compliance. In determinati settori, la posizione dei dati, il controllo operativo, i requisiti normativi e le caratteristiche specifiche dell’organizzazione possono influenzare direttamente le scelte architetturali.
Workload placement significa quindi bilanciare contemporaneamente più dimensioni: latenza e dipendenze locali, connettività, costi, sovranità, compliance, continuità operativa e caratteristiche dell’applicazione.
È proprio questo approccio multidimensionale che abbiamo cercato di mettere al centro della strategia Adaptive Cloud anche in Azure Local Unleashed.
Ma mantenere tutto on-premises non è una strategia migliore
Se considero sbagliato migrare tutto verso il public cloud per principio, considero altrettanto rischioso mantenere tutto on-premises semplicemente perché è sempre stato così.
Anche questa situazione è ancora molto comune. A volte dipende dalla mancanza di conoscenza delle alternative, altre dalla paura di affrontare qualcosa di nuovo. E poi c’è il classico “finché funziona, non lo tocco”, un atteggiamento comprensibile dal punto di vista operativo, ma che può diventare un limite quando impedisce persino di valutare scenari differenti.
Lo stesso accade quando una migrazione verso il cloud viene esclusa a priori perché considerata troppo costosa, senza aver effettuato un vero confronto economico. In alcuni casi, continuare a possedere e gestire infrastruttura locale significa mantenere server sovradimensionati, cicli di refresh, contratti di supporto, datacenter, energia, competenze specialistiche e processi operativi che potrebbero non essere più giustificati dal valore del workload.
Per determinate applicazioni, il public cloud può invece rappresentare chiaramente l’opzione migliore.
Ancora una volta, quindi, il problema non è scegliere una parte. È scegliere bene.
Cosa è cambiato rispetto all’hybrid cloud di qualche anno fa
Le infrastrutture distribuite non sono una novità. Le aziende gestiscono datacenter, filiali, impianti produttivi e sedi remote da decenni. La vera differenza rispetto al passato è la maturità raggiunta dagli strumenti con cui oggi possiamo governare questi ambienti.
Storicamente, distribuire l’infrastruttura significava spesso distribuire anche gli strumenti di gestione. Ogni ambiente poteva avere console differenti, procedure specifiche, strumenti di monitoraggio diversi, modelli di sicurezza autonomi e processi di aggiornamento indipendenti. Era hybrid dal punto di vista dell’infrastruttura, ma raramente lo era dal punto di vista operativo.
Oggi questo paradigma sta cambiando. Control plane comuni, policy centralizzate, automazione, observability e, progressivamente, strumenti basati sull’intelligenza artificiale permettono di separare sempre di più il luogo nel quale un workload viene eseguito dal modo in cui viene governato.
Ed è probabilmente questo uno dei passaggi più importanti nell’evoluzione dell’hybrid cloud: la distribuzione non deve necessariamente significare frammentazione.
È il principio alla base di tecnologie come Azure Arc, ma considero il concetto più importante del singolo prodotto. Il vero obiettivo è poter applicare governance, policy, security, monitoraggio e automazione in maniera coerente, indipendentemente dal luogo nel quale si trova una risorsa.
Il workload placement non è più necessariamente definitivo
C’è poi un’altra differenza significativa rispetto al passato. Le decisioni infrastrutturali erano spesso considerate definitive: una volta scelta una piattaforma e completato il progetto, spostare nuovamente un workload poteva risultare costoso, complesso e rischioso.
Oggi le tecnologie di migrazione, replica, automazione e gestione sono molto più mature. Questo rende il workload placement una decisione che può essere rivalutata nel tempo, anziché essere considerata immutabile.
Un’applicazione che oggi deve risiedere nel datacenter potrebbe domani essere modernizzata e spostata verso il public cloud. Un workload nato nel cloud potrebbe invece richiedere maggiore prossimità ai dati o a un impianto produttivo. Una nuova normativa potrebbe modificare i requisiti di sovranità, così come una variazione del profilo di utilizzo potrebbe rendere economicamente più conveniente una piattaforma differente.
In questo scenario, la capacità di cambiare decisione diventa quasi importante quanto la decisione iniziale. L’architettura deve quindi essere progettata non solo per rispondere ai requisiti di oggi, ma anche per mantenere aperte opzioni future.
Il vero problema è spesso la governance
È qui che emerge uno degli errori strategici che vedo più frequentemente nelle organizzazioni: scegliere prima la piattaforma e analizzare successivamente i workload.
Dovrebbe avvenire il contrario. Prima bisogna comprendere applicazioni, dati, dipendenze, requisiti operativi e profilo economico; soltanto dopo ha senso identificare la piattaforma più adatta.
C’è però un secondo errore, forse ancora più importante: sottovalutare la governance.
Costruire un ambiente ibrido senza un modello coerente di governance rischia semplicemente di moltiplicare la complessità. Non basta poter eseguire workload in ambienti differenti: bisogna poterli inventariare, proteggere, monitorare, aggiornare e governare attraverso principi coerenti.
È proprio qui che il concetto di hybrid cloud cambia profondamente rispetto al passato. Il valore non deriva soltanto dall’avere più luoghi nei quali eseguire un’applicazione, ma dalla possibilità di farlo senza moltiplicare proporzionalmente la complessità operativa.
In altre parole, la vera sfida dell’hybrid cloud non è la distribuzione dell’infrastruttura. È la capacità di governare quella distribuzione.
Dove entra Azure Local
In questo scenario, Azure Local rappresenta una delle risposte di Microsoft all’evoluzione dell’infrastruttura ibrida.
Non lo considero interessante semplicemente perché permette di eseguire virtual machine fuori da Azure. Quello è soltanto un punto di partenza. L’elemento più significativo è la possibilità di avvicinare capacità di elaborazione ad applicazioni e dati mantenendo un modello operativo sempre più coerente con quello utilizzato nel cloud.
È anche uno dei concetti che abbiamo voluto evidenziare in Azure Local Unleashed: Azure Local non dovrebbe essere interpretato semplicemente come un sostituto dell’infrastruttura esistente, ma come una componente di un modello distribuito nel quale il workload può essere collocato dove crea maggiore valore.
Questo non significa replicare Azure all’interno del proprio datacenter, né sostenere che cloud e on-premises diventeranno completamente equivalenti. Significa piuttosto ridurre quella discontinuità che storicamente caratterizzava il passaggio di un workload tra ambienti differenti, evitando di dover ricostruire ogni volta processi, strumenti e modelli di controllo.
È una distinzione importante: il valore non sta nell’avere “il cloud on-premises”, ma nel rendere più coerente il modo in cui ambienti diversi vengono gestiti.
Dal cloud-first al workload-first
Forse è arrivato il momento di superare alcune delle etichette che abbiamo utilizzato negli ultimi anni.
Il concetto di cloud-first ha avuto un ruolo importante: ha spinto molte organizzazioni a mettere in discussione modelli infrastrutturali consolidati, accelerando l’adozione di nuovi servizi e nuovi paradigmi operativi. Il livello successivo di maturità, però, potrebbe essere rappresentato da un approccio workload-first.
Significa non partire dalla piattaforma, dalla tecnologia che conosciamo meglio o dall’obiettivo di spostare qualcosa. Significa partire dall’applicazione, comprenderne esigenze, dipendenze, profilo economico, requisiti di sicurezza e vincoli operativi, e soltanto dopo decidere dove debba essere eseguita.
Per questo non credo che l’infrastruttura ibrida rappresenti una fase transitoria. Credo invece che stia diventando il risultato naturale di un IT nel quale le decisioni di placement possono essere prese in maniera più consapevole e riviste nel tempo, mentre governance e operations diventano progressivamente indipendenti dal luogo fisico nel quale risiede il workload.
Il concetto, alla fine, può essere sintetizzato in una frase:
The future of enterprise IT is not cloud versus on-premises, but intelligent workload placement.
Ed è proprio da questa considerazione che partirà il prossimo articolo della serie: come decidere, concretamente, se un workload dovrebbe essere eseguito in Azure, su Azure Local oppure su un’infrastruttura on-premises tradizionale?