Nel primo articolo di questa serie siamo partiti da un principio: il futuro dell’IT enterprise non sarà definito dalla contrapposizione tra cloud e on-premises, ma dalla capacità di collocare ogni workload dove può generare il maggior valore.
Da questa affermazione nasce però una domanda inevitabile: come si decide concretamente dove eseguire un workload?
Azure, Azure Local e un’infrastruttura on-premises tradizionale possono essere tutte scelte valide. Il problema nasce quando la decisione viene affrontata partendo direttamente dalla piattaforma, senza avere prima definito il modello complessivo nel quale quelle piattaforme dovranno convivere.
Il workload placement, infatti, non è semplicemente una sequenza di decisioni indipendenti prese applicazione per applicazione. Prima viene la strategia. Poi viene il workload.
Il principio da cui partirei è quindi questo:
Workload placement starts with understanding the application, but within a clearly defined operating model.
Prima il modello operativo, poi il workload
Quando un’organizzazione affronta un percorso di modernizzazione infrastrutturale, la prima decisione raramente riguarda una singola applicazione. Normalmente il confronto parte da un livello superiore: quale modello infrastrutturale e operativo vogliamo adottare?
La risposta può essere prevalentemente cloud, fortemente orientata all’infrastruttura locale oppure, come accade sempre più frequentemente, ibrida.
Questa scelta definisce il perimetro entro cui verranno successivamente valutati i singoli workload, ma non dovrebbe determinarne automaticamente la destinazione.
Adottare un modello ibrido, ad esempio, non significa decidere a priori che una certa percentuale delle applicazioni debba essere eseguita nel public cloud e la restante parte on-premises. Significa costruire un’architettura e un operating model capaci di utilizzare ambienti differenti in maniera coerente, lasciando poi che siano le caratteristiche dei singoli workload a determinare il placement più appropriato.
È a questo punto che si entra realmente nel merito dell’applicazione.
Chi la utilizza? Da quali sedi? Con quali altri sistemi comunica? Quanto è sensibile alla latenza? Cosa accade se la connettività verso il cloud viene interrotta? Quali dati tratta? Qual è il suo profilo di crescita? Quanto è critica per il business? Qual è il suo lifecycle?
Il placement nasce quindi dall’incontro tra una strategia infrastrutturale trasversale e le caratteristiche specifiche del workload.
La strategia definisce il modello entro il quale operare. Il workload determina dove, all’interno di quel modello, abbia più senso essere eseguito.
Questa distinzione permette anche di evitare due errori opposti: costruire l’intera strategia intorno a una singola piattaforma oppure trattare ogni applicazione come un caso completamente indipendente, perdendo coerenza a livello di governance, sicurezza e operations.
Non esiste un singolo criterio di placement
Una volta definito il modello complessivo, il singolo workload deve essere valutato attraverso più dimensioni.
La prima è la latenza. Alcune applicazioni possono tollerare decine o centinaia di millisecondi senza conseguenze significative. Altre no. Un sistema amministrativo ha esigenze completamente differenti da un’applicazione MES che interagisce direttamente con una linea produttiva o da una piattaforma di video analytics che deve elaborare immagini in tempo reale.
Direttamente collegata alla latenza c’è la prossimità. Applicazioni e dati possono dipendere da macchinari, sensori, sistemi di fabbrica, utenti o altri servizi che rimangono fisicamente in una determinata sede.
Poi ci sono le dipendenze applicative. Una macchina virtuale raramente vive da sola: comunica con database, file share, middleware, directory, sistemi legacy, dispositivi industriali e servizi esterni. Migrare un singolo componente senza comprendere questa rete di relazioni può semplicemente spostare il problema anziché risolverlo.
Un’altra dimensione fondamentale è la connettività. Non basta domandarsi se una sede sia collegata a Internet. Bisogna chiedersi che cosa accade al processo di business quando quella connettività si degrada o viene interrotta.
Poi ci sono data sovereignty e compliance. In alcuni scenari rappresentano uno dei fattori della decisione; in altri diventano un vincolo architetturale vero e proprio, capace di escludere direttamente alcune alternative.
Infine, il profilo economico. Un workload stabile e prevedibile presenta caratteristiche completamente differenti rispetto a uno che richiede capacità estremamente variabile. Anche qui, la piattaforma più conveniente non può essere determinata senza comprendere prima il comportamento dell’applicazione.
Workload placement significa quindi bilanciare simultaneamente latenza, prossimità, dipendenze, connettività, sovereignty, compliance, economics, resilienza, scalabilità e lifecycle.
Difficilmente una di queste dimensioni, presa singolarmente, fornisce la risposta. È solitamente la loro combinazione a far emergere il placement corretto.
Quando Azure è la scelta naturale
Il public cloud esprime probabilmente il proprio valore massimo quando l’obiettivo non è semplicemente trasferire un’infrastruttura esistente, ma sfruttare capacità che sarebbe difficile replicare localmente con gli stessi tempi e la stessa semplicità.
Penso, ad esempio, allo sviluppo di nuove applicazioni cloud-native, all’utilizzo di servizi PaaS, alle piattaforme dati e, sempre più frequentemente, ai servizi legati all’intelligenza artificiale.
In questi scenari, il valore di Azure non deriva soltanto dalla disponibilità di capacità computazionale. Deriva soprattutto dall’accesso immediato a un ecosistema di servizi che può accelerare significativamente il percorso di innovazione.
Anche il global reach può diventare determinante. Un’applicazione destinata a utenti distribuiti geograficamente può beneficiare di un’infrastruttura globale in un modo difficilmente comparabile con ciò che sarebbe ragionevole costruire e mantenere in proprio.
C’è poi l’elasticità. Se un workload è caratterizzato da una domanda fortemente variabile, dimensionare un’infrastruttura locale per il picco significa acquistare capacità che per buona parte del tempo potrebbe rimanere inutilizzata. Nel public cloud la capacità può invece seguire più naturalmente l’andamento della domanda.
Questo non significa che Azure sia automaticamente la destinazione corretta per ogni nuova applicazione. Significa che, quando elasticità, velocità di innovazione, disponibilità di servizi gestiti e distribuzione geografica rappresentano i driver principali, il public cloud parte spesso con un vantaggio significativo.
Quando Azure Local diventa particolarmente interessante
Esistono poi workload che devono rimanere vicini al luogo nel quale vengono utilizzati o nel quale viene generato il dato.
È qui che Azure Local introduce un’opzione particolarmente interessante: mantenere l’esecuzione localmente, senza rinunciare necessariamente a un operating model coerente con la strategia Azure dell’organizzazione.
Il caso più evidente è quello della latenza.
Pensiamo all’analisi video in tempo reale tramite AI oppure ai sistemi che controllano direttamente una linea produttiva. Il dato nasce nello stabilimento e spesso deve essere elaborato nello stesso luogo. Aumentare la banda disponibile verso il cloud non elimina la distanza fisica e quindi non risolve il problema della latenza.
Un secondo elemento è la continuità operativa. Se l’interruzione della connettività verso il cloud può fermare un processo produttivo o un servizio critico, mantenere localmente l’esecuzione può diventare un requisito architetturale.
Azure Local diventa inoltre interessante quando l’organizzazione ha scelto un modello ibrido e vuole ridurre la distanza operativa tra ciò che viene eseguito nel datacenter e ciò che risiede nel public cloud. Virtual machine e workload containerizzati possono rimanere localmente, mentre governance, policy, sicurezza e lifecycle possono essere inseriti in un modello più coerente e trasversale.
Questo è un punto importante: Azure Local non rappresenta semplicemente una soluzione intermedia tra Azure e l’on-premises tradizionale.
Ha senso quando l’esecuzione locale è necessaria o conveniente e, contemporaneamente, esiste valore nell’adottare un operating model integrato con Azure.
Se manca uno di questi due elementi, la scelta deve essere valutata con attenzione.
Quando l’on-premises tradizionale continua ad avere senso
Ragionare per workload significa anche accettare che Azure Local non sia automaticamente la scelta migliore ogni volta che un’applicazione deve rimanere localmente.
Se un’organizzazione non vede un reale valore in un modello ibrido, non prevede workload significativi nel public cloud e non ha necessità di adottare un operating model integrato con Azure, una piattaforma tradizionale può continuare a essere una scelta perfettamente razionale.
Lo stesso vale per determinati workload legacy o per applicazioni fortemente condizionate da requisiti di supporto dei vendor.
Il punto non è utilizzare la tecnologia più recente.
È utilizzare quella che risponde meglio al problema e si inserisce correttamente nella strategia complessiva.
In presenza di workload stabili, requisiti tradizionali e un modello operativo consolidato, introdurre una nuova piattaforma senza un beneficio concreto rischia semplicemente di aggiungere complessità.
La modernizzazione deve sempre avere un obiettivo. Se l’integrazione cloud non produce valore, non dovrebbe essere adottata per principio.
Tre workload, tre decisioni differenti
Un modo efficace per comprendere quanto il placement dipenda dal contesto è osservare tre situazioni differenti.
Quando Azure evita di cristallizzare il datacenter
Una società di servizi con circa 550 dipendenti gestiva un centinaio di virtual machine su un cluster a tre nodi. L’hardware sarebbe uscito dal supporto entro pochi mesi.
La decisione avrebbe potuto sembrare semplice: acquistare un nuovo cluster.
Analizzando però il contesto applicativo emergevano due elementi importanti. Il primo era un picco stagionale di domanda pari a circa cinque volte il carico ordinario per alcune settimane all’anno. Il secondo era che l’organizzazione aveva già pianificato il passaggio del proprio gestionale a un modello SaaS entro circa due anni, con la conseguente eliminazione di una parte significativa delle VM esistenti.
Dimensionare una nuova infrastruttura locale per cinque anni avrebbe quindi significato acquistare capacità necessaria soltanto per un breve picco e destinata, nel tempo, a rimanere inutilizzata.
La scelta è stata Azure.
In questo caso il public cloud ha permesso alla capacità di seguire l’evoluzione del workload: assorbire il picco quando necessario e ridursi progressivamente man mano che le applicazioni venivano dismesse o trasformate.
Quando il workload richiede l’esecuzione locale
Un’azienda manifatturiera opera attraverso più stabilimenti e utilizza sistemi MES e di supervisione direttamente collegati alle linee produttive.
Il requisito principale era estremamente chiaro: il ciclo di controllo richiedeva latenze incompatibili con l’esecuzione del workload nel public cloud. A questo si aggiungevano precedenti interruzioni della connettività WAN che rendevano necessario garantire la continuità operativa anche in assenza del collegamento verso Azure.
In questo scenario il public cloud non era semplicemente meno conveniente. Non rispondeva al requisito.
La scelta è stata Azure Local negli stabilimenti.
I workload sensibili alla latenza rimangono così vicini alle linee produttive e possono continuare a operare localmente. Allo stesso tempo, invece di creare piattaforme completamente indipendenti con processi differenti di gestione, aggiornamento e sicurezza, l’infrastruttura viene inserita nel modello operativo ibrido definito dall’organizzazione.
Gli altri workload, non soggetti agli stessi vincoli, possono invece essere eseguiti direttamente in Azure.
Questo è probabilmente uno degli esempi più chiari di workload placement: non scegliere una piattaforma per l’intera azienda, ma utilizzare piattaforme differenti all’interno dello stesso operating model.
Quando la scelta migliore è non forzare la migrazione
Un’azienda logistica con circa 420 dipendenti utilizza una settantina di VM, tra ERP, file server, sistemi di magazzino e applicazioni verticali. Anche qui l’hardware si stava avvicinando alla fine del supporto.
Il vero vincolo, però, non era infrastrutturale. Era applicativo.
Il vendor dell’ERP non supportava su Azure la versione utilizzata dal cliente. Per arrivarci sarebbe stato necessario effettuare un major upgrade con revisione delle personalizzazioni, ricostruzione delle integrazioni e formazione degli utenti.
Il progetto applicativo era già pianificato, ma non nell’immediato.
Forzare la migrazione avrebbe significato affrontare contemporaneamente il cambio infrastrutturale e il major upgrade dell’applicazione, concentrando due rischi differenti sul sistema che sosteneva uno dei processi aziendali più critici.
La decisione è stata quindi molto più pragmatica: refresh contenuto dell’infrastruttura on-premises, miglioramento della protezione del dato, disaster recovery in Azure e introduzione di strumenti di gestione coerenti con il percorso futuro.
La piattaforma verrà rivalutata dopo l’upgrade dell’ERP.
Il lifecycle dell’infrastruttura e quello delle applicazioni non sempre coincidono. Cercare di forzarli nella stessa finestra temporale può generare un rischio superiore al beneficio.
Il costo va misurato, non presunto
Il fattore economico merita sempre un’analisi specifica.
Troppo spesso si parte da una delle due convinzioni opposte: “il cloud costa meno” oppure “il cloud costa di più”.
Entrambe sono semplificazioni.
Un workload stabile e prevedibile ha un profilo economico molto diverso da uno caratterizzato da forti oscillazioni. Un’infrastruttura locale sovradimensionata può avere costi nascosti esattamente come un ambiente cloud lasciato crescere senza governance.
Personalmente preferisco ragionare almeno su un TCO a tre anni, includendo infrastruttura e licensing e, quando i dati lo consentono, anche le principali componenti operative.
L’obiettivo non è determinare quale piattaforma costi meno in assoluto, ma capire quale modello economico sia più coerente con il comportamento del workload nel periodo analizzato.
Anche il costo, quindi, non è una proprietà della piattaforma. È il risultato dell’incontro tra piattaforma e workload.
Un framework a due livelli
Alla fine, il processo decisionale può essere ricondotto a due livelli distinti.
Livello 1 – Definire l’operating model
Prima di discutere il placement delle singole applicazioni, l’organizzazione dovrebbe chiarire alcuni principi trasversali:
quale ruolo devono avere public cloud e infrastrutture locali;
quale modello di governance adottare;
come gestire identity e security;
quali strumenti utilizzare per monitoring e observability;
quale livello di automazione perseguire;
come gestire lifecycle e compliance;
quale dipendenza dalla connettività cloud sia accettabile.
Questo livello definisce le regole del gioco.
Livello 2 – Valutare ogni workload
All’interno di quel modello, ogni workload dovrebbe essere analizzato almeno attraverso queste dimensioni:
Dimensione
Domanda da porsi
Latency
Quanto è sensibile l’applicazione alla distanza dai sistemi con cui comunica?
Proximity
Deve rimanere vicina a utenti, macchinari, dati o processi fisici?
Connectivity
Cosa accade se il collegamento verso il cloud viene degradato o interrotto?
Sovereignty / Compliance
Esistono vincoli sulla posizione, sul controllo o sul trattamento del dato?
Economics
La domanda è stabile, variabile o caratterizzata da picchi significativi?
Scalability
Quanto rapidamente può cambiare il fabbisogno di capacità?
Lifecycle
I tempi dell’applicazione coincidono con quelli dell’infrastruttura?
Dependencies
Quali componenti devono muoversi insieme perché il placement abbia realmente senso?
Il risultato non dovrebbe essere una classifica universale tra Azure, Azure Local e on-premises.
Dovrebbe essere una scelta coerente con il modello complessivo e con le caratteristiche del workload.
Il placement può cambiare, ma non è automaticamente reversibile
Nel primo articolo abbiamo evidenziato come il workload placement sia oggi meno definitivo rispetto al passato.
Il concetto rimane valido, ma deve essere utilizzato con prudenza.
Non tutti i workload possono essere spostati liberamente da un ambiente all’altro. Architettura applicativa, servizi utilizzati, dipendenze, networking e quantità di dati possono rendere una migrazione estremamente complessa.
La reversibilità non dovrebbe quindi essere presentata come una proprietà automatica dell’hybrid cloud.
Dovrebbe piuttosto diventare un principio architetturale: evitare, quando possibile, decisioni che eliminino inutilmente le opzioni future.
Non significa poter spostare tutto in qualsiasi momento. Significa progettare oggi cercando di non rendere impossibile il cambiamento di domani.
Technology is not the destination
Il workload placement non è una competizione tra Azure, Azure Local e l’infrastruttura tradizionale.
Non esiste una piattaforma vincente in assoluto, perché non esiste un workload universale.
Ma non esiste nemmeno una strategia infrastrutturale costruita semplicemente sommando una serie di decisioni indipendenti applicazione per applicazione.
Serve prima un modello.
Un modello capace di stabilire come cloud e infrastruttura locale debbano convivere, come le risorse debbano essere governate, protette e monitorate e quali principi debbano rimanere coerenti indipendentemente dal luogo di esecuzione.
All’interno di quel modello, ogni workload può poi trovare la propria posizione.
Un’applicazione cloud-native con forte bisogno di elasticità può trovare in Azure il proprio ambiente naturale. Un sistema industriale sensibile alla latenza può richiedere l’esecuzione locale e beneficiare del modello operativo di Azure Local. Un’applicazione legacy con vincoli di supporto può rendere perfettamente razionale mantenere temporaneamente un’infrastruttura tradizionale.
La qualità della decisione dipende dalla capacità di collegare strategia e caratteristiche del workload, senza sacrificare l’una all’altra.
Modernizzare non significa adottare più tecnologia o spostare tutto nel cloud. Significa costruire un operating model coerente, comprendere ciò che conta per ogni applicazione e collocare workload, dati e capability dove possono generare il maggior valore oggi, preservando allo stesso tempo la capacità di evolvere domani.
