{"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