{"id":3370,"date":"2021-07-23T13:59:00","date_gmt":"2021-07-23T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3370"},"modified":"2021-07-22T15:59:03","modified_gmt":"2021-07-22T13:59:03","slug":"migrazione-ninja-dallon-premise-al-cloud-con-cloudendure","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/migrazione-ninja-dallon-premise-al-cloud-con-cloudendure\/","title":{"rendered":"Migrazione Ninja dall’on-premise al Cloud con CloudEndure"},"content":{"rendered":"\n
\u201cLife is what happens to you while you’re busy making other plans\u201d<\/p><\/blockquote>\n\n\n\n
scrisse John Lennon in \u201cBeautiful Boy\u201d. <\/p>\n\n\n\n
In questo articolo vedremo che, a volte, anche se sono stati fatti piani accurati e dettagliati gli imprevisti sono sempre dietro l\u2019angolo e spesso ci obbligano a cambiare rapidamente la nostra strategia. Quando si intraprendono percorsi di migrazione sul Cloud<\/strong> e application modernization<\/strong> uno dei nostri mantra recita che \u00e8 sempre necessario procedere con attivit\u00e0 di refactoring o re-architecting delle applicazioni per poter trarre i massimi benefici dall\u2019utilizzo del cloud. A volte, per\u00f2, fattori esterni possono rimescolare le carte in tavola e costringerci a cambiare in modo drastico le nostre decisioni, facendoci cambiare del tutto la strada verso il nostro obiettivo.<\/p>\n\n\n\n
Alcuni mesi fa un cliente ha chiesto il nostro aiuto per un progetto di migrazione dal provider corrente ad AWS di alcuni siti e-commerce. Come di consueto, abbiamo cominciato stilando un piano seguendo la regola delle \u201c7R\u201d<\/a><\/strong>.<\/p>\n\n\n\n
Dopo aver inventariato tutti i sistemi \u00e8 emersa la necessit\u00e0 di procedere con azioni sostanziali di refactoring<\/strong> e re-architecting<\/strong>, mentre nessun sistema doveva essere rinnovato, mantenuto, rilocato o ritirato. Inizialmente l\u2019opzione del rehosting non \u00e8 stata nemmeno presa in considerazione perch\u00e9 il cliente era desideroso di cambiare il paradigma infrastrutturale attualmente in uso, traendo vantaggio dall\u2019utilizzo del Cloud e dalle sue caratteristiche, specialmente per elasticit\u00e0, ottimizzazione dei costi ed eccellenza operativa. <\/p>\n\n\n\n
La quantit\u00e0 di debito tecnico era considerevole, a causa di sistemi operativi molto vecchi, versioni obsolete di linguaggi di programmazione, librerie e versioni di database end-of-life.<\/p>\n\n\n\n
Non ci siamo fatti intimorire: il progetto era molto sfidante ma i prerequisiti erano chiari e l\u2019infrastruttura finale prevedeva applicazioni in container<\/strong>, database RDS<\/strong> ed alcuni siti statici ospitati sull\u2019accoppiata Amazon S3 + Amazon CloudFront<\/strong>.<\/p>\n\n\n\n
Lo sforzo maggiore gravava sulle spalle del team di sviluppo del cliente, costantemente supportato dai nostri Cloud Expert: per ogni applicazione andava affrontato un refactoring per renderla stateless<\/strong>, utilizzando i servizi gestiti AWS<\/strong> (come ad esempio utilizzare S3 per 5 Terabyte di asset statici).<\/p>\n\n\n\n
L\u2019inizio del progetto era concordato al termine della stagione natalizia, garantendo agli sviluppatori da un lato la possibilit\u00e0 di rilasciare aggiornamenti e bug fix alla piattaforma, dall\u2019altro concedendo loro tempo a sufficienza per prendere confidenza con termini, servizi e concetti del paradigma.<\/p>\n\n\n\n
Tutto sembrava procedere per il meglio, ma la legge di Murphy<\/a> \u00e8 sempre in agguato: durante il periodo del Black Friday il vecchio provider ha causato 2 giorni di downtime per problemi gravi, causando al cliente enormi perdite di profitto. <\/p>\n\n\n\n
Oltre al danno immediato, l\u2019evento ha fatto da elemento scatenante di numerose altre criticit\u00e0, cambiando , la priorit\u00e0 del progetto di migrazione da \u201cpianificata\u201d a \u201cappena possibile\u201d con un termine massimo fissato per il mese successivo. <\/p>\n\n\n\n
\u00c8 diventato subito ovvio che, data la scadenza, un refactor applicativo sarebbe stato impossibile: era necessaria una soluzione veloce, ma che garantisse al cliente lo stesso livello di affidibilit\u00e0. L\u2019opzione \u201crehosting\u201d<\/strong> a questo punto \u00e8 rientrata nell\u2019insieme delle possibili soluzioni.<\/p>\n\n\n\n
Per essere in grado di procedere al rehosting avevamo bisogno di uno strumento che ci permettesse di migrare macchine virtuali on-premise al Cloud di AWS, fornendo anche la possibilit\u00e0 di effettuare test e che mantenesse i dati sincronizzati fino alla messa in produzione del nuovo ambiente.<\/p>\n\n\n\n
Dopo una breve ricerca abbiamo deciso di utilizzare CloudEndure<\/a><\/strong>, un tool di una compagnia acquisita da AWS. <\/p>\n\n\n\n
CloudEndure fornisce la possibilit\u00e0 di migrare macchine fisiche e virtuali al Cloud di AWS, mantenendo i dati sincronizzati e permettendo di effettuare test sulle istanze migrate prima del \u201ccutoff\u201d (il momento in cui la migrazione si ritiene conclusa)<\/p>\n\n\n\n
Il diagramma di flusso per una migrazione standard effettuata utilizzando CloudEndure \u00e8:<\/p>\n\n\n\n
Diagramma di flusso per una migrazione standard con CloudEndure<\/figcaption><\/figure><\/div>\n\n\n\n Dopo aver concluso con successo un breve test utilizzando una configurazione comune (macchine virtuali Ubuntu 20.04) sono emersi i primi problemi: i sistemi operativi del cliente erano troppo vecchi e la loro esecuzione non era supportata sul Cloud AWS.<\/p>\n\n\n\n
Abbiamo a questo punto deciso di procedere con un replatforming in un ambiente di test<\/strong> utilizzando una versione di sistema operativo supportata da CloudEndure e, dopo aver validato il corretto funzionamento delle applicazioni, di procedere con la migrazione.<\/p>\n\n\n\n
Dopo alcuni tentativi infruttuosi abbiamo scoperto che la nostra unica possibilit\u00e0 era data dall\u2019utilizzo di Ubuntu 12.04<\/strong>, la minima versione supportata da CloudEndure.<\/p>\n\n\n\n
A causa di questa scelta non \u00e8 stato possibile usufruire di famiglie recenti delle istanze EC2: i driver per la piattaforma Nitro non sono disponibili, per cui abbiamo dovuto ripiegare sulle famiglie m4 per l\u2019ambiente di produzione. <\/p>\n\n\n\n
Per l\u2019esecuzione delle istanze sono infatti utilizzati ambienti basati su hypervisor differenti: Xen per le generazioni precedenti, KVM in combinazione con la piattaforma Nitro<\/a> per le famiglie di istanze pi\u00f9 recenti.<\/p>\n\n\n\n
Non \u00e8 stato nemmeno possibile migrare il database sulla piattaforma RDS a causa della versione dell\u2019engine troppo datata. Un cambio di engine in corsa avrebbe richiesto anche il cambio di alcune librerie utilizzate dal framework con risultati incerti.<\/p>\n\n\n\n
Una volta effettuato il deploy delle macchine virtuali nell\u2019ambiente di test per il replatforming, \u00e8 stato possibile effettuare la migrazione utilizzando CloudEndure, mantenendo i dati sincronizzati utilizzando rsync<\/strong>.<\/p>\n\n\n\n
Il workflow di migrazione \u00e8 diventato:<\/p>\n\n\n\n
New migration workflow<\/figcaption><\/figure><\/div>\n\n\n\n Non entriamo nei dettagli tecnici sull\u2019utilizzo di rsync o del processo di dump\/restore del database in quanto si tratta di comandi standard. Se avete dubbi o curiosit\u00e0 al riguardo segnalatecelo nei commenti e saremo felici di offrire un maggior dettaglio!<\/p>\n\n\n\n
Dopo aver messo in atto il nuovo piano tutto \u00e8 andato per il meglio con un unico disservizio pianificato di 3 ore dovuto al rallentamento del trasferimento dei dati causato dallo storage del provider sorgente. Dopo una attenta valutazione, le virtual machine sono state spente, fornendo al cliente un ambiente di produzione pi\u00f9 stabile.<\/p>\n\n\n\n
Takeaways<\/h2>\n\n\n\n
Come spesso accade, anche questo progetto ha dovuto adattarsi in corso d\u2019opera a situazioni non previste e intraprendere una direzione del tutto in attesa e piuttosto limitata rispetto ai vantaggi che il piano originario avrebbe garantito contando sui servizi gestiti di AWS. Nonostante ci\u00f2, la buona notizia \u00e8 che ora il progetto originale pu\u00f2 iniziare e, finalmente, il processo di modernizzazione dell\u2019applicazione pu\u00f2 essere avviato.<\/p>\n\n\n\n
Pur non essendo quasi mai una scelta ottimale, a volte una migrazione di tipo \u201cLift and Shift\u201d \u00e8 richiesta o quasi \u201cobbligata\u201d a causa di fattori esterni come tempo, costi di refactor o fattibilit\u00e0 tecnica. Occorre sempre tenere presente che il debito tecnico che molto spesso si accumula non aggiornando i sistemi, utilizzando librerie vecchie e versioni di linguaggi di programmazione non pi\u00f9 mantenuti, ad esempio, nasconde delle insidie. Prima tra tutte un costo nascosto consistente che potrebbe manifestarsi e compromettere non solo la buona riuscita di progetti importanti di migrazione, ma addirittura precludere le infinite possibilit\u00e0 che il Cloud offre anche in termini di spinta innovativa.<\/p>\n\n\n\n
Per maggiori informazioni su come procedere al refactoring e re-architecting delle applicazioni vi consigliamo la metodologia descritta nel sito della Twelve-Factor-app<\/a>: anche se non state ancora prevedendo di migrare al cloud, pu\u00f2 essere comunque utile per prevenire molti problemi futuri! <\/p>\n\n\n\n
Vi siete mai trovati ad affrontare sfide simili o improvvise che vi hanno costretti ad una cambio di passo repentino? Raccontateci le vostre imprese DevOps!<\/p>\n\n\n\n
A tra 14 giorni su #Proud2beCloud<\/strong> con un nuovo articolo!<\/p>\n","protected":false},"excerpt":{"rendered":"
\u201cLife is what happens to you while you’re busy making other plans\u201d scrisse John Lennon in \u201cBeautiful Boy\u201d. In questo […]<\/p>\n","protected":false},"author":13,"featured_media":3388,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[528,526,530],"class_list":["post-3370","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecting","tag-application-modernization-it","tag-cloud-migration-it","tag-cloudendure-it"],"yoast_head":"\n
Migrazione Ninja dall'on-premise al Cloud con CloudEndure - Proud2beCloud Blog<\/title>\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\t\n\n\n\n\n\n\n\t\n\t\n\t\n