La cloud migration è il processo attraverso il quale applicazioni, dati, server e servizi IT vengono trasferiti da un'infrastruttura locale verso un ambiente cloud. Non si tratta però di spostare semplicemente un server fisico o una macchina virtuale su una piattaforma esterna. Una migrazione corretta richiede un'analisi tecnica dell'infrastruttura esistente, delle dipendenze tra applicazioni e database, dei requisiti di sicurezza, delle prestazioni, della connettività e dei costi operativi. Prima di decidere cosa portare nel cloud è quindi necessario capire quali workload siano realmente adatti alla migrazione, quali debbano essere modificati e quali, invece, sia più conveniente mantenere on-premise.

Analizzare l'infrastruttura prima della migrazione

Il primo passaggio di una cloud migration consiste nell'effettuare un assessment dell'ambiente IT esistente. È necessario identificare server fisici e virtuali, sistemi operativi, applicazioni, database, servizi di rete, storage, backup, collegamenti tra sedi e dispositivi che dipendono dai sistemi che si intende trasferire. L'inventario deve essere sufficientemente dettagliato da permettere di ricostruire le relazioni tra i diversi componenti dell'infrastruttura.

Un'applicazione apparentemente indipendente potrebbe, ad esempio, utilizzare un database installato su un server differente, un servizio LDAP per l'autenticazione, una condivisione SMB per l'archiviazione dei documenti oppure un sistema SMTP per l'invio delle email. Spostare soltanto il server applicativo senza considerare queste dipendenze può generare malfunzionamenti, latenze elevate o interruzioni dei servizi. Per questo motivo il discovery iniziale deve comprendere anche le connessioni applicative e di rete, le porte utilizzate, i protocolli, le modalità di autenticazione e le dipendenze dai sistemi locali.

Capire quali workload sono adatti al cloud

Non tutti i workload devono essere necessariamente migrati. Un'applicazione web moderna, stateless e progettata per funzionare su infrastrutture virtualizzate può essere un candidato naturale per il cloud, mentre un'applicazione legacy fortemente legata a hardware specifico, licenze particolari o periferiche locali potrebbe richiedere una riprogettazione prima della migrazione.

La valutazione deve considerare anche il comportamento del workload. Un sistema con carico variabile può beneficiare dell'elasticità del cloud, aumentando o diminuendo le risorse in funzione delle necessità. Al contrario, un server che utilizza costantemente CPU, RAM e storage a livelli elevati potrebbe avere costi significativi se trasferito su un'infrastruttura cloud senza un'adeguata ottimizzazione.

Anche le applicazioni che sembrano semplici devono essere analizzate in relazione al loro ciclo di vita. Un software vicino alla dismissione potrebbe non giustificare il costo e la complessità di una migrazione. In questo caso può essere più conveniente mantenerlo temporaneamente nell'infrastruttura esistente e pianificare direttamente la sostituzione con una nuova soluzione.

Rehost, Replatform e Refactor

Una delle decisioni tecniche più importanti riguarda il livello di trasformazione da applicare al workload. Nel modello di rehost, spesso definito lift and shift, l'applicazione viene trasferita nel cloud con modifiche minime. Una macchina virtuale locale può, ad esempio, essere ricreata come istanza virtuale cloud mantenendo sostanzialmente la stessa architettura.

Il replatform introduce invece alcune modifiche per sfruttare meglio i servizi della piattaforma cloud senza riscrivere completamente l'applicazione. Un database installato su una macchina virtuale potrebbe essere sostituito con un servizio database gestito, riducendo le attività di manutenzione del sistema operativo e della componente infrastrutturale.

Il refactoring rappresenta un livello di trasformazione maggiore. L'applicazione viene modificata architetturalmente per sfruttare caratteristiche native del cloud, come autoscaling, servizi gestiti, container, code di messaggistica, storage distribuito o architetture a microservizi. Questa strategia può offrire vantaggi importanti in termini di scalabilità e resilienza, ma richiede maggiore investimento progettuale e tecnico.

Dipendenze applicative e architettura

La mappatura delle dipendenze è uno degli elementi più importanti nella valutazione di una migrazione. Un'applicazione non deve essere considerata come un componente isolato, ma come parte di un sistema composto da servizi interconnessi. Database, DNS, autenticazione, storage, API, firewall, sistemi di backup e servizi esterni possono influenzare direttamente il funzionamento dell'applicazione.

