Migrazione ibrida e multi-cloud
Nella metodologia di migrazione di Cloud Adoption Framework, la migrazione al cloud è già considerata un processo ibrido o multicloud. La maggior parte delle indicazioni incluse in tale metodologia continuerà a essere pertinente quando si esegue la migrazione a un ambiente ibrido e multi-cloud. Il principale cambiamento rispetto a tale metodologia è correlato all'obiettivo a lungo termine delle migrazioni.
In genere, le attività di migrazione sono state considerate come una strada a senso unico. Gli asset si vengono spostati nel cloud o in un nuovo cloud e vi rimangono. In un ambiente ibrido e multi-cloud le attività di migrazione sono più simili a un'autostrada a più corsie. Gli asset vengono spostano tra più cloud pubblici e privati in base ai mutevoli requisiti aziendali o tecnici. Questo cambiamento nella strategia di migrazione ha un impatto minimo sul processo di migrazione, ma può influire direttamente sulle attività eseguite prima e dopo la migrazione.
Effetto sui processi specifici della migrazione
L'effetto diretto delle divergenze sui processi di migrazione è minimo, ma conoscerle può aumentare le probabilità di successo dell'organizzazione. La migrazione dei carichi di lavoro prevede tre processi di alto livello ripetuti in fasi, o sprint, fino al completamento. Ecco una rapida panoramica sui cambiamenti che interessano questi processi:
- Valutare i carichi di lavoro: alcune considerazioni consentiranno di definire le modalità di valutazione dei carichi di lavoro prima della migrazione.
- Distribuire i carichi di lavoro: la distribuzione delle fasi dei carichi di lavoro rimane in gran parte invariata. È però possibile scegliere di usare parte dell'ecosistema di Azure Migrate per velocizzare tipi specifici di migrazioni.
- Rilasciare i carichi di lavoro: dopo la distribuzione dei carichi di lavoro, il principale cambiamento si nota nei cicli di test prima del rilascio al traffico di produzione.
Più avanti in questo articolo verranno fornite altre informazioni su come valutare, distribuire o rilasciare i carichi di lavoro all'interno dei processi di migrazione. Leggere prima di tutto la sezione successiva sulle modifiche più importanti apportate ai processi upstream e downstream che influiranno sulla migrazione.
Effetto sui processi upstream e downstream
Quando si esegue la migrazione dei carichi di lavoro in un ambiente ibrido e multi-cloud, l'effetto reale è evidente sulle attività che precedono o seguono la migrazione. Prima di eseguire la migrazione dei carichi di lavoro in un approccio ibrido e multi-cloud, vedere Introduzione all'ambiente ibrido e multi-cloud e Introduzione alle operazioni unificate per informazioni sulle altre modifiche richieste in aggiunta all'impegno richiesto per la migrazione.
Avviso
I collegamenti precedenti forniscono informazioni dettagliate di carattere generale che consentono di ottenere risultati. All'interno di questi articoli sono disponibili collegamenti a modifiche tecniche ed effetti rilevanti. Non procedere con una migrazione basata su una strategia ibrida e multi-cloud senza conoscere almeno l'impatto sul piano, sull'idoneità dell'ambiente e sulla gestione delle operazioni. La mancata preparazione di tali attività comporta costi operativi maggiori e potrebbe causare un blocco imprevisto da parte del fornitore.
Valutare i carichi di lavoro per la migrazione ibrida e multi-cloud
I prodotti Azure usati in una migrazione standard sono comunque applicabili a una migrazione ibrida e multi-cloud. In particolare, è possibile usare Azure Migrate e Mapping dei servizi per conoscere il digital estate e definire le dipendenze. Per altre informazioni su entrambi gli strumenti, vedere la guida introduttiva per la valutazione dei carichi di lavoro. Quando si crea il piano o si valutano le fasi dei carichi di lavoro ibridi e multi-cloud, rimangono comunque valide le procedure consigliate per la valutazione del digital estate in Azure.
Se le migrazioni ibride e multi-cloud che presentano problemi di valutazione, i processi di valutazione del team di migrazione non sono ancora maturi. Tenere conto delle considerazioni seguenti nei piani di valutazione:
Quando si valutano i carichi di lavoro, considerare la compatibilità con Azure e le zone di destinazione di Azure. Durante la valutazione del carico di lavoro è anche necessario considerare la compatibilità con eventuali vincoli previsti da rete ibrida, identità ibrida, sicurezza ibrida, gestione ibrida o governance definiti in altri ambienti ibridi o multi-cloud.
Prestare maggiore attenzione alle dipendenze perché una percentuale maggiore di asset potrebbe essere ospitata in altri cloud.
Conoscere i motivi alla base della decisione di adottare una soluzione ibrida e multi-cloud per valutare la compatibilità dei vari carichi di lavoro con strumenti che supportano:
- Compatibilità con Azure Stack HCI, che è importante se si intende modernizzare il data center per consentire soluzioni native del cloud in locale.
- Compatibilità con Kubernetes, che è importante se si intende mantenere la portabilità tramite l'infrastruttura basata su contenitori.
- Compatibilità con Azure Edge, che potrebbe essere importante per estendere i carichi di lavoro e ridurre la latenza al momento dell'interazione.
- Requisiti normativi, di conformità o aziendali, in base ai quali è possibile che alcuni asset o dati debbano rimanere locali. Per gestire, gestire, proteggere, configurare e monitorare gli asset locali da Azure, è possibile prendere in considerazione i server abilitati per Azure Arc, VMware vSphere abilitato per Azure Arc e System Center Virtual Machine Manager abilitato per Azure Arc.
Questi articoli consentono di sviluppare i processi più importanti richiesti per questo tipo di migrazione:
- Responsabilità
- Classificazione dei carichi di lavoro
- Compatibilità cloud
- Gestione delle modifiche Agile
- Creazione di un backlog di migrazione ben definito
Distribuire carichi di lavoro di cui è stata eseguita la migrazione per ambienti ibridi e multi-cloud
Quando si esegue la migrazione al cloud, predisporre un inventario chiaro di tutti gli asset dipendenti e dei percorsi di rete per assicurarsi che tali asset vengano distribuiti nel cloud corretto. Un inventario chiaro, ovvero una valutazione del digital estate, risulta ancor più importante negli ambienti ibridi prima di eseguire la migrazione dei carichi di lavoro. Vedere la sezione precedente Valutare i carichi di lavoro prima di provare a eseguire la migrazione dei carichi di lavoro in un ambiente ibrido e multi-cloud.
Azure Migrate è la soluzione principale per la migrazione dei carichi di lavoro dal cloud privato ad Azure. Le procedure consigliate per la migrazione ad Azure da altri cloud pubblici variano. Potrebbe anche essere necessario aggiungere altri strumenti quando si esegue la migrazione ad Azure Stack HCI. Vedere le esercitazioni seguenti:
- Eseguire la migrazione da AWS ad Azure
- Eseguire la migrazione da GCP ad Azure
- Eseguire la migrazione ad Azure Stack HCI
Rilasciare carichi di lavoro di cui è stata eseguita la migrazione per ambienti ibridi e multi-cloud
I piani di test, benchmarking e dimensionamento e promozione sono importanti quando si esegue la migrazione al cloud. I carichi di lavoro ibridi e multi-cloud sono maggiormente dipendenti da asset decentralizzati e dalle reti che li connettono. Sono più soggetti a problemi di latenza, connettività e routing, che potrebbero sembrare problemi di prestazioni della piattaforma cloud. Per il test e il debug di carichi di lavoro ibridi e multi-cloud è necessario allocare un tempo maggiore rispetto ai carichi di lavoro distribuiti in un singolo provider di servizi cloud per i livelli aggiuntivi di identità e rete.
Ecco alcune considerazioni da includere nel piano di test quando si esegue la migrazione a un ambiente ibrido e multi-cloud:
- Allineare i test aziendali e IT
- Benchmark e ridimensionare gli asset
- Procedure consigliate per il ridimensionamento e i costi
- Promuovere la produzione
- Prepararsi per le operazioni unificate
Passaggi successivi
Per altre indicazioni sul percorso di adozione del cloud, vedere gli articoli seguenti: