Questo documento mostra un'architettura che utilizza un mesh di servizi Istio per eseguire la migrazione da un ambiente legacy, come un data center on-premise che esegue applicazioni su macchine virtuali, a Google Kubernetes Engine (GKE). L'utilizzo di un mesh di servizi può ridurre la complessità della migrazione e del refactoring perché disaccoppia le funzioni di rete dalle funzioni di servizio.
Questo documento spiega le motivazioni della migrazione e ne delinea le fasi generali. Puoi utilizzare questa architettura per eseguire una migrazione in un'operazione (talvolta chiamata migrazione big-bang) o per eseguire una migrazione graduale funzionalità per funzionalità. Il relativo documento di deployment ti accompagna nella migrazione di esempio.
Questa architettura e la relativa guida al deployment sono destinate ai professionisti IT che gestiscono un'infrastruttura complessa di cui vogliono eseguire gradualmente la migrazione e la modernizzazione, riducendo al minimo i seguenti aspetti:
- Inattività
- Impegno di refactoring
- Complessità operativa della rete
I concetti illustrati si applicano a qualsiasi cloud, quindi il documento presuppone che tu conosca le tecnologie cloud, i container e i microservizi.
Come descritto in Migrazione a Google Cloud: inizia, esistono diversi pattern per la migrazione al cloud. L'architettura in questo documento utilizza un pattern di refactoring (a volte chiamato spostamento e miglioramento), in cui il pattern viene applicato a ciascuna funzionalità dell'applicazione, invece che all'applicazione nel suo insieme.
Durante la migrazione, l'applicazione ha un'architettura ibrida in cui alcune funzionalità sono disponibili in Google Cloud e altre ancora nell'ambiente legacy. Al termine della migrazione, l'applicazione completa viene ospitata su Google Cloud.
Architettura
Il seguente diagramma mostra come utilizzare un mesh di servizi per instradare il traffico ai microservizi in esecuzione nell'ambiente di origine o a Google Cloud:
L'architettura include i seguenti componenti:
Un ambiente di origine, in questo caso un'istanza Compute Engine che ospita il carico di lavoro di esempio di cui eseguire la migrazione. L'ambiente di origine può anche essere on-premise o ospitato in altre piattaforme cloud.
Un mesh di servizi, in questo caso il gateway Istio, che collega tra loro servizi diversi. Il mesh di servizi offre funzionalità di networking di alto valore, come Service Discovery, comunicazioni sicure, bilanciamento del carico, gestione del traffico e osservabilità.
Un'implementazione tipica di un mesh di servizi abbina ciascun servizio a un proxy che fornisce quelle funzionalità. Il proxy di servizio è spesso definito sidecar. Il ruolo del file collaterale consiste nell'aumentare e migliorare l'applicazione a cui è associato, spesso senza che questa ne sia a conoscenza. Nella guida al deployment fornita, utilizzerai Envoy come proxy sidecar.
Un carico di lavoro che contiene un'applicazione composta da microservizi. Un microservizio è un componente autonomo creato per accogliere una funzionalità dell'applicazione. In questa architettura, l'applicazione è composta da vari microservizi indistinguibili per gli utenti. Ad esempio, un componente che gestisce le recensioni dei libri è un microservizio.
Nel pattern dei microservizi, l'applicazione è l'aggregazione di più microservizi, ciascuno con un obiettivo specifico. Ad esempio, potresti avere un microservizio che gestisce le valutazioni dei libri e un altro che gestisce le recensioni dei libri. Questi microservizi dovrebbero essere a basso accoppiamento e interfacciarsi tra loro tramite API ben definite. Possono essere scritte in linguaggi e framework diversi (come nelle applicazioni poliglotta) e possono avere cicli di vita diversi.
Un container che serve a definire ulteriormente i confini di ogni microservizio. Poiché l'ambiente di destinazione in questa architettura è orchestrato con Kubernetes, ti consigliamo di containerizzare i microservizi utilizzando i seguenti strumenti:
- Docker è uno strumento per isolare i programmi a livello di spazio utente a livello di sistema operativo. Esegue pacchetti chiamati containers.
- Kubernetes è la soluzione di orchestrazione leader per i carichi di lavoro containerizzati. Offre funzionalità come Service Discovery, bilanciamento del carico, pod e nodi con riparazione automatica e gestione di secret e configurazioni.
- GKE è un ambiente Kubernetes gestito e pronto per la produzione, che fa parte di Google Cloud.
Per consigli su come containerizzare questi microservizi, consulta Best practice per la creazione dei container e Best practice per l'utilizzo dei container.
Per eseguire una migrazione utilizzando un mesh di servizi, completa le seguenti fasi:
- Valuta l'ambiente precedente: raccogli informazioni e stabilisci una serie di requisiti per l'ambiente di destinazione e una base di riferimento per i test e la convalida.
- Crea una base nell'ambiente di destinazione: esegui il provisioning dell'ambiente di destinazione e applica una metodologia Infrastructure as Code per rendere l'infrastruttura verificabile, ripetibile e di provisioning automatico.
- Esegui il deployment dei servizi e avvia il routing del traffico all'ambiente di destinazione: completa una singola operazione per eseguire il deployment di tutte le istanze di microservizi contemporaneamente oppure completa un deployment graduale per eseguire il deployment di un microservizio alla volta.
- Interrompi il routing del traffico all'ambiente precedente: configura le regole di routing per instradare il traffico solo ai servizi in esecuzione nell'ambiente di destinazione.
- Ritira l'ambiente legacy: aggiorna i record DNS in modo che rimandino al bilanciatore del carico che hai configurato durante la fase di provisioning dell'ambiente di destinazione.
Questo documento descrive alcune considerazioni di progettazione per questo tipo di migrazione e la relativa guida al deployment fornisce passaggi dettagliati per completare la migrazione.
Note sul layout
Questa sezione fornisce indicazioni per aiutarti a sviluppare un'architettura che soddisfi i tuoi requisiti specifici di affidabilità, efficienza operativa, costi e ottimizzazione delle prestazioni.
Affidabilità
Le seguenti sezioni descrivono le considerazioni relative all'affidabilità della migrazione.
Utilizza una strategia di migrazione graduale
Anche se questa architettura può essere utilizzata per una migrazione di una singola operazione, ti consigliamo di adottare una strategia di migrazione graduale. Eseguire una migrazione in un'operazione è difficile a causa delle sfide e dei rischi associati alla migrazione di una o più applicazioni contemporaneamente. Se hai limiti di tempo e budget, concentrarti su una migrazione per una singola operazione non lascia molta capacità per lavorare sulle nuove funzionalità dell'applicazione.
Al contrario, una migrazione graduale e funzione per funzionalità ha una complessità generale inferiore a causa delle dimensioni ridotte del carico di lavoro da migrare: una singola funzionalità ha un ingombro ridotto rispetto a un'intera applicazione. Una migrazione graduale consente di distribuire il rischio su eventi di migrazione più piccoli, anziché in un singolo esercizio ad alto rischio. Una migrazione graduale consente inoltre al team di migrazione di pianificare, progettare e sviluppare più strategie di migrazione per soddisfare diversi tipi di funzionalità.
Per indicazioni su come scegliere le funzionalità di cui eseguire prima la migrazione e su come eseguire la migrazione delle funzionalità stateful, consulta Scegliere le app di cui eseguire per prime la migrazione in "Eseguire la migrazione a Google Cloud: valutazione e rilevamento dei carichi di lavoro".
Utilizza una suite di test di conformità
Per facilitare la migrazione, ti consigliamo di utilizzare una suite di test di conformità. Una suite di test di conformità è un insieme di test che puoi eseguire su un ambiente per verificare se soddisfi un determinato insieme di requisiti. Se l'ambiente è valido, soddisfa i requisiti. Ad esempio, puoi convalidare la risposta a una richiesta di test o verificare se le dipendenze dell'applicazione sono installate.
Puoi iniziare con gli strumenti di monitoraggio, tracciamento e visualizzazione del mesh di servizi per una convalida manuale. Successivamente, puoi implementare la suite di test e svilupparla nel tempo nei seguenti modi:
- Test di carico: puoi far evolvere la suite di test inviando automaticamente il traffico di test all'ambiente e valutando i risultati.
- Strumento di test di conformità: puoi progettare e sviluppare una suite di test utilizzando uno strumento dedicato.
Esegui la suite di test di conformità rispetto all'ambiente legacy come base di riferimento e anche all'ambiente di destinazione durante e dopo la migrazione.
Le suite di test devono concentrarsi sui seguenti aspetti da convalidare durante la migrazione:
- Provisioning: esegui il provisioning delle risorse necessarie nel tuo ambiente prima di configurarle.
- Configurazione: dopo aver eseguito il provisioning delle risorse nell'ambiente, configurale in base alle esigenze dell'applicazione. Avere una suite di test di configurazione garantisce che l'ambiente sia pronto per ospitare la tua applicazione.
- Logica di business: dopo aver convalidato il provisioning e la configurazione dell'ambiente, convalida la logica di business della tua applicazione. Ad esempio, puoi convalidare le risposte alle richieste.
Chef InSpec, RSpec e Serverspec sono strumenti per sviluppare suite di test di conformità automatizzate. Funzionano su qualsiasi piattaforma e sono estensibili per consentirti di implementare i tuoi controlli, a partire dai controlli integrati.
Quando esegui il provisioning dell'ambiente di destinazione, puoi utilizzare la suite di test di conformità per convalidarlo. Potrebbe essere necessario aggiornare la suite di test per tenere conto delle eventuali differenze tra l'ambiente legacy e l'ambiente di destinazione, come la topologia dell'hardware e della rete. Tieni presente che stai passando da un ambiente on-premise, in cui hai il controllo completo, a un ambiente cloud pubblico, in cui solitamente non hai accesso completo all'intero stack.
Prima di instradare il traffico dal livello di bilanciamento del carico dell'ambiente legacy all'ambiente di destinazione, ti consigliamo di eseguire la suite di test di conformità della logica di business sui microservizi esposti dall'ambiente di destinazione. La suite di test può contribuire a garantire che i microservizi funzionino come previsto. Ad esempio, puoi convalidare le risposte restituite dai servizi esposti dal mesh di servizi. Puoi mantenere la route originale come opzione di backup nel caso in cui sia necessario eseguire il rollback delle modifiche e ripristinare l'ambiente precedente. Instradando una piccola parte del traffico di produzione a istanze dei microservizi in esecuzione nell'ambiente di destinazione, puoi creare fiducia nell'ambiente di destinazione e aumentare il traffico totale nel tempo.
Non consentire le richieste cross-environment
Durante la fase di test di conformità, ti consigliamo di perfezionare le regole di routing in modo da non consentire le richieste cross-environment, in modo che, quando la richiesta di un client raggiunge un ambiente, legacy o di destinazione, rimanga in quell'ambiente. Il divieto delle richieste cross-environment aiuta ad assicurare che i test convalidino correttamente l'ambiente di destinazione. Se non impedisci queste richieste, un test potrebbe riportare l'esito positivo nell'ambiente di origine anziché nell'ambiente di destinazione a tua insaputa.
Ritira l'ambiente legacy
Prima di ritirare l'ambiente legacy, verifica che tutte le seguenti condizioni siano vere:
- Nessun traffico viene instradato alle istanze dei microservizi in esecuzione nell'ambiente legacy.
- Nessun traffico proviene dalle interfacce dell'ambiente legacy.
- L'ambiente di destinazione è stato completamente convalidato.
Quando queste condizioni sono soddisfatte, puoi aggiornare i record DNS in modo che rimandino al bilanciatore del carico che hai configurato durante la fase di provisioning dell'ambiente di destinazione. Non ritirare l'ambiente legacy a meno che tu non abbia la certezza che l'ambiente di destinazione sia stato convalidato. Inoltre, non limitare la convalida alla sola logica di business, ma considera altri requisiti non funzionali come prestazioni e scalabilità.
Efficienza operativa
Le seguenti sezioni descrivono le considerazioni relative all'efficienza operativa della migrazione.
Valuta l'ambiente precedente
Prima di progettare o implementare un piano di migrazione, devi valutare l'ambiente legacy per raccogliere informazioni e stabilire una serie di requisiti per l'ambiente di destinazione e una base di riferimento per i test e la convalida. Per iniziare, devi creare un catalogo di tutte le funzionalità delle applicazioni di cui eseguire la migrazione. Per ogni funzionalità, dovresti essere in grado di rispondere a questa serie non esaustiva di domande:
- Quali sono l'ambiente di runtime e i requisiti per le prestazioni?
- Ci sono dipendenze da altre funzionalità?
- Questa funzionalità è fondamentale per l'attività?
- Questa funzionalità è stateless o stateful?
- Quanto è previsto il refactoring per eseguirne la migrazione?
- Questa funzionalità può consentire una finestra di migrazione completa?
Per ulteriori informazioni, consulta Eseguire la migrazione a Google Cloud: valutazione e rilevamento dei carichi di lavoro.
Risorse stateless e stateful
L'architettura utilizza un mesh di servizi perché disaccoppia le funzioni di servizio (come viene implementata la logica di business) dalle funzioni di rete (come e quando instradare il traffico alle funzioni di servizio). Nel deployment associato, utilizzi Istio come mesh di servizi.
Nell'ambiente legacy, la maggior parte delle chiamate ai servizi non riguarda la rete, perché avviene in una piattaforma monolitica. In un'architettura di microservizi, le comunicazioni tra i servizi avvengono su una rete e i servizi devono gestire questo modello diverso. Un mesh di servizi astrae le funzioni per gestire le comunicazioni di rete, eliminando la necessità di implementarle in ogni applicazione. Un mesh di servizi riduce anche la complessità operativa della rete poiché offre canali di comunicazione sicuri, bilanciamento del carico, funzionalità di gestione del traffico e osservabilità che non richiedono alcuna configurazione.
Con il deployment e la configurazione di un mesh di servizi, puoi instradare dinamicamente il traffico all'ambiente legacy o all'ambiente di destinazione. Per supportare la migrazione, non è necessario modificare la configurazione dell'applicazione perché la gestione del traffico è trasparente per i servizi del mesh.
Sebbene questo approccio funzioni bene per le funzionalità stateless, sono necessarie ulteriori pianificazioni e refactoring per migrare le funzionalità che sono stateful, sensibili alla latenza o altamente accoppiate con altre funzionalità:
- Stateful: quando esegui la migrazione delle funzionalità stateful, devi eseguire anche la migrazione dei dati per ridurre al minimo i tempi di inattività e mitigare i problemi di sincronizzazione e integrità durante la migrazione. Per saperne di più sulle strategie di migrazione dei dati, consulta la sezione Valutare gli approcci alla migrazione dei dati di "Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni".
- Sensibile alla latenza: se una funzionalità è sensibile alla latenza quando comunica con altre funzionalità, potrebbe essere necessario eseguire il deployment di componenti aggiuntivi durante il processo di migrazione. Per mitigare questa sensibilità, vengono solitamente utilizzati proxy che possono precaricare i dati o livelli di memorizzazione nella cache.
- Alto accoppiamento con altre funzionalità: se due o più funzionalità sono caratterizzate da un accoppiamento elevato, potrebbe essere necessario eseguirne la migrazione contemporaneamente. Sebbene questo approccio sia più semplice rispetto alla migrazione di un'intera applicazione, potrebbe risultare più difficile rispetto alla migrazione di una singola funzionalità.
Registra i servizi con il mesh di servizi
Poiché il tuo ambiente legacy non è direttamente integrato con il mesh di servizi, quando configuri la migrazione devi registrare manualmente tutti i servizi in esecuzione nell'ambiente legacy con il mesh di servizi. Se il tuo ambiente è già in esecuzione in Kubernetes, puoi automatizzare la registrazione utilizzando l'integrazione integrata con le API mesh di servizi.
Dopo aver registrato l'ambiente legacy, utilizzerai il mesh di servizi per esporre i microservizi in esecuzione nell'ambiente legacy. Puoi quindi instradare gradualmente il traffico ai microservizi dalle interfacce dell'ambiente legacy alle interfacce dell'ambiente di destinazione.
I client non vedranno alcuna interruzione del servizio perché accedono alle interfacce dei due ambienti tramite un livello di bilanciamento del carico. Il routing del traffico all'interno del mesh di servizi è trasparente per i client, pertanto i client non sapranno che la configurazione del routing è stata modificata.
Ottimizzazione dei costi
Questa architettura utilizza i seguenti componenti fatturabili di Google Cloud:
Quando esegui il deployment dell'architettura, puoi utilizzare il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.
Ottimizzazione delle prestazioni
In questa architettura, il traffico è quasi equamente suddiviso tra i servizi in esecuzione in Compute Engine e quelli in esecuzione in GKE. Il mesh di servizi bilancia il traffico tra le istanze di un servizio selezionato, indipendentemente dal fatto che siano in esecuzione nel cluster GKE o nelle istanze di Compute Engine. Se vuoi che tutto il traffico passi attraverso il mesh di servizi, devi riconfigurare i carichi di lavoro in esecuzione in Compute Engine in modo che puntino ai servizi nel mesh di servizi, anziché connetterti direttamente a questi servizi. Puoi configurare il criterio di bilanciamento del carico per le revisioni di ciascun servizio con la risorsa DestinationRule.
Deployment
Per eseguire il deployment di questa architettura, consulta Eseguire il deployment della migrazione con l'espansione del mesh Istio.
Passaggi successivi
- Scopri di più su GKE.
- Scopri di più su Istio.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.