Una particolare attenzione deve essere dedicata alla latenza. Spostare nel cloud un application server mantenendo il database on-premise può essere una soluzione tecnicamente possibile, ma ogni query attraverserà il collegamento tra le due infrastrutture. Se l'applicazione effettua un numero elevato di chiamate al database, la latenza di rete può diventare un collo di bottiglia molto più importante della potenza computazionale del server.

Per questo motivo, prima della migrazione è necessario valutare la possibilità di mantenere vicini i componenti che comunicano frequentemente. In alcuni casi conviene spostare insieme application server e database, mentre in altri può essere preferibile mantenere temporaneamente un'architettura ibrida e ridurre progressivamente le dipendenze dall'infrastruttura locale.

Database e migrazione nel cloud

I database richiedono una valutazione particolarmente approfondita. La scelta non riguarda soltanto la possibilità di trasferire i dati, ma anche il modello di gestione del database dopo la migrazione. Un database può essere eseguito su una macchina virtuale come avviene nell'infrastruttura locale, oppure essere trasferito verso un servizio gestito che si occupa di aggiornamenti, backup, replica e parte delle attività amministrative.

Prima della migrazione è necessario analizzare dimensione del database, crescita prevista, numero di transazioni, IOPS, latenza, connessioni concorrenti, dimensione delle tabelle, indici, procedure, job schedulati e dipendenze applicative. Anche il metodo di trasferimento deve essere valutato in relazione alla quantità di dati e al downtime accettabile. Per database di grandi dimensioni può essere necessario utilizzare una replica continua o una strategia di sincronizzazione che permetta di ridurre la finestra di interruzione durante il cutover.

È inoltre importante verificare la compatibilità tra versioni del database e servizi disponibili nel cloud. Una migrazione può richiedere modifiche allo schema, alle query, ai driver utilizzati dall'applicazione o ai meccanismi di autenticazione.

Sicurezza durante la cloud migration

La sicurezza deve essere considerata già nella fase di progettazione e non dopo il trasferimento dei sistemi. Un ambiente cloud richiede la definizione di identità, ruoli, autorizzazioni, segmentazione di rete, firewall, cifratura, gestione delle chiavi, logging e monitoraggio. Il principio del least privilege deve essere applicato sia agli utenti sia alle applicazioni e ai servizi.

Durante la migrazione è inoltre necessario proteggere i dati in transito e verificare le modalità con cui vengono trasferiti. Le connessioni tra infrastruttura locale e cloud possono essere realizzate attraverso VPN site-to-site o collegamenti dedicati, in funzione dei requisiti di sicurezza, affidabilità e prestazioni.

Un errore frequente consiste nel trasferire nel cloud una macchina virtuale mantenendo configurazioni di sicurezza pensate per un ambiente locale senza adattarle al nuovo modello. La migrazione dovrebbe invece essere l'occasione per rivedere regole firewall, accessi amministrativi, esposizione dei servizi Internet, segmentazione delle reti e modalità di autenticazione.

Connettività tra azienda e cloud

La qualità della connessione Internet diventa un elemento infrastrutturale fondamentale quando parte dei sistemi aziendali viene spostata nel cloud. Non è sufficiente considerare la velocità nominale della linea, ma è necessario analizzare latenza, jitter, perdita di pacchetti, disponibilità del collegamento e capacità di gestire il traffico generato dagli utenti e dai sistemi.

In ambienti critici può essere necessario progettare collegamenti ridondati attraverso operatori differenti oppure utilizzare connessioni dedicate verso il provider cloud. La scelta dipende dal livello di disponibilità richiesto e dalla criticità dei workload.

Anche il DNS assume un ruolo importante. La risoluzione dei nomi deve funzionare correttamente tra sistemi on-premise e risorse cloud, soprattutto in presenza di applicazioni ibride. Un'architettura mal progettata può generare problemi apparentemente applicativi che sono invece causati da configurazioni DNS o di routing.

Valutare i costi reali

Uno degli errori più comuni nella cloud migration è confrontare semplicemente il costo di un server locale con il prezzo mensile di una macchina virtuale cloud. Il costo effettivo del cloud comprende molte altre componenti, tra cui storage, backup, traffico in uscita, database gestiti, indirizzi IP, servizi di sicurezza, monitoraggio, log, licenze e servizi aggiuntivi.

È quindi necessario costruire un modello di costo basato sul reale utilizzo delle risorse. Una macchina virtuale sovradimensionata può generare costi inutili, mentre una configurazione sottodimensionata può causare problemi di performance. Anche lo storage deve essere scelto in funzione delle caratteristiche del workload, considerando capacità, IOPS, throughput e frequenza di accesso ai dati.

