Eccoci arrivati alla terza e ultima parte della serie “Come affrontare il Lift&Shift su Azure con zen”. Dopo aver parlato di Assessment dell’infrastruttura (nella prima parte) e aver valutato i diversi modelli di servizio che possiamo utilizzare in cloud mentre migriamo le isole applicative in Azure (nella seconda parte), oggi affronteremo gli ultimi 3 step del processo di migrazione al cloud: Design, Migration e Governance.
Step 3 – Design
Il Design è lo step time-consuming per antonomasia. Questo perchè, durante questa fase, il Solution Architect deve valutare come governare le risorse che verranno distribuite in cloud. Ad esempio, dovrà decidere: se utilizzare un’unica subscription o un design multi-subscription; quante crearne e quale criterio guiderà la distribuzione delle risorse; la tipologia di rete e le eventuali appliance di terze parti (firewall, bilanciatori, eccetera); il tipo di connettività verso l’on-premises necessario, eccetera.
Oltre a ciò, è necessario gestire altri aspetti fondamentali della nostra Infrastruttura quali: la sicurezza, la resilienza e la protezione del dato, senza mai perdere di vista i consumi. Nonostante non sia cosa facile, vi assicuro che è possibile.
Ricordatevi che in cloud la resilienza o l’alta disponibilità dei servizi è sempre una vostra preoccupazione in caso di infrastrutture IaaS (VM) e che il Disaster Recovery deve essere sempre configurato e implementato da voi per tutti i servizi, anche quelli PaaS.
Design – Subscription
Come anticipato, la prima domanda che ci si dovrebbe porre nella fase di Design è “Quante subscription mi servono?”. La risposta prediletta dalle aziende è “Una sola subscription”.
A mio avviso, questa scelta è preferibile quando le risorse da distribuire non sono molte e non si hanno particolari esigenze di suddivisione dei consumi lato finance; ed è una scelta che consiglio per chi si sta avvicinando al cloud. Per gli altri casi, invece, sarebbe ottimale separare le risorse degli ambienti di produzione e quelle di sviluppo/ test /pre-produzione in diverse subscription. Questo vi permetterà anche di risparmiare, dato che è possibile definire una subscription Test/Dev, ottenendo una riduzione dei consumi per questo ambiente.
Ovviamente, la suddivisione può essere effettuata anche sulla base di criteri geografici, dipartimentali o per funzione, applicazione e workload.
Ci tengo a precisare che, al contrario di quanto si possa pensare, gestire una sola subscription non è più semplice di gestirne dieci. Ad esempio, se avessi una sola Subscription per più dipartimenti, dovrei creare tanti ruoli custom quanti sono i responsabili di dipartimento, affinché possano vedere i costi delle proprie risorse. Inoltre, dovrei avere sempre una mappatura e un controllo stringente di tutti i progetti in azienda per poter abbinare ogni ruolo ai Resource Group che contengono solo risorse per quel dato reparto. Al contrario, con una subscription per ogni reparto sarebbe sufficiente assegnare i ruoli standard.
Considerate anche che qualche servizio, come Azure AD Domain Services, può essere distribuito uno per subscription e comporterà il moltiplicarsi delle stesse.
Di seguito lo schema finale di una simile soluzione, per ogni reparto dell’organizzazione:
Design – Networking
Qualunque sia il numero di subscription scelto, le risorse distribuite in cloud avranno bisogno di una o più reti virtuali. Se le applicazioni sono poche, molto semplici e non avrete necessità di implementare piani di Disaster Recovery granulari, basterà una sola vNet per ambiente, che potrete segregare con i network security group (NGS) associate alle subnet della/e vNet. Tenete presente che potete connettere fra loro con routing esplicito varie vNet (Peering), anche distribuite in diverse subscription (e tenant, aggiungo io) in una configurazione denominata topologia Hub&Spoke.
L’immagine mostra un classico esempio di tipologia Hub&Spoke: nella rete Hub vengono distribuiti i servizi comuni a tutte le applicazioni (ad esempio la connettività verso il data center on premises, o i domain controller per Active Directory, o l’appliance virtuale del firewall perimetrale); nelle altre vNet vengono distribuite le varie applicazioni. Nel caso si voglia un piano di Disaster Recovery granulare è d’obbligo implementare una vNet per applicazione o servizio. In questa tipologia è molto importante pianificare gli spazi di indirizzi di rete non in sovrapposizione con quelli già esistenti. Se voleste implementare questa soluzione ma avete già tutto in una singola vNet, dovrete rifare le VM esistenti, mantenendo i dischi, per connetterle alle nuove reti.
In cloud le risorse aumentano e si modificano rapidamente; se non si costruisce un’infrastruttura modulare si rischia di incontrare difficoltà di implementazione e di gestione. Come scritto nel primo articolo, qui non valgono le semplificazioni del data center on premises.
Step 4 – Migration
Dopo aver tracciato il design, si passa finalmente allo step della migrazione. L’ideale sarebbe lavorare con l’ambiente di Dev/Test, se presente, prima che con quello di produzione, avendo definito a priori i test per verificare le soluzioni del pilota.
Inoltre, è consigliabile partire con un progetto pilota di un’applicazione non cruciale per il business, ma di una certa complessità. Ad esempio, migrare un’applicazione a più tier invece di un’applicazione installata su una singola VM, sarà più utile per verificare la bontà del design, confermare o meno le scelte della topologia di rete e predisporre gli strumenti di DevOps per la fase di migrazione vera e propria.
Se il test pilota si conclude positivamente, si potrà procedere con la migrazione completa non dimenticandosi di: distribuire tutte le componenti previste in fase di design, attivare la connettività tra on-premises e il cloud, pianificare attentamente lo switch in cloud mitigando i periodi di disservizio, eseguire ogni volta il test dell’isola applicativa migrata e completare la migrazione di ogni singola isola applicativa prima di approcciarne un’altra.
Con questo metodo si concluderà celermente la migrazione, minimizzando le sorprese durante il processo.
Step 5 – Governance
Dopo aver completato la migrazione, inizia la fase di governance delle risorse, che punta all’ottimizzazione dei consumi, all’applicazione continua delle best practice, all’eventuale trasformazione dei servizi da IaaS a PaaS e, se non ancora fatto, all’implementazione del Disaster Recovery Plan delle risorse.
Fortunatamente in Azure si hanno molteplici strumenti per governare le risorse, come Management Group, Azure Policy e i seguenti.
- Il servizio Azure Security Center notifica eventuali problemi di sicurezza delle nostre applicazioni e propone soluzioni per mitigarli.
- Azure Monitor permette di misurare le prestazioni delle risorse distribuite, generando allarmi di notifica che possono a loro volta scatenare processi di remediation automatica.
- Per i costi, invece, troviamo Azure Advisor con le sue raccomandazioni per ottimizzare i consumi (come VM sovradimensionate che possono essere scalate verso il basso).
- In Azure Cost and Management Billing vi è anche la possibilità di generare degli oggetti denominati Budget impostando degli allarmi sui consumi in forecasting, mensili o annuali.
E, così, siamo arrivati al termine del percorso di migrazione al cloud, che è al contempo l’inizio di un altro viaggio importante: la trasformazione della nostra infrastruttura e dei nostri servizi.
Con questo vademecum, spero di aver reso il vostro Lift&Shift un po’ più sereno e di avervi lasciato qualche spunto di riflessione, sia in caso voi stiate per intraprendere il percorso di migrazione, sia che voi siate già utilizzatori del cloud computing da tempo.
Rimanete connessi: prossimamente sul blog approfondiremo gli aspetti di design e i componenti utili a comporre le soluzioni distribuite in Azure. Stay tuned and jump to cloud!
