Da qualche anno ormai mi occupo di migrazioni verso Azure e, facendo tesoro delle mie esperienze, mi sono ritrovato a stilare un vademecum per cercare di affrontare con serenità e tranquillità la migrazione dei data center nel cloud targato Microsoft.
In questo e nei prossimi articoli, vorrei quindi condividere con voi alcune indicazioni su come affrontare un “Lift and Shift” su Azure con zen, cercando di mettere l’accento su alcuni aspetti che, durante questo tipo di processo, a volte causano qualche mal di testa di troppo.
Di solito tutto inizia con una forte decisione dall’alto o esterna a noi: ad esempio il CEO che afferma “Dobbiamo andare in cloud altrimenti non riusciamo ad essere competitivi“; oppure “Abbiamo in scadenza il contratto con il nostro hoster. Perchè comprare nuovo hardware e licenze? Andiamo in cloud!“.
Ditemi chi non si è trovato in questa situazione: dal CTO, al System Administrator, al consulente IT. E quasi sempre si hanno solo 2 o 3 mesi per poter completare tutta l’operazione.
La prima reazione è sempre il panico. Tralasciando la preoccupazione di perdere il proprio lavoro, solitamente ci si ritrova a sostenere questa pressione e urgenza andando ad affrontare l’intero processo con l’ansia da prestazione e con la mentalità di voler replicare in cloud la propria infrastruttura on-premises: stessi strumenti di sicurezza, di controllo e di gestione.
Se vi riconoscete in tutto questo, continuate a leggere e vedrete che ritroverete la pace dei sensi per affrontare una migrazione Lift and Shift su Azure, non dico tranquilla, ma per lo meno consapevole.
Cominciamo!
I cinque step imprescindibili del lift&shift
Anche il Lift and Shift su Azure, per essere affrontato al meglio, richiede di eseguire 5 step, in ordine.
Ogni passo ovviamente richiede tempo. Ma ricordatevi che “in cloud” più tempo si impiega ad analizzare, escogitare il design migliore, scegliere il modello più efficiente e meno tempo si impiegherà nell’esecuzione della migrazione e migliore sarà l’esperienza di governance.
Il mio consiglio è di prendervi tutto il tempo necessario (e anche di più) per ogni step descritto in questo e nei prossimi articoli di questa serie.
Step 1 – assessment
Analisi del data center on-premises e di tutti i sevizi erogati
L’analisi dell’as-is è fondamentale per capire eventuali blocker ed individuare i migliori workaround. L’idea guida è quella di suddividere l’attuale data center on-premises in quello che in SoftJam chiamiamo “Isole Applicative”, aggregando server e virtual machine che compongono i tier per ogni singola applicazione.
L’obbiettivo di tale analisi deve coprire i seguenti aspetti:
- Dimensionamento servizi
- Requisiti di sicurezza
- Requisiti di resilienza
- Consumi mensili
Fortunatamente, ad aiutarci in tutto questo abbiamo la possibilità di utilizzare uno strumento che sta diventando sempre più potente: Azure Migrate.
Assessment con Azure Migrate
Azure Migrate permette la creazione di un project di migrazione che colleziona le caratteristiche delle virtual machine (VM) on-premises tramite un’appliance virtuale da distribuire nel nostro data center.
Oltre alle VM, è possibile analizzare le basi dati – SQL Server, MySQL, Oracle, ecc. – offrendo un’analisi simile a quella fornita per le macchine virtuali. Inoltre, Azure Migrate analizza i workload di archiviazione file, come file server o archivi di file, e fornisce lo strumento più idoneo da usare per migrarli in Azure.
Dallo stesso portale, infine, è possibile migrare Web application non troppo complesse, solitamente i frontend web IIS e Apache senza nGINX, verso gli App Service di Azure.
Ecco come si presenta l’elenco delle VM analizzate, non ancora aggregate in Group, prima di eseguire l’Assessment che analizzerà effettivamente i dati collezionati dal vCenter o da Hyper-V.
IMPORTANTE – Per avere dati di performance attendibili per la parte storage e networking, nel caso di infrastruttura VMware, impostare i log del vCenter a livello 3.
Azure Migrate permette anche di: visualizzare, globalmente o per ogni Isola Applicativa, non solo i dimensionamenti in Azure delle VM analizzate, ma anche le stime dei consumi che queste risorse avranno; e verificare la matrice di compatibilità di questi workload in cloud.
I dati visualizzati sono influenzati dai parametri di assessment prescelti. I principali sono:
- uso o meno di Reserved Instance;
- se il dimensionamento è condizionato dalle prestazioni rilevate oppure dal dimensionamento on-premise;
- dal tipo di contratto con cui si acquisiscono le risorse Azure;
- durata del periodo osservato e valore percentile considerato.
Al variare di questi parametri, oltre ai consumi stimati, varieranno anche le caratteristiche delle VM in cloud.
Nonostante tutta questa potenza, Azure Migrate non può essere considerato attendibile al 100%. Infatti, lo strumento non riconosce evetuali infrastrutture clusterizzate e non valuta le licenze d’uso dei workload analizzati. Inoltre, non esegue valutazione dei picchi di utilizzo o se le VM analizzate siano più CPU intensive, RAM intensive, Storage intensive o un mix di tutto.
In tutto questo, la figura dell’Architect è fondamentale per evitare errori come l’utilizzo in ambienti di produzione, ad esempio, delle virtual machine serie A o per dimensionare i dischi esattamente quanto lo spazio occupato on-premises.
Il mio consiglio è: usate Azure Migrate per stimare quali workload sono cloud-ready e l’ordine di grandezza dei consumi ipotizzati. Ai risultati, poi, applicate tutte le best practice che gli Azure Cloud Design Pattern riportano. Ma di questo parleremo nei prossimi articoli.
→ Vai alla seconda parte di “Come affrontare il Lift&Shift su Azure con Zen” dedicata alla scelta dei modelli di servizio che possiamo utilizzare in cloud mentre migriamo le nostre isole applicative in Azure.
→ Vai alla terza parte della serie per approfondire gli step di Design, Migration e Governance relativi al processo di migrazione Lift&Shift sul cloud Microsoft.
