Eccoci arrivati alla seconda parte della serie di articoli su “Come affrontare il Lift&Shift su Azure con zen”.
Nel precedente articolo abbiamo parlato di Assessment, ossia il primo dei cinque step necessari per affrontare al meglio il Lift&Shift sul cloud. Oggi, invece, cercheremo di fare chiarezza sui modelli di servizio che possiamo utilizzare in cloud mentre migriamo le nostre isole applicative in Azure.
Step 2 – Model
Quando ci chiediamo quale modello di servizio sia meglio utilizzare per passare al cloud, un elemento che ci viene in aiuto è sicuramente il Cloud Adoption Framework (CAF): un insieme di linee guida e best practice che i grandi Cloud Provider mettono a disposizione dei clienti per aiutarli ad affrontare il Lift&Shift e adottare il cloud computing.
Il CAF, in questo caso, ci indica quelle che sono definite le cinque R del cambiamento o della trasformazione digitale che permettono di rispondere alla domanda “Quale servizio cloud fa per me? IaaS, PaaS o SaaS?”.
Scopriamo insieme quali sono le 5 R e quali sono le azioni da compiere per ognuna.
1. Retire
Sul vostro pc avete ancora l’applicazione scritta in ASP nel lontano 2001? Oppure avete scaricato 3 applicazioni per creare PDF? Ecco, prima di andare in cloud, applichiamo la R di Retire e mandiamole tutte in pensione! Facciamo pulizia mantenendo le app più moderne e cloud ready.
Tuttavia, mentre fate pulizia, potreste trovare delle applicazioni legacy : app un po’ obsolete che continuate ad utilizzare perché “non possono essere rimpiazzate”. Cosa fare in questo caso? Il CAF ci suggerisce queste 4 opzioni: Replace, Retain, Rehost e Re-envision.
2. Replace
Potete decidere di sostituire (Replace) completamente, o in parte, alcune di queste app legacy con componenti cloud; magari sfruttando modelli SaaS e PaaS che hanno un Total Cost Ownership (TCO) più efficiente.
3. Retain (wrap and expand)
Nonostante tutti i vostri sforzi, pensate ancora che ci sono alcune applicazioni legacy per cui non c’è nulla da fare: sono talmente annidate nei processi industriali e legate ad altre applicazioni, che non è possibile applicare i passaggi Retire e Replace.
Ma niente panico, perché la R di Retain ci dà un’altra possibilità! Infatti, l’applicazione continuerà ad essere eseguita nel data center legacy, ma verrà modernizzata inglobandola in una nuova veste (in inglese “to wrap”: rivestire), senza quasi doverne ritoccare il codice.
Ad esempio, l’applicazione scritta nel lontano 2001 in ASP per i rapporti di intervento di cui parlavamo all’inizio, è talmente annidata fra i vari processi che risulta impossibile trasformarla, se non a fronte di considerevoli investimenti. Tuttavia è possibile renderla mobile, grazie agli App Service in Azure, e anche più intelligente, tramite i Cognitive Services di Azure, tanto da integrarla persino con funzioni vocali e chatbot, con Google Assistant, Alexa, Cortana, Telegram, Skype for Business, Teams e molto altro.
L’applicazione è la stessa del 2001, ma l’esperienza utente è quella del 2020!
4. Rehost
Il Rehost – che significa letteralmente “riospitare”- indica il vero e proprio Lift&Shift. Se l’applicazione legacy è produttivamente valida, ma costosa nella sua esecuzione, sarà sicuramente una mossa intelligente spostarla in cloud nella modalità Iaas, sfruttando qualche componente in Paas ove possibile (come la base dati).
Spostare una Virtual Machine da on-premises al cloud potrebbe non sembrarvi la soluzione ottimale. Per cambiare idea, vi basterà pensare a come reagiscono al cloud i servizi a supporto della stessa VM: ad esempio, il backup con long retention in cloud è implementabile senza gestire infrastrutture e senza problemi di approvvigionamento dello storage; oppure, se avete particolari esigenze di sicurezza, sappiate che la crittografia dello storage in cloud è nativa e stratificabile in maniera trasparente per la VM; o, ancora, pensate alla modulabilità dell’uso delle risorse sia verticali sia orizzontali, che rende il cloud un’alternativa efficiente se usata e governata correttamente.
5. Re-envision
Se l’applicazione legacy ha una produttività elevata, ma non sono applicabili le tre R precedenti – Replace, Retain e Rehost – potrebbe essere il momento di ripensarla da zero. Questo può essere fatto durante il Lift&Shift, oppure in un secondo momento quando l’adozione del cloud si sia consolidata. A mio parere quest’ultima scelta è la più opportuna, data l’enorme quantità di tempo che è richiesta per ottenere l’applicazione completamente rinnovata e ricostruita secondo i nuovi paradigmi di sviluppo Agile e a microservice. Da non sottovalutare anche la necessità di acquisire nuove competenze per raggiungere questo scopo.
E quindi?
Tenendo a mente queste linee guida possiamo riassumere nello schema seguente alcune valutazioni che possono guidare le vostre scelte di modello dei servizi in cloud.
È consigliato scegliere il modello Iaas nel caso in cui non si abbia il tempo necessario per re-ingegnerizzare l’isola applicativa o il singolo tier; e si decide quindi di trasformarla/o in un secondo momento con Rehost e Re-Envision.
Se l’applicazione fosse già “cloud ready” si potrebbero sfruttare modelli scalbili e più efficienti in IaaS, come i VM ScaleSet, o direttamente gli App Services, come nel caso di frontend WEB.
Se siamo fortunati e già utilizziamo da tempo i container, allora potremo sfruttare gli Azure Kubernetes Services per i microservizi di frontend e backend, e i servizi di Azure Synapse e Databricks per l’analisi dei dati, utilizzando i Cognitive Services se necessario.
Discorso a parte per il tier data che può essere redistribuito in Azure tramite IaaS, oppure PaaS con i servizi di Azure Database che coprono ormai quasi tutti gli engine DB, arrivando a fornire anche un modello ibrido fra le due modalità per SQL Server con le Managed Instance.
Infine, per concludere questa seconda parte del nostro viaggio verso il cloud, non mi resta che consigliarvi nuovamente di prendervi tutto il tempo necessario per valutare correttamente il miglior modo possibile per portare le vostre isole applicative su Azure.
Enjoy, and jump to cloud!
→ Torna alla prima parte di “Come affrontare il Lift&Shift su Azure con Zen” dedicata alla fase di Assessment.
→ 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.
Per questo articolo ho preso spunto dal testo Enterprise Cloud Strategy, 2nd Edition, di Eduardo Kassner (@ekassner), Chief Technology Officer del OCP Enablement & Innovation team di Microsoft, e Barry Briggs (www.barrybriggs.com), Serial CTO, Cloud/Enterprise Architect in Microsoft. Il testo, scaricabile qui, descrive una delle prime versioni del Cloud Adoption Framework della casa di Redmond.Mentre scrivo questo articolo, Microsoft ha rilasciato una nuova versione del CAF, che sostanzialmente rivede e migliora alcune parti del precedente. Se siete interessati a leggere come costruire un modello operativo con CAF Azure qui potete scaricare l’e-book Building a Digital Operating Model with Microsoft Cloud Adoption Framework.Consiglio di leggerli entrambi non solo ai Cloud Solution Architect (CSA) e i Business Decision Maker (BDM), ma anche agli IT Pro che lavorano tutti i giorni con il cloud. Sono testi pieni di ottimi spunti sulla strategia dell’approccio al cloud.
