Un esempio di migrazione dei workload da on-premises a Cloud usando AWS Migration Service

Quando si migra un workload su Cloud da on-premise, l’applicazione deve essere sempre almeno re-platformed e, meglio ancora, re-factored, per iniziare ad ottenere benefici dal nuovo ambiente nel Cloud.

Pur sapendo che il Re-host è un’opzione più vantaggiosa in termini di costi, il Re-factor porta ad un ROI molto più velocemente, senza menzionare il beneficio del Technical Debt (debito tecnico) di cui parleremo in un altro post dedicato.

Anche se ci sono altri punti da prendere in considerazione per decidere il giusto approccio di migrazione, questa valutazione per ogni applicazione, insieme al Business Case, ci porterà a scegliere uno dei percorsi elencati di seguito (7 Rs):

1. Rehost: possiamo semplicemente replicare il carico di lavoro - (es. Oracle DB su EC2)
2. Replatform: possiamo fare piccole modifiche per migrare (es: aggiornare la versione del sistema operativo o il database su RDS)
3. Repurchase: tipico scenario di drop and shop come selezionare un software SaaS o "off-the-shelf" per sostituire il workload
4. Refactor: Riscrivere e riprogettare l'applicazione - qui si comincia a pagare il debito tecnico! (es. migrare Oracle DB a AWS RDS su PostgreSQL)
5. Retire: smantellare il software perché non è più necessario
6. Retain: tenere nel luogo di origine per rivederlo in futuro
7. Relocate: lift and shift a livello di hypervisor (VMware on AWS)

Per esempio, un cliente ci ha chiesto una consulenza per la migrazione del suo sistema assicurativo interno dal suo attuale fornitore di hosting ad AWS.

Dopo un inventario di tutti i server, le applicazioni e l'infrastruttura satellite, si è scoperto che era necessaria una notevole quantità di re-architecturing e re-platform.

Alcuni server erano versioni di Oracle Linux e Windows obsolete e un'applicazione legacy scritta in un framework sconosciuto, dove abbiamo realizzato che c'era una quantità significativa di debito tecnico da risolvere, ma non c'era il tempo per pensare all'approccio Refactor.

Il progetto in sé non era così difficile, i requisiti erano chiari e l'infrastruttura finale sarebbe stata essenzialmente server EC2 e 2 database AWS RDS Oracle. Il cliente ha deciso di non portare nessuna applicazione nei container a causa della mancanza di skills del suo team.

L'attenzione principale era sul tempo di cutover. Quindi la strategia di migrazione è stata progettata per garantire la minima interruzione durante lo switchover. Avevamo a disposizione 30 giorni di calendario per preparare, sincronizzare, testare il tempo di cutover ed essere pronti per il giorno del cutover.

La legge di Murphy è entrata in gioco

Durante la fase di migrazione scopriamo alcuni aspetti tecnologici erogati in modalità condivisa dal vecchio provider che non sono stati mappati in fase di valutazione, come ad esempio:

• Il server FTP centrale del vecchio provider serve alcuni file al sistema BI;
• Configurazioni specifiche sul Load Balancer (sempre condiviso) che non è stato mappato perché nessuno ne era a conoscenza;
• Un server NFS comune usato come integrazione tra il vecchio servizio di provider e le applicazioni client;

Naturalmente, abbiamo potuto identificare tutti questi punti nella fase di test di AWS Application Migration Service (vecchio CloudEndure e in fase di migrazione verso AWS Application Migration Service). Rapidamente quindi definiamo in maniera più dettagliata la nostra Landing Zone con:

• AWS FTP Service: decidiamo di mantenere FTP e non usare SFTP perché il tempo per migliorare l'applicazione non corrisponderebbe alla nostra Timeline di progetto
• ALB: abbiamo preferito ALB perché alcune regole usano le Sticky Session, altre regole bilanciano per URL (path-based) e stiamo pensando di avere la possibilità di usare Lambda come obiettivo nel caso in cui trovassimo altre sorprese durante i test;
• EFS: abbiamo deciso di usare EFS a causa della sua resilienza, ma stiamo pensando di cambiare l'applicazione per rimuovere questa dipendenza.

Questo servizio di migrazione delle applicazioni è impressionante perché potremmo sincronizzare i dati tra i DataCenter del fornitore e AWS e fare quante Dry-Reharsal del Cutover vogliamo, fino a raggiungere il tempo di inattività previsto che è stato dato dal cliente. Non solo, nel progetto il Refactoring richiederebbe più tempo del tempo previsto per migrare e questo porterebbe ad una soluzione robusta, affidabile e lascierebbe il cliente fiducioso di fare il primo movimento al cloud.

Flusso di lavoro (di alto livello) di AWS per questo servizio

Qui il nostro flusso di lavoro per questo servizio

Avvertenze

1. Alcuni sistemi operativi per alcuni server giravano su Oracle Linux 4 e non erano supportati da questo servizio, quindi in questi pochi casi abbiamo migrato usando "rsync" ad un server in una versione più recente del sistema operativo. Fortunatamente l'applicazione è basata su Apache Tomcat ed è stato facile adeguare le librerie.
2. La maggior parte dei server che migriamo era su EC2 famiglia c5, ad eccezione di un sistema di BI in esecuzione su Windows che ci ha richiesto l’utilizzo della famiglia m4.
3. La strategia adottata per Oracle 19c è stata un Data-Pump diretto tra sorgente e destinazione, dato che il DB non era grande (circa 100GB senza compressione e 20GB compressi) e abbiamo fatto la migrazione in un paio d'ore e portato i dati su AWS RDS per Oracle.
4. Il nostro piano di cutover era di 6 ore di interruzione, e tutto è andato bene tranne che, quando abbiamo finito l'ultima sincronizzazione, il servizio di origine ha iniziato il backup giornaliero che ci ha rallentato un po', ma abbiamo potuto iniziare la convalida della destinazione dopo 4 ore di interruzione.

Considerazioni finali

Con questo tipo di progetti, spesso ci troviamo ad affrontare situazioni inaspettate …ma è normale: usando gli strumenti e l'approccio giusto, "fix the plane in the air" è easy. Anche i cambiamenti dei requisiti e le richieste di aggiunta di funzionalità sono molto comuni. Avere una buona Landing Zone con una buona strategia per connettere i servizi sul cloud ci aiuterà sempre nell’architettare al meglio i cambiamenti..

Questa migrazione è stata solo il primo passo, dal momento che abbiamo già iniziato alcuni refactoring per applicazioni specifiche utilizzando ECS.

Andre Marzulo

Cloud enthusiast, AppModernization and DevOps consultant, AWS SA Professional Certified

email: andre.marzulo@softwareone.com