L'analisi economica dovrebbe inoltre considerare il TCO, cioè il Total Cost of Ownership. Nel confronto devono rientrare non soltanto i costi infrastrutturali, ma anche manutenzione hardware, energia elettrica, climatizzazione, spazio nel data center, rinnovo dei server, licenze, personale tecnico e gestione dell'infrastruttura. Solo attraverso questo confronto è possibile capire se il cloud rappresenta realmente un vantaggio economico.

Alta disponibilità, backup e disaster recovery

Portare un sistema nel cloud non significa automaticamente renderlo altamente disponibile. La disponibilità dipende dall'architettura utilizzata. Una singola macchina virtuale può continuare a rappresentare un single point of failure anche se viene eseguita in un data center cloud.

Per workload critici è quindi necessario valutare ridondanza delle istanze, distribuzione su zone differenti, bilanciamento del traffico, replica dei database e procedure di failover. Allo stesso modo, il backup deve essere progettato separatamente dalla semplice disponibilità dell'infrastruttura. Una replica non sostituisce necessariamente un backup e uno snapshot non deve essere considerato automaticamente una strategia completa di protezione dei dati.

La progettazione deve partire da RTO e RPO. Il Recovery Time Objective definisce quanto tempo può trascorrere prima del ripristino del servizio, mentre il Recovery Point Objective determina la quantità massima di dati che l'azienda è disposta a perdere. Questi parametri influenzano direttamente architettura, replica, backup e costi.

Monitoraggio dopo la migrazione

Una cloud migration non termina quando il server viene avviato nel nuovo ambiente. Dopo il cutover è necessario monitorare il comportamento dell'applicazione e dell'infrastruttura per verificare che prestazioni, disponibilità e consumi siano conformi alle aspettative.

CPU e RAM rappresentano soltanto una parte delle informazioni necessarie. È importante analizzare latenza applicativa, tempi di risposta, IOPS, throughput dello storage, errori HTTP, connessioni al database, utilizzo della rete e metriche specifiche dell'applicazione. Anche i log devono essere centralizzati e analizzati per individuare errori che potrebbero non essere immediatamente visibili all'utente.

Il monitoraggio è inoltre fondamentale per l'ottimizzazione dei costi. Un workload che utilizza costantemente una frazione delle risorse assegnate può essere ridimensionato, mentre un sistema sottodimensionato può richiedere un aumento delle risorse. Il cloud permette una maggiore elasticità, ma questa deve essere governata attraverso monitoraggio e automazione.

Quando mantenere un sistema on-premise

La cloud migration non deve essere considerata obbligatoria per ogni componente dell'infrastruttura. Esistono situazioni in cui mantenere un workload on-premise può essere tecnicamente ed economicamente più conveniente. Questo può avvenire quando sono presenti vincoli normativi, applicazioni legacy difficili da modificare, periferiche locali, requisiti di latenza molto bassi oppure costi cloud particolarmente elevati rispetto a un'infrastruttura già ammortizzata.

Un'architettura ibrida può quindi rappresentare una soluzione efficace. Alcuni servizi possono essere eseguiti localmente mentre altri vengono trasferiti nel cloud, mantenendo collegamenti sicuri tra i due ambienti. L'obiettivo non deve essere spostare tutto nel cloud, ma costruire l'architettura più adatta alle caratteristiche tecniche e operative dell'azienda.

Pianificare una cloud migration

Una migrazione efficace deve essere realizzata attraverso fasi controllate. Dopo l'assessment iniziale è necessario classificare i workload in base a criticità, dipendenze, complessità, costi e possibilità di migrazione. I sistemi meno critici possono essere utilizzati come primi workload di test, consentendo al team IT di verificare connettività, sicurezza, procedure operative e strumenti di monitoraggio prima di intervenire sui sistemi più importanti.

La fase di cutover deve essere pianificata con attenzione e deve prevedere procedure di rollback. Se dopo la migrazione si verifica un problema grave, deve essere possibile tornare rapidamente alla situazione precedente o attivare un ambiente alternativo. Per questo motivo backup, replica e test di ripristino devono essere verificati prima dell'esecuzione della migrazione.

La cloud migration deve quindi essere considerata come un progetto di trasformazione dell'infrastruttura IT e non come una semplice operazione di trasferimento dei server. Valutare correttamente cosa portare nel cloud significa analizzare applicazioni, database, dipendenze, rete, sicurezza, prestazioni, costi, disponibilità e modalità operative. Una progettazione accurata permette di sfruttare realmente i vantaggi del cloud evitando di trasferire semplicemente nel nuovo ambiente le inefficienze e i vincoli dell'infrastruttura precedente.