Descrivere Azure Migration Framework
Prima di iniziare a eseguire la migrazione dei carichi di lavoro locali di Tailwind Traders in Azure, è opportuno creare un piano di migrazione. Il piano deve identificare i carichi di lavoro di cui eseguire la migrazione e il servizio o gli strumenti appropriati da usare durante la migrazione. Idealmente, il piano deve includere anche dettagli su come ottimizzare i servizi migrati.
Il framework di migrazione di Azure può aiutare a sviluppare il piano e ad eseguire la migrazione. Il framework è costituito da quattro fasi: Valutazione, Migrazione, Ottimizzazione e Monitoraggio.
Fase 1 - Valutare l'ambiente locale
Nella prima fase si valuta l'ambiente locale attuale:
- Identificare le app e i relativi server, servizi e dati correlati inclusi nell'ambito della migrazione
- Iniziare a coinvolgere gli stakeholder, ad esempio il reparto IT e i gruppi aziendali pertinenti
- Creare un inventario completo e una mappa di dipendenze di server, servizi e app di cui si intende eseguire la migrazione
- Stimare i risparmi sui costi usando il Calcolatore del costo totale di proprietà di Azure
- Identificare gli strumenti e i servizi appropriati da usare per attuare le quattro fasi
Criteri di strategia di migrazione
Esistono cinque modelli di strategia generali per la migrazione dei carichi di lavoro nel cloud, definiti in genere Le cinque R della razionalizzazione: rehosting, refactoring, riprogettazione, ricompilazione e rimpiazzo. La strategia adottata dipende dai fattori chiave dello sviluppo aziendale e dagli obiettivi di migrazione prefissati. È possibile adottare più criteri. Si potrebbe optare per il rehosting di app semplici o app che non sono cruciali per l'azienda, scegliendo di riprogettare quelle più complesse e critiche.
Rehosting:il rehosting è noto anche come migrazione in modalità lift-and-shift. Adottando questa strategia non è necessario apportare modifiche al codice ed è possibile eseguire rapidamente la migrazione ad Azure dei carichi di lavoro esistenti. Ogni carico di lavoro viene migrato così com'è, senza i rischi e i costi associati alle modifiche del codice.
Refactoring: il refactoring viene spesso definito anche repackaging. Il refactoring richiede modifiche minime alle app, in modo che possano connettersi alla piattaforma distribuita come servizio (PaaS) di Azure e sfruttare le offerte del cloud. È possibile eseguire la migrazione delle app esistenti al Servizio app di Azure o al servizio Azure Kubernetes. In alternativa, si può effettuare il refactoring di database relazionali e non relazionali in altre opzioni. Effettuare il refactoring in Istanza gestita di SQL di Azure, Database di Azure per MySQL, Database di Azure per PostgreSQL e Azure Cosmos DB (se è possibile creare facilmente un nuovo pacchetto dell'app per funzionare in Azure).
Riprogettazione: la riprogettazione per la migrazione è incentrata sulla modifica e sull'estensione della codebase e delle funzionalità dell'app al fine di ottimizzarne l'architettura per la scalabilità nel cloud. È possibile suddividere un'applicazione monolitica in un gruppo di microservizi che funzionano insieme e sono facilmente scalabili. In alternativa, è possibile riprogettare i database relazionali e non relazionali in una soluzione di database completamente gestita. Riprogettare in Istanza gestita di SQL di Azure, Database di Azure per MySQL, Database di Azure per PostgreSQL e Azure Cosmos DB.
Ricompilazione: questa strategia consente di compiere un passo in avanti ricreando completamente un'app con le tecnologie cloud di Azure. È possibile creare app greenfield con tecnologie native del cloud come Funzioni di Azure, Azure per intelligenza artificiale, Istanza gestita di SQL di Azure e Azure Cosmos DB.
Sostituzione: Implementare soluzioni che usano la tecnologia e l'approccio migliori disponibili in questo momento. A volte, le applicazioni SaaS (Software as a Service) possono fornire tutte le funzionalità necessarie per le applicazioni ospitate. Un carico di lavoro può quindi essere pianificato per la sostituzione, in modo da rimuoverlo dall'ambito di migrazione.
Nella tabella seguente sono elencati gli scenari per l'uso dei quattro criteri.
| Rehosting | Refactoring | Riprogettazione | Ricostruzione | Sostituzione |
|---|---|---|---|---|
| Spostare rapidamente i carichi di lavoro nel cloud Spostare un carico di lavoro senza modificarlo Per le app progettate per sfruttare la scalabilità IaaS di Azure dopo la migrazione Quando i carichi di lavoro sono importanti per l'azienda, ma non è necessario apportare modifiche immediate alle funzionalità delle app |
Applicare procedure DevOps innovative fornite da Azure Implementare una strategia di contenitori DevOps per i carichi di lavoro Supportare la portabilità della codebase esistente e le competenze di sviluppo disponibili |
Le app necessitano di revisioni importanti per incorporare nuove funzionalità Le app necessitano di revisioni importanti per funzionare efficacemente su una piattaforma cloud Usare gli investimenti di applicazioni esistenti Soddisfare i requisiti di scalabilità Applicare procedure DevOps innovative Ridurre al minimo l'uso delle macchine virtuali |
Velocizzare lo sviluppo Supportare le app esistenti con funzionalità e durata limitate Accelerare l'innovazione aziendale con le procedure DevOps Ricompilare con nuove tecnologie native del cloud come Azure Blockchain Ricompilare le applicazioni legacy come app senza codice o con poco codice nel cloud |
Standardizzare in base alle procedure consigliate del settore Accelerare l'adozione di approcci basati su processi aziendali Riallocare gli investimenti di sviluppo che creano una differenziazione o vantaggi competitivi Sostituire le soluzioni esistenti a favore delle offerte SaaS |
Fase 2 - Eseguire la migrazione dei carichi di lavoro
Dopo aver completato la valutazione, è possibile iniziare il processo di migrazione delle app di destinazione e dei relativi servizi e dati correlati. La fase di migrazione consiste in genere nelle attività seguenti:
Distribuire le risorse di destinazione dell'infrastruttura cloud. Prima di poter eseguire la migrazione dei carichi di lavoro di Tailwind Traders, occorre creare le risorse di destinazione dell'infrastruttura cloud necessarie. A seconda degli strumenti usati per la migrazione, potrebbe essere necessario creare le risorse di Azure necessarie prima di iniziare la migrazione. Alcuni strumenti, come Azure Migrate e Servizio Migrazione del database di Azure, possono creare le risorse di Azure di destinazione per l'utente.
Eseguire la migrazione dei carichi di lavoro. È consigliabile effettuare un progetto pilota della migrazione dei carichi di lavoro e scegliere un'app di importanza non cruciale. Questo approccio consente di acquisire familiarità con gli strumenti, fare pratica con i processi e le procedure e ridurre i rischi durante la migrazione di carichi di lavoro complessi o di grandi dimensioni.
Rimuovere l'infrastruttura locale: una volta che la migrazione di app e database è stata completata correttamente, è necessario rimuovere i carichi di lavoro di origine. È consigliabile conservare i backup del carico di lavoro di origine e dei dati archiviati. Questi dati potrebbero risultare utili perché forniscono un archivio cronologico. È possibile archiviare questi backup e archivi in Archiviazione BLOB di Azure.
Fase 3 - Ottimizzare i carichi di lavoro migrati
La fase di ottimizzazione prevede tre attività principali su cui concentrarsi per la pianificazione:
- Analizzare i costi di migrazione dei carichi di lavoro
- Esaminare i consigli per ridurre i costi
- Identificare le opzioni per migliorare le prestazioni dei carichi di lavoro
È possibile usare Gestione dei costi Microsoft (in precedenza Gestione dei costi e fatturazione di Azure) nel portale di Azure per analizzare i costi dei carichi di lavoro. Questo strumento è disponibile per il gruppo di risorse di Azure che contiene i carichi di lavoro di cui è stata eseguita la migrazione. Si trova nella sezione Analisi dei costi>Gestione costi. Lo screenshot seguente mostra l'analisi dei costi per l'ultimo periodo fatturabile per il gruppo di risorse ContosoResourceGroup. I risultati mostrano i costi in base a nome del servizio, area e risorsa. È possibile personalizzare la visualizzazione dei risultati in base alle esigenze.
Per ridurre i costi, è possibile usare le funzionalità di Azure Advisor scegliendo Raccomandazioni Advisor. Dopo aver analizzato i costi correnti ed esaminato le raccomandazioni, è possibile determinare le opzioni per migliorare le prestazioni dei carichi di lavoro.
Fase 4 - Monitorare i carichi di lavoro
È possibile usare Monitoraggio di Azure per acquisire informazioni sull'integrità e sulle prestazioni delle macchine virtuali di Azure. Installare l'agente Log di Monitoraggio di Azure (in precedenza Log Analytics) nelle macchine virtuali di destinazione e quindi configurare avvisi e report.
Nota
L'agente Log di Monitoraggio di Azure può essere installato nelle macchine virtuali che eseguono Windows o Linux.
È possibile configurare gli avvisi in base a una gamma di origini dati:
- Valori di metriche specifici, ad esempio l'utilizzo della CPU
- Testo specifico nei file di log
- Metriche di integrità
- Metriche della scalabilità automatica