Il presente documento fornisce una guida alle informazioni approcci comprovati e considerazioni per la migrazione del carico di lavoro nel cloud. it si estende alle linee guida 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 sul cloud pubblico e i carichi di lavoro esistenti rimangono dove si trovano. In tal caso, prendi in considerazione 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, potrebbero comportare la perdita di opportunità di miglioramento o di utilizzo delle risorse esistenti. carichi di lavoro con scale out impegnativi. 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.
Seguendo un rigoroso approccio cloud-first rischi anche di aumentare la copertura complessità 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 del settore e alle leggi sulla privacy dei dati può impedisce alle aziende di eseguire la migrazione di determinate applicazioni che contengono dati sensibili e i dati di Google Cloud.
Se consideriamo questi rischi, potrebbe essere meglio utilizzare un approccio cloud-first solo per determinati carichi di lavoro. L'utilizzo di un approccio cloud-first consente di concentrarsi sui carichi di lavoro che possono trarre il massimo 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 contenenti dati critici devono essere integrati con i nuovi dati o applicazioni. Per completare l'integrazione, puoi utilizzare un modello che modernizza i servizi legacy utilizzando interfacce API, che ne sbloccano l'utilizzo da parte di nuovi servizi e applicazioni cloud. Con una nuvola piattaforma di gestione delle API, Mi piace 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 tra loro un circolo virtuoso. L'uso del cloud pubblico può facilitare 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 dell'infrastruttura e delle operazioni.
- Aumenta l'affidabilità e la resilienza per ridurre al minimo i rischi.
Tuttavia, potrebbe non essere possibile modernizzare ogni applicazione 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 (lift and Optimize)
- Refactoring (spostamento e miglioramento)
- Riprogetta (continua per modernizzare)
- Ricrea (rimuovi e sostituisci, a volte chiamato ripresa e sostituisci)
- Riacquisto
Quando prendi decisioni strategiche sulle tue architetture ibride e multi-cloud, è importante considerare la fattibilità della strategia in base ai costi e al tempo punto di vista. 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. Quando le applicazioni sono in esecuzione nel cloud, e integrare i servizi cloud per ottimizzarli ulteriormente utilizzando architetture e funzionalità cloud-first. Inoltre, queste applicazioni possono possono comunicare con altri ambienti tramite una connessione di rete ibrida.
Ad esempio, puoi eseguire il refactoring o la riprogettazione dell'architettura di una grande piattaforma monolitica basata su VM e trasformarla in vari microservizi indipendenti, sulla base di basata su cloud. In questo esempio, i microservizi utilizza 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 alla migrazione, valuta la possibilità di modernizzare delle applicazioni (ove applicabile e fattibile). La modernizzazione può richiedere l'adozione di e implementazione SRE (Site Reliability Engineering) o DevOps, in modo che tu possa avere bisogno anche di estendere la modernizzazione al tuo ambiente privato con una configurazione ibrida. Anche se l'implementazione dei principi SRE coinvolge l'ingegneria al centro, è più un processo di trasformazione piuttosto che una sfida tecnica. Di conseguenza, è probabile che richiedono cambiamenti procedurali e culturali. Per scoprire di più su come eseguire il primo passaggio, all'implementazione dell'SRE in un'organizzazione è ottenere il sostegno del team direttivo, vedi Con SRE, mancare di pianificare può fallire.
Combina e abbina gli approcci alla migrazione
Ogni approccio alla migrazione qui discusso 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 però decidere quale approccio funziona meglio per ogni carico di lavoro o stack di applicazioni, come illustrato di seguito in questo 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.
- È possibile eseguire il refactoring delle macchine virtuali frontend delle applicazioni dei container 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:
- e hanno un numero relativamente ridotto di dipendenze nell'ambiente.
- Non viene considerato la necessità di eseguire il refactoring o refactoring prima perché non è possibile eseguire la migrazione.
- 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 integrati 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 ricompilazione (rimuovi e sostituisci) 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 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.
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.