Il framework di migrazione 6-R

Il framework di migrazione 6-R è un approccio strutturato per classificare il modo in cui ogni carico di lavoro locale deve essere trasferito nel cloud. Microsoft e il settore in generale usano queste sei strategie — chiamate anche modelli di migrazione — per rendere efficienti e coerenti le decisioni relative al portafoglio. Invece di applicare un approccio uguale per tutti, gli architetti valutano ogni applicazione singolarmente e le assegnano la R più appropriata.

Rehost (Lift and Shift) significa trasferire un carico di lavoro in Azure con nessuna modifica al codice. Si prende l'immagine VM o il binario dell'applicazione esistente e lo si esegue su Azure IaaS. È la strategia più rapida e viene in genere usata per le applicazioni legacy difficili da modificare o dalle organizzazioni con scadenze di migrazione ravvicinate. Il motore di replica di Azure Migrate automatizza il rehosting per la maggior parte delle VM Windows e Linux.

Replatform (chiamato anche Lift, Tinker, and Shift) prevede piccole ottimizzazioni durante la migrazione, senza modificare l'architettura di base. Gli esempi includono lo spostamento di un database MySQL autogestito da una VM a Azure Database for MySQL oppure la sostituzione di un relay SMTP autogestito con Azure Communication Services. Si ottengono i vantaggi dei servizi gestiti — applicazione di patch, backup e scalabilità — senza riscrivere la logica dell'applicazione.

Rearchitect (o Refactor) significa modificare in modo significativo l'architettura dell'applicazione per sfruttare le funzionalità cloud-native. Un'applicazione .NET monolitica potrebbe essere suddivisa in microservizi distribuiti in Azure Container Apps, oppure un sistema batch basato su processi cron potrebbe essere reimplementato come Azure Functions. La riprogettazione offre i maggiori vantaggi a lungo termine in termini di scalabilità e costi, ma richiede il maggiore investimento.

Rebuild significa abbandonare completamente l'applicazione esistente e crearne una nuova cloud-native. Questa strategia viene scelta quando l'applicazione legacy è troppo costosa da mantenere, usa uno stack tecnologico non più supportato oppure non può soddisfare i requisiti aziendali nemmeno dopo la migrazione. Rebuild offre il massimo vantaggio cloud-native, ma richiede il tempo più lungo per ottenere valore. I servizi PaaS e serverless di Azure, come Azure App Service, Azure Functions e Cosmos DB, sono destinazioni comuni.

Replace significa sostituire un'applicazione locale esistente con un prodotto SaaS disponibile sul mercato, che offre funzionalità equivalenti o superiori. Ad esempio, si può sostituire un CRM locale con Dynamics 365 oppure un file server legacy con SharePoint Online. Replace elimina completamente la gestione dell'infrastruttura. Il compromesso consiste in una personalizzazione ridotta e in un impegno potenzialmente significativo per la migrazione dei dati e la gestione del cambiamento.

Retire è la strategia più semplice: si individuano le applicazioni non più utilizzate, ridondanti o sostituite da altre e le si dismette invece di migrarle. I dati di individuazione raccolti da Azure Migrate rivelano spesso che una percentuale significativa (a volte il 20–30%) dei server locali ha un utilizzo molto basso o nessun utente attivo. La dismissione di queste applicazioni riduce l'ambito della migrazione, i costi delle licenze e la complessità operativa.

Per selezionare la R appropriata è necessario analizzare quattro fattori per ogni applicazione: criticità aziendale, complessità tecnica, tempistiche della migrazione e costo totale di proprietà. Un semplice front-end Web senza dipendenze di integrazione è un buon candidato per Rehost. Un'applicazione con centinaia di stored procedure e funzionalità di database personalizzate potrebbe richiedere Rearchitect o Rebuild. Gli strumenti interni di scarso valore sono candidati ideali per Retire o Replace.

Azure Migrate offre una funzionalità Business Case che suggerisce automaticamente una strategia di migrazione per i server individuati, in base ai dati di utilizzo, alle licenze e ai prezzi di Azure. Raggruppa i carichi di lavoro nelle categorie Rehost, Replatform e End-of-Support, fornendo una base iniziale per la classificazione 6-R. È possibile ignorare qualsiasi suggerimento e aggiungere il proprio contesto aziendale prima di finalizzare il piano di migrazione.

Dopo aver assegnato una R a ogni applicazione, le si raggruppa in ondate di migrazione. I candidati Rehost a basso rischio costituiscono in genere la prima ondata, per aumentare la fiducia del team e la familiarità con gli strumenti. I progetti Rearchitect e Rebuild vengono eseguiti in flussi di lavoro paralleli e con tempistiche più lunghe. È necessario rispettare le dipendenze tra le applicazioni — ad esempio tra un livello Web che chiama un database condiviso — affinché le applicazioni correlate vengano migrate insieme o nell'ordine corretto.

Le 6-R sono allineate alla fase Adopt del Cloud Adoption Framework di Microsoft. Il CAF fornisce modelli per la pianificazione delle ondate, matrici RACI e questionari di valutazione dei carichi di lavoro che rendono operative le 6-R su scala aziendale. I meccanismi di governance stabiliti durante la fase Ready — landing zone, criteri e identità — devono essere configurati prima dell'inizio delle ondate di migrazione, in modo che i carichi di lavoro migrati vengano inseriti in un ambiente conforme fin dal primo giorno.

Verificate la vostra comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione avete appreso che il framework 6-R (Rehost, Replatform, Rearchitect, Rebuild, Replace, Retire) fornisce un vocabolario per le decisioni di migrazione, che ogni R presenta un compromesso diverso tra costi e velocità e che la funzionalità Business Case di Azure Migrate può suggerire automaticamente le strategie in base ai dati di utilizzo. Ora analizzeremo come Azure Migrate individua e valuta i server locali.