Questo documento fornisce indicazioni su approcci e considerazioni comuni e comprovati per eseguire la migrazione del tuo carico di lavoro nel cloud. Espande le indicazioni riportate in Creare 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. In questo approccio, esegui il deployment dei nuovi carichi di lavoro nel cloud pubblico, mentre i carichi di lavoro esistenti rimangono invariati. In tal caso, considera un modello in un ambiente di computing privato solo nel caso in cui 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 potenzialmente comportare opportunità perse 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 sulle prestazioni IT potrebbe essere limitato. Allocazione del tempo e risorse per la migrazione di un carico di lavoro esistente potrebbero comportare vantaggi sostanziali o risparmi sui costi rispetto al tentativo di accogliere un nuovo carico di lavoro nell'ambiente cloud.
Inoltre, seguire un approccio cloud-first rigoroso rischia di aumentare la complessità complessiva del tuo ambiente IT. Questo approccio può creare ridondanze, Prestazioni inferiori a causa di una potenziale comunicazione cross-environment eccessiva oppure creano un ambiente di elaborazione non adatto al singolo carico di lavoro. Inoltre, la conformità alle normative di settore e alle leggi sulla privacy dei dati può limitare le aziende nella migrazione di determinate applicazioni che contengono dati sensibili.
Tenendo conto di questi rischi, ti consigliamo di utilizzare un approccio cloud-first solo per carichi di lavoro 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 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 utilizzando interfacce API, che li sblocca 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 all'applicazione e aggiungere sicurezza, analisi e scalabilità ai servizi legacy.
Migrazione e modernizzazione
Il multicloud ibrido e la modernizzazione IT sono concetti distinti collegati in un circolo virtuoso. L'utilizzo del cloud pubblico può agevolare e semplificare la modernizzazione dei carichi di lavoro IT. La modernizzazione dei carichi di lavoro IT può aiutarti sfruttare al meglio il 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 di infrastruttura e operazioni.
- Aumenta l'affidabilità e la resilienza per ridurre al minimo i rischi.
Tuttavia, potrebbe non essere possibile modernizzare contemporaneamente tutte le applicazioni nel processo di migrazione. Come descritto nella sezione Migrazione a Google Cloud, puoi implementare uno dei seguenti tipi di migrazione, o anche combinare più tipi a seconda delle esigenze:
- Rehosting (lift and shift)
- Replatforming (trasferimento e ottimizzazione)
- Refactoring (spostare e migliorare)
- Riprogettazione dell'architettura (continua a modernizzare)
- Ricrea (rimuovi e sostituisci, a volte chiamato rip e sostituisci)
- Riacquista
Quando prendi decisioni strategiche sulle tue architetture ibride e multicloud, è importante considerare la fattibilità della tua strategia dal punto di vista dei costi e dei tempi. Potremmo prendere in considerazione un approccio alla migrazione graduale, con lift and shifting, replatforming e poi refactoring e riprogettare l'architettura come prossimo passo. In genere, il sollevamento pesi ottimizzare le applicazioni dell'infrastruttura. Una volta che le applicazioni sono in esecuzione nel cloud, è più facile utilizzare e integrare i servizi cloud per ottimizzarli 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 di un'applicazione monolitica di grandi dimensioni basata su VM e trasformarla in diversi microservizi indipendenti, in base a un'architettura di microservizi basata su cloud. In questo esempio, i microservizi Transformer utilizza i servizi per container gestiti di Google Cloud, 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 replatforming, refactoring o riprogettazione della strategia di migrazione 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 di principi di Site Reliability Engineering (SRE) o DevOps, pertanto potrebbe essere necessario estendere la modernizzazione delle applicazioni al tuo ambiente privato in una configurazione ibrida. Anche se l'implementazione dei principi SRE prevede l'ingegneria come elemento fondamentale, si tratta più di un processo di trasformazione che di una sfida tecnica. Di conseguenza, è probabile che richieda modifiche procedurali e culturali. Per scoprire di più su come il primo passo per implementare SRE in un'organizzazione sia ottenere l'approvazione del management, consulta Con SRE, non pianificare significa pianificare un fallimento.
Combina e abbina gli approcci alla migrazione
Ogni approccio alla migrazione discusso qui presenta determinati punti di forza e di debolezza. R il vantaggio chiave di seguire una strategia ibrida e multi-cloud è che non necessarie per stabilirsi su un unico approccio. Puoi invece decidere quale approccio è più adatto per ogni carico di lavoro o stack di applicazioni, come mostrato nel seguente diagramma.
Questo diagramma concettuale illustra le varie migrazioni e modernizzazione o approcci applicabili a diversi carichi di lavoro contemporaneamente, basati sugli unici requisiti aziendali, tecnici e obiettivi di ogni carico di lavoro o applicazione.
Inoltre, non è necessario che gli stessi componenti dello stack di applicazioni seguono lo stesso approccio o strategia per la migrazione. Ad esempio:
- È possibile cambiare la piattaforma con il database on-premise di backend di un'applicazione da MySQL self-hosted 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 contenitori utilizzando GKE Autopilot, in cui Google gestisce la configurazione del cluster, inclusi nodi, scalabilità, sicurezza e altre impostazioni preconfigurate.
- Applicazione web e soluzione di bilanciamento del carico dell'hardware on-premise le funzionalità WAF firewall possono essere sostituite Cloud Load Balancing e Google Cloud Armor.
Scegli il rehosting (lift and shift), se una delle seguenti condizioni è vera in relazione alla carichi di lavoro standard:
- Hanno un numero relativamente ridotto di dipendenze dal loro ambiente.
- Non sono considerati meritevoli di refactoring o il refactoring prima della migrazione non è 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 slegate.
- Si basano su sistemi operativi, hardware o database che non possono essere supportati 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 (rimuovi e sostituisci) soddisfa le tue esigenze per questi tipi di carichi di lavoro:
- Non soddisfano più i requisiti attuali.
- Possono essere incorporate in 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 suo ciclo di vita.
- Richiedono tariffe per licenze di terze parti che non sono più economiche.
La Programma di migrazione rapida mostra come Google Cloud aiuta i clienti a utilizzare best practice, controllare i costi e semplificare il percorso verso il successo nel cloud.