Questo documento fornisce indicazioni su approcci e considerazioni comuni e comprovati per la migrazione del carico di lavoro al cloud. Si basa sulle indicazioni riportate in Progettare una strategia di architettura ibrida e multi-cloud, che illustra diversi 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 workload nel cloud pubblico, mentre i workload esistenti rimangono dove si trovano. In questo caso, valuta un deployment classico in un ambiente di computing privato solo se un deployment di cloud pubblico è impossibile per motivi tecnici o organizzativi.
La strategia cloud-first presenta vantaggi e svantaggi. Il lato positivo è che è orientato al futuro. Puoi eseguire il deployment di nuovi carichi di lavoro in modo modernizzato, evitando (o almeno riducendo al minimo) i problemi della migrazione dei carichi di lavoro esistenti.
Sebbene un approccio cloud-first possa offrire alcuni vantaggi, potrebbe potenzialmente comportare la perdita di opportunità per migliorare o utilizzare i carichi di lavoro esistenti. I nuovi carichi di lavoro potrebbero rappresentare una frazione del panorama IT complessivo e il loro effetto sulle spese e sul rendimento IT può essere limitato. L'allocazione di tempo e risorse per la migrazione di un carico di lavoro esistente potrebbe potenzialmente portare a vantaggi o risparmi sui costi più sostanziali rispetto al tentativo di ospitare un nuovo carico di lavoro nell'ambiente cloud.
Seguire un approccio cloud-first rigoroso rischia anche di aumentare la complessità complessiva dell'ambiente IT. Questo approccio potrebbe creare ridondanze, ridurre le prestazioni a causa di una potenziale comunicazione eccessiva tra gli ambienti o risultare in un ambiente di computing non adatto al singolo carico di lavoro. Inoltre, la conformità alle normative di settore e alle leggi sulla privacy dei dati può impedire alle aziende di eseguire la migrazione di determinate applicazioni che contengono dati sensibili.
Considerando questi rischi, potrebbe essere più opportuno utilizzare un approccio cloud-first solo per i workload selezionati. L'utilizzo di un approccio cloud-first ti consente di concentrarti sui carichi di lavoro che possono trarre il massimo vantaggio da un deployment o una migrazione nel cloud. Questo approccio prende in considerazione anche la modernizzazione dei carichi di lavoro esistenti.
Un esempio comune di architettura ibrida cloud-first si verifica quando applicazioni e 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 utilizzando interfacce API, che li sbloccano per l'utilizzo 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 all'applicazione 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. L'utilizzo del cloud pubblico può facilitare e semplificare la modernizzazione dei workload IT. La modernizzazione dei carichi di lavoro IT può aiutarti a ottenere di più dal cloud.
Gli obiettivi principali della modernizzazione dei workload sono i seguenti:
- Aumenta l'agilità per adattarti ai requisiti in evoluzione.
- Ridurre i costi dell'infrastruttura e delle operazioni.
- Aumenta l'affidabilità e la resilienza per ridurre al minimo il rischio.
Tuttavia, potrebbe non essere fattibile modernizzare ogni applicazione nel processo di migrazione contemporaneamente. 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 (trasferisci e ottimizza)
- Refactoring (sposta e migliora)
- Riprogettazione dell'architettura (continua a modernizzare)
- Ricostruzione (rimozione e sostituzione, a volte chiamata elimina e sostituisci)
- Riacquisto
Quando prendi decisioni strategiche in merito alle architetture ibride e multicloud, è importante considerare la fattibilità della tua strategia dal punto di vista di costi e tempi. Potresti prendere in considerazione un approccio di migrazione graduale, iniziando con il lift and shift o il replatforming e poi il refactoring o la riprogettazione come passaggio successivo. In genere, il lift and shift consente di ottimizzare le applicazioni dal punto di vista dell'infrastruttura. Una volta che le applicazioni vengono eseguite nel cloud, è più facile utilizzare e integrare i servizi cloud per ottimizzarle ulteriormente utilizzando architetture e funzionalità cloud-first. Inoltre, queste applicazioni possono comunque comunicare con altri ambienti tramite una connessione di rete ibrida.
Ad esempio, puoi eseguire il refactoring o la riprogettazione dell'architettura di un'applicazione di grandi dimensioni basata su VM monolitiche e trasformarla in diversi microservizi indipendenti, in base a un'architettura di microservizi basata sul cloud. In questo esempio, l'architettura dei microservizi utilizza Google Cloud servizi container gestiti come Google Kubernetes Engine (GKE) o Cloud Run. Tuttavia, se l'architettura o l'infrastruttura di un'applicazione non sono supportate nell'ambiente cloud di destinazione così com'è, potresti prendere in considerazione l'idea 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 di migrazione, valuta la possibilità di modernizzare le tue applicazioni (se applicabile e fattibile). La modernizzazione può richiedere l'adozione e l'implementazione dei principi di Site Reliability Engineering (SRE) o DevOps, pertanto potrebbe essere necessario estendere la modernizzazione dell'applicazione al tuo ambiente privato in una configurazione ibrida. Anche se l'implementazione dei principi SRE comporta un lavoro di ingegneria, si tratta più di un processo di trasformazione che di una sfida tecnica. Pertanto, è probabile che richiederà modifiche procedurali e culturali. Per scoprire di più su come il primo passo per implementare SRE in un'organizzazione sia ottenere l'approvazione della leadership, consulta Con SRE, non pianificare significa pianificare il fallimento.
Combinare gli approcci di migrazione
Ogni approccio di migrazione descritto qui presenta determinati punti di forza e di debolezza. Un vantaggio fondamentale di seguire una strategia ibrida e multi-cloud è che non è necessario optare per un unico approccio. Puoi invece decidere quale approccio funziona meglio per ogni carico di lavoro o stack di applicazioni, come mostrato nel seguente diagramma.
Questo diagramma concettuale illustra i vari percorsi o approcci di migrazione e modernizzazione che possono essere applicati simultaneamente a diversi carichi di lavoro, in base ai requisiti e agli obiettivi tecnici e commerciali unici di ciascun 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 di backend di un'applicazione può essere ripiattaformato da MySQL autogestito a un database gestito utilizzando Cloud SQL in Google Cloud.
- Le macchine virtuali frontend dell'applicazione possono essere sottoposte a refactoring per essere eseguite 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 (web application firewall) possono essere sostituite da Cloud Load Balancing e Google Cloud Armor.
Scegli il rehosting (lift and shift) se una delle seguenti condizioni è vera per i workload:
- Hanno un numero relativamente ridotto di dipendenze dal loro ambiente.
- Non sono considerati degni di refactoring o il refactoring prima della migrazione non è fattibile.
- Si basano su software di terze parti.
Valuta il refactoring (spostamento e miglioramento) per questi tipi di workload:
- Hanno dipendenze che devono essere risolte.
- Si basano su sistemi operativi, hardware o database che non possono essere ospitati nel cloud.
- Non utilizzano in modo efficiente le risorse di calcolo o di archiviazione.
- Non possono essere implementati in modo automatico senza un certo impegno.
Valuta se la ricompilazione (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 forniscono funzionalità simili senza compromettere i requisiti aziendali.
- Si basano su una tecnologia di terze parti che ha raggiunto la fine del ciclo di vita.
- Richiedono costi di licenza di terze parti che non sono più economici.
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.