Questo documento fornisce indicazioni su approcci comuni e comprovati e considerazioni per eseguire la migrazione dei carichi di lavoro nel cloud. Approfondisce le linee guida riportate in Progettare una strategia per un'architettura ibrida e multi-cloud, che illustra i vari passaggi possibili e consigliati per progettare una strategia per l'adozione di un'architettura ibrida o multi-cloud.
Cloud-first
Un modo comune per iniziare a utilizzare il cloud pubblico è l'approccio cloud-first. Con questo approccio, esegui il deployment dei nuovi carichi di lavoro nel cloud pubblico, mentre quelli esistenti rimangono dove si trovano. In tal caso, prendi in considerazione un deployment classico in un ambiente di computing privato solo se un deployment nel cloud pubblico è impossibile per motivi tecnici o organizzativi.
La strategia cloud-first presenta vantaggi e svantaggi. Il lato positivo è che è lungimirante. Puoi eseguire il deployment di nuovi carichi di lavoro in modo modernizzato, evitando (o almeno riducendo al minimo) i problemi legati alla migrazione dei carichi di lavoro esistenti.
Sebbene un approccio cloud-first possa offrire determinati vantaggi, potrebbe trasmettere potenziali opportunità di miglioramento o utilizzo dei carichi di lavoro esistenti. I nuovi carichi di lavoro potrebbero rappresentare una frazione del panorama IT complessivo e il loro effetto sulle spese e sulle prestazioni IT può essere limitato. L'allocazione di tempo e risorse alla migrazione di un carico di lavoro esistente potrebbe portare a vantaggi o risparmi sui costi più sostanziali rispetto a quando si tenta di accogliere un nuovo carico di lavoro nell'ambiente cloud.
Seguendo un rigoroso approccio cloud-first, rischi anche di aumentare la complessità generale del tuo ambiente IT. Questo approccio potrebbe creare ridondanze, prestazioni inferiori a causa di una potenziale comunicazione cross-environment eccessiva o portare a un ambiente di computing non adatto al singolo carico di lavoro. Inoltre, la conformità alle normative del settore e alle leggi sulla privacy dei dati può impedire alle aziende di eseguire la migrazione di determinate applicazioni che contengono dati sensibili.
Considerati questi rischi, potrebbe essere meglio utilizzare un approccio cloud-first solo per determinati carichi di lavoro. L'approccio cloud-first consente di concentrarsi sui carichi di lavoro che possono trarre vantaggio da un deployment o una migrazione cloud. Questo approccio considera anche la modernizzazione dei carichi di lavoro esistenti.
Un esempio comune di architettura ibrida cloud-first è quando le applicazioni e i servizi legacy che contengono dati critici devono essere integrati con nuovi dati o applicazioni. Per completare l'integrazione, puoi utilizzare un'architettura ibrida che modernizza i servizi legacy mediante le interfacce API, che li sbloccano per il consumo da parte di nuovi servizi e applicazioni cloud. Con una piattaforma di gestione delle API cloud, come Apigee, puoi implementare questi casi d'uso con modifiche minime alle applicazioni e aggiungere sicurezza, analisi e scalabilità ai servizi legacy.
Migrazione e modernizzazione
Il multi-cloud ibrido e la modernizzazione dell'IT sono concetti distinti collegati in un circolo virtuoso. Il cloud pubblico può facilitare e semplificare la modernizzazione dei carichi di lavoro IT. La modernizzazione dei carichi di lavoro IT può aiutarti a ottenere di più dal cloud.
Gli obiettivi principali della modernizzazione dei carichi di lavoro sono i seguenti:
- Ottieni una maggiore agilità per adattarti ai requisiti in continuo cambiamento.
- Riduci i costi dell'infrastruttura e delle operazioni.
- Aumenta l'affidabilità e la resilienza per ridurre al minimo i rischi.
Tuttavia, potrebbe non essere possibile modernizzare contemporaneamente ogni applicazione durante il processo di migrazione. Come descritto in Migrazione a Google Cloud, puoi implementare uno dei seguenti tipi di migrazione o anche combinare più tipi in base alle esigenze:
- Rehosting (lift and shift)
- Replatforming (lift and Optimize)
- Refactoring (spostamento e miglioramento)
- Riprogetta (continua per modernizzare)
- Ricrea (rimuovi e sostituisci, a volte chiamato ripresa e sostituisci)
- Riacquisto
Quando si prendono decisioni strategiche sulle architetture ibride e multi-cloud, è importante considerare la fattibilità della strategia dal punto di vista dei costi e dei tempi. L'approccio alla migrazione è graduale. Il passaggio successivo prevede il lift and shift o il replatforming e poi il refactoring o riprogettazione. In genere, il lift and shifting aiuta a ottimizzare le applicazioni dal punto di vista dell'infrastruttura. Quando le applicazioni sono in esecuzione nel cloud, è più facile utilizzare e integrare i servizi cloud per ottimizzarli ulteriormente mediante architetture e funzionalità cloud-first. Inoltre, queste applicazioni possono comunque comunicare con altri ambienti tramite una connessione di rete ibrida.
Ad esempio, è possibile eseguire il refactoring o la riprogettazione di una grande applicazione monolitica basata su VM e trasformarla in vari microservizi indipendenti, sulla base di un'architettura di microservizi basata su cloud. In questo esempio, l'architettura dei microservizi utilizza servizi per container gestiti di Google Cloud come Google Kubernetes Engine (GKE) o Cloud Run. Tuttavia, se l'architettura o l'infrastruttura di un'applicazione non è supportata nell'ambiente cloud di destinazione così com'è, potresti valutare di iniziare con il replatforming, il refactoring o la riprogettazione della strategia di migrazione per superare questi vincoli ove possibile.
Quando utilizzi uno di questi approcci alla migrazione, valuta la possibilità di modernizzare le tue applicazioni (ove applicabile e fattibile). La modernizzazione può richiedere l'adozione e l'implementazione dei principi di Site Reliability Engineering (SRE) o DevOps, tale che potrebbe essere necessario estendere la modernizzazione delle applicazioni al tuo ambiente privato in una configurazione ibrida. Anche se l'implementazione dei principi SRE coinvolge fondamentalmente la progettazione, è più un processo di trasformazione che una sfida tecnica. Di conseguenza, probabilmente richiedono cambiamenti procedurali e culturali. Per saperne di più su come il primo passo per implementare l'SRE in un'organizzazione sia ottenere il sostegno del team dirigenziale, consulta Con SRE, non pianificare correttamente.
Combina e abbina gli approcci alla migrazione
Ogni approccio alla migrazione qui discusso presenta determinati punti di forza e di debolezza. Un vantaggio chiave di seguire una strategia ibrida e multi-cloud è che non è necessario accontentarsi di un singolo approccio. Puoi invece decidere quale approccio funziona meglio per ogni carico di lavoro o stack di applicazioni, come mostrato nel diagramma seguente.
Questo diagramma concettuale illustra i vari percorsi o approcci di migrazione e modernizzazione che possono essere applicati contemporaneamente a diversi carichi di lavoro, guidati dagli unici requisiti aziendali, tecnici e obiettivi di ogni carico di lavoro o applicazione.
Inoltre, non è necessario che gli stessi componenti dello stack di applicazioni seguano lo stesso approccio o strategia di migrazione. Ad esempio:
- Il database on-premise backend di un'applicazione può essere sottoposto a replatforming da MySQL self-hosted a un database gestito utilizzando Cloud SQL in Google Cloud.
- È possibile eseguire il refactoring delle macchine virtuali frontend delle applicazioni per l'esecuzione su container utilizzando GKE Autopilot, dove Google gestisce la configurazione del cluster, inclusi nodi, scalabilità, sicurezza e altre impostazioni preconfigurate.
- La soluzione di bilanciamento del carico hardware on-premise e le funzionalità WAF firewall dell'applicazione web possono essere sostituite con Cloud Load Balancing e Google Cloud Armor.
Scegli rehosting (lift and shift), se per i carichi di lavoro si verifica una delle seguenti condizioni:
- e hanno un numero relativamente ridotto di dipendenze nell'ambiente.
- Non viene considerato la necessità di eseguire il refactoring, oppure il refactoring prima che la migrazione non sia fattibile.
- Si basano su software di terze parti.
Valuta la possibilità di eseguire il refactoring (spostamento e miglioramento) per questi tipi di carichi di lavoro:
- Hanno dipendenze che devono essere distribuite.
- Si basano su sistemi operativi, hardware o database che non possono essere inseriti nel cloud.
- Non utilizzano in modo efficiente le risorse di calcolo o archiviazione.
- e non possono essere implementate in modo automatizzato senza uno sforzo.
Valuta se la ricreazione (rimozione e sostituzione) soddisfa le tue esigenze per questi tipi di carichi di lavoro:
- Non soddisfano più i requisiti attuali.
- Possono essere incorporate con altre applicazioni che offrono funzionalità simili senza compromettere i requisiti aziendali.
- Si basano su tecnologie di terze parti che hanno raggiunto la fine del loro ciclo di vita.
- Richiedono tariffe per licenze di terze parti che non sono più economiche.
Il Rapid Migration Program mostra come Google Cloud aiuta i clienti a utilizzare le best practice, ridurre i rischi, controllare i costi e semplificare il percorso verso il successo nel cloud.