Crea architetture ibride e multi-cloud utilizzando Google Cloud

Last reviewed 2024-11-27 UTC

Questa guida all'architettura fornisce indicazioni pratiche per la pianificazione e la progettazione degli ambienti ibridi e multi-cloud utilizzando Google Cloud. Questo documento è il primo di tre documenti del set. Esamina le opportunità e le considerazioni associate a queste architetture dal punto di vista aziendale e tecnologico. Inoltre, analizza e descrive molti modelli di architettura ibrida e multi-cloud collaudati.

Il set di documenti per i modelli di architettura ibrida e multi-cloud è composto da queste parti:

Puoi leggere ciascuno di questi articoli sull'architettura in modo indipendente, ma per ottenere il massimo vantaggio, ti consigliamo di leggerli in sequenza prima di prendere una decisione sull'architettura.

Il rapido ritmo di cambiamento delle richieste del mercato ha aumentato i requisiti e le aspettative dell'IT aziendale, come la scalabilità dinamica, le prestazioni migliorate per un'esperienza utente ottimizzata e la sicurezza. Molte aziende di livello enterprise trovano difficile soddisfare queste richieste ed aspettative utilizzando solo infrastrutture e processi tradizionali. Anche i reparti IT sono sotto pressione per migliorare il rapporto costi/efficacia, il che rende difficile giustificare ulteriori investimenti di capitale in data center e attrezzature.

Una strategia di cloud ibrido che utilizza le funzionalità di cloud computing pubblico fornisce una soluzione pragmatica. Utilizzando il cloud pubblico, puoi estendere la capacità e le funzionalità delle tue piattaforme di computing senza costi di investimento di capitale iniziali.

Se aggiungi una o più soluzioni basate sul cloud pubblico, come Google Cloud, alla tua infrastruttura esistente, non solo preservi gli investimenti esistenti, ma eviti anche di vincolarti a un unico fornitore di servizi cloud. Inoltre, utilizzando una strategia ibrida, puoi modernizzare applicazioni e processi in modo incrementale man mano che le risorse lo consentono.

Per aiutarti a pianificare la tua decisione architettonica e la strategia ibrida o multicloud, ci sono diverse potenziali sfide e considerazioni di progettazione da tenere in considerazione. Questa guida all'architettura in più parti mette in evidenza sia i potenziali vantaggi delle varie architetture sia le potenziali sfide.

Panoramica del cloud ibrido e multi-cloud

Poiché i carichi di lavoro, l'infrastruttura e i processi sono unici per ogni azienda, ogni strategia di cloud ibrido deve essere adattata alle tue esigenze specifiche. Il risultato è che i termini cloud ibrido e multi-cloud vengono a volte utilizzati in modo incoerente.

Nel contesto di questa guida all'architettura, il termine cloud ibrido descrive un'architettura in cui i carichi di lavoro vengono implementati in più ambienti di computing, di cui uno basato sul cloud pubblico e almeno uno privato, ad esempio un data center on-premise o una struttura di colocation. Google Cloud

Il termine multicloud descrive un'architettura che combina almeno due CSP pubblici. Come illustrato nel seguente diagramma, a volte questa architettura include un ambiente di calcolo privato (che potrebbe includere l'utilizzo di un componente cloud privato). Questo assetto è chiamato architettura ibrida e multi-cloud.

Diagramma delle tre architetture descritte in questa serie: ibrida, multi-cloud e un mix di architetture ibride e multi-cloud.

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

Motivazioni, considerazioni, strategia e approcci

Questo documento definisce e descrive gli obiettivi, i fattori e i requisiti aziendali e il modo in cui questi fattori possono influenzare le decisioni di progettazione durante la creazione di architetture ibride e multi-cloud.

Obiettivi

Un'organizzazione può adottare un'architettura ibrida o multi-cloud come soluzione permanente per raggiungere obiettivi aziendali specifici o come stato temporaneo per soddisfare determinati requisiti, ad esempio una migrazione al cloud.

Rispondere alle seguenti domande sulla tua attività è un buon modo per definire i requisiti aziendali e stabilire aspettative specifiche su come raggiungere alcuni o tutti i tuoi obiettivi commerciali. Queste domande si concentrano su ciò che è necessario per la tua attività, non su come ottenerlo tecnicamente.

  • Quali obiettivi aziendali guidano la decisione di adottare un'architettura ibrida o multicloud?
  • Quali obiettivi aziendali e tecnici aiuterà a raggiungere un'architettura ibrida o multicloud?
  • Quali fattori aziendali hanno influenzato questi obiettivi?
  • Quali sono i requisiti aziendali specifici?

Nel contesto delle architetture ibride e multicloud, un obiettivo aziendale per un cliente enterprise potrebbe essere quello di espandere le operazioni o i mercati di vendita online da una singola regione per diventare uno dei leader globali nel proprio segmento di mercato. Uno degli obiettivi aziendali potrebbe essere quello di iniziare ad accettare ordini di acquisto da utenti di tutto il mondo (o di regioni specifiche) entro sei mesi.

Per supportare i requisiti e gli obiettivi aziendali menzionati in precedenza, uno dei potenziali obiettivi tecnici principali è espandere l'infrastruttura IT e l'architettura delle applicazioni di un'azienda da un modello solo on-premise a un'architettura ibrida, utilizzando le funzionalità e i servizi globali dei cloud pubblici. Questo obiettivo deve essere specifico e misurabile, definendo chiaramente l'ambito di espansione in termini di regioni target e tempistiche.

In generale, un'architettura ibrida o multicloud è raramente un obiettivo in sé, ma piuttosto un mezzo per raggiungere obiettivi tecnici guidati da determinati requisiti aziendali. Pertanto, la scelta dell'architettura ibrida o multicloud giusta richiede innanzitutto di chiarire questi requisiti.

È importante distinguere tra gli obiettivi aziendali e quelli tecnici del tuo progetto IT. Gli obiettivi aziendali devono concentrarsi sullo scopo e sulla missione della tua organizzazione. Gli obiettivi tecnici devono concentrarsi sulla creazione di una base tecnologica che consenta alla tua organizzazione di soddisfare i requisiti e gli obiettivi aziendali.

I fattori aziendali influenzano il raggiungimento dell'obiettivo e degli scopi aziendali. Pertanto, identificare chiaramente i fattori aziendali può contribuire a definire gli obiettivi o gli scopi aziendali in modo che siano più pertinenti alle esigenze e alle tendenze del mercato.

Il seguente diagramma di flusso illustra i fattori, gli scopi, gli obiettivi e i requisiti aziendali, nonché gli obiettivi e i requisiti tecnici e il modo in cui tutti questi fattori sono correlati tra loro:

Diagramma di flusso che mostra gli aspetti da considerare durante lo sviluppo dei requisiti tecnici, tra cui fattori, scopi, obiettivi e requisiti aziendali, nonché obiettivi tecnici.

Fattori aziendali e tecnici

Valuta in che modo i fattori che guidano la tua attività influenzano i tuoi obiettivi tecnici. Alcuni fattori aziendali comuni e influenti nella scelta di un'architettura ibrida includono quanto segue:

  • Rispetto delle leggi e dei regolamenti sulla sovranità dei dati.
  • Riduzione delle spese in conto capitale (CAPEX) o delle spese IT generali con il supporto della gestione finanziaria del cloud e delle discipline di ottimizzazione dei costi come FinOps.
    • L'adozione del cloud può essere determinata da scenari che contribuiscono a ridurre le spese in conto capitale, ad esempio la creazione di una soluzione di ripristino di emergenza in un'architettura ibrida o multi-cloud.
  • Migliorare l'esperienza utente.
  • Aumentare la flessibilità e l'agilità per rispondere alle mutevoli richieste del mercato.
  • Migliorare la trasparenza in merito ai costi e al consumo di risorse.

Considera insieme l'elenco dei fattori aziendali per l'adozione di un'architettura ibrida o multi-cloud. Non considerarli isolatamente. La decisione finale deve dipendere dall'equilibrio delle priorità della tua attività.

Dopo che la tua organizzazione si è resa conto dei vantaggi del cloud, potrebbe decidere di eseguire la migrazione completa se non ci sono vincoli, come costi o requisiti di conformità specifici che richiedono l'hosting in locale di dati altamente sicuri.

Sebbene l'adozione di un singolo fornitore di servizi cloud possa offrire diversi vantaggi, come la riduzione della complessità, le integrazioni integrate tra i servizi e le opzioni di ottimizzazione dei costi come gli sconti per utilizzo di cui è stato eseguito il commit, esistono ancora alcuni scenari in cui un'architettura multicloud può essere vantaggiosa per un'azienda. Di seguito sono riportati i fattori aziendali comuni per l'adozione di un'architettura multicloud, insieme alle considerazioni associate per ciascun fattore:

  • Rispetto di leggi e normative sulla sovranità dei dati: lo scenario più comune si verifica quando un'organizzazione espande la propria attività in una nuova regione o paese e deve rispettare nuove normative sull'hosting dei dati.
    • Se il CSP utilizzato non dispone di una regione cloud locale nel paese, la soluzione comune per la conformità è utilizzare un altro CSP che disponga di una regione cloud locale nel paese.
  • Riduzione dei costi: la riduzione dei costi è spesso il fattore aziendale più comune per l'adozione di una tecnologia o un'architettura. Tuttavia, è importante considerare non solo il costo dei servizi e i potenziali sconti sui prezzi quando decidi se adottare un'architettura multicloud. Tieni conto del costo di creazione e gestione di una soluzione su più cloud e di eventuali vincoli dell'architettura derivanti dai sistemi esistenti.

A volte, le potenziali sfide associate a una strategia multicloud potrebbero superare i vantaggi. Una strategia multi-cloud potrebbe comportare costi aggiuntivi in un secondo momento.

Le sfide più comuni associate allo sviluppo di una strategia multicloud includono:

  • Complessità crescente della gestione.
  • Mantenere una sicurezza coerente.
  • Integrazione degli ambienti software.
  • Garantire prestazioni e affidabilità coerenti tra i cloud.
  • La creazione di un team tecnico con competenze multicloud potrebbe essere costosa e potrebbe richiedere l'espansione del team, a meno che non sia gestita da un'azienda di terze parti.
  • Gestione degli strumenti di gestione e dei prezzi dei prodotti di ciascun CSP.
  • Utilizzo delle funzionalità uniche di ogni CSP: un'architettura multicloud consente alle organizzazioni di utilizzare nuove tecnologie aggiuntive per migliorare le proprie offerte di funzionalità aziendali senza essere limitate alle scelte offerte da un singolo cloud provider.
    • Per evitare rischi o complessità imprevisti, valuta le tue potenziali sfide attraverso una valutazione di fattibilità ed efficacia, comprese le sfide comuni menzionate in precedenza.
  • Evitare i vincoli al vendor: a volte, le aziende vogliono evitare di essere vincolate a un unico fornitore di servizi cloud. Un approccio multi-cloud consente loro di scegliere la soluzione migliore per le loro esigenze aziendali. Tuttavia, la fattibilità di questa decisione dipende da diversi fattori, tra cui:
    • Dipendenze tecniche
    • Considerazioni sull'interoperabilità tra applicazioni
    • Costi di ricompilazione o refactoring delle applicazioni
    • Competenze tecniche
    • Sicurezza e gestibilità coerenti
  • Miglioramento del livello di affidabilità e disponibilità delle applicazioni business critical: in alcuni scenari, un'architettura multi-cloud può fornire resilienza alle interruzioni. Ad esempio, se una regione di un CSP non funziona, il traffico può essere indirizzato a un altro CSP nella stessa regione. Questo scenario presuppone che entrambi i provider cloud supportino le funzionalità o i servizi richiesti in quella regione.

Quando le normative sulla residenza dei dati in un paese o in una regione specifici impongono l'archiviazione di dati sensibili, come le informazioni che consentono l'identificazione personale (PII), all'interno di quella località, un approccio multicloud può fornire una soluzione conforme. Utilizzando due CSP in una regione per garantire la resilienza alle interruzioni, puoi facilitare la conformità alle restrizioni normative e soddisfare i requisiti di disponibilità.

Di seguito sono riportate alcune considerazioni sulla resilienza da valutare prima di adottare un'architettura multicloud:

  • Spostamento dei dati: con quale frequenza i dati potrebbero essere spostati all'interno del tuo ambiente multicloud?
    • Lo spostamento dei dati potrebbe comportare costi di trasferimento elevati?
  • Sicurezza e gestibilità: esistono potenziali complessità di sicurezza o gestibilità?
  • Parità di funzionalità: entrambi i CSP nella regione selezionata offrono le funzionalità e i servizi richiesti?
  • Competenze tecniche: il team tecnico ha le competenze necessarie per gestire un'architettura multi-cloud?

Prendi in considerazione tutti questi fattori quando valuti la fattibilità dell'utilizzo di un'architettura multicloud per migliorare la resilienza.

Quando valuti la fattibilità di un'architettura multicloud, è importante considerare i vantaggi a lungo termine. Ad esempio, il deployment di applicazioni su più cloud per il ripristino di emergenza o l'aumento dell'affidabilità potrebbe far lievitare i costi nel breve termine, ma potrebbe impedire interruzioni o errori. Questi errori possono causare danni finanziari e reputazionali a lungo termine. Pertanto, è importante valutare i costi a breve termine rispetto al potenziale valore a lungo termine dell'adozione del multi-cloud. Inoltre, il potenziale valore a lungo termine può variare in base alle dimensioni dell'organizzazione, alla scala tecnologica, alla criticità della soluzione tecnologica e al settore.

Le organizzazioni che prevedono di creare un ambiente ibrido o multicloud dovrebbero prendere in considerazione la creazione di un Cloud Center of Excellence (COE). Un team del COE può diventare il canale per trasformare il modo in cui i team interni della tua organizzazione servono l'attività durante la transizione al cloud. Un COE è uno dei modi in cui la tua organizzazione può adottare il cloud più rapidamente, promuovere la standardizzazione e mantenere un allineamento più forte tra la strategia aziendale e gli investimenti nel cloud.

Se l'obiettivo dell'architettura ibrida o multi-cloud è creare uno stato temporaneo, i fattori aziendali comuni includono:

  • La necessità di ridurre le spese di capitale o le spese IT generali per progetti a breve termine.
  • La possibilità di eseguire il provisioning di questa infrastruttura rapidamente per supportare un caso d'uso aziendale. Ad esempio:
    • Questa architettura può essere utilizzata per progetti a tempo limitato. Potrebbe essere utilizzato per supportare un progetto che richiede un'infrastruttura distribuita su larga scala per un periodo di tempo limitato, utilizzando comunque i dati on-premise.
  • La necessità di progetti di trasformazione digitale pluriennali che richiedono a una grande impresa di stabilire e utilizzare un'architettura ibrida per un certo periodo di tempo per aiutarla ad allineare la modernizzazione di infrastrutture e applicazioni alle priorità aziendali.
  • La necessità di creare un'architettura ibrida, multi-cloud o mista temporanea dopo una fusione aziendale. In questo modo, la nuova organizzazione può definire una strategia per lo stato finale della sua nuova architettura cloud. È comune che due aziende che si fondono utilizzino provider cloud diversi o che una utilizzi un data center privato on-premise e l'altra il cloud. In entrambi i casi, il primo passo di una fusione e acquisizione è quasi sempre l'integrazione dei sistemi IT.

Fattori tecnici

La sezione precedente ha trattato i fattori di crescita. Per ottenere l'approvazione, le principali decisioni architetturali hanno quasi sempre bisogno del supporto di questi driver. Tuttavia, anche i fattori tecnici, che possono basarsi su un guadagno tecnico o su un vincolo, possono influenzare i fattori aziendali. In alcuni scenari, è necessario tradurre i fattori tecnici in fattori aziendali e spiegare in che modo potrebbero influire positivamente o negativamente sull'attività.

Il seguente elenco non esaustivo contiene alcuni fattori tecnici comuni per l'adozione di un'architettura ibrida o multicloud:

  • Sviluppare funzionalità tecnologiche, come servizi di analisi avanzata e AI, che potrebbero essere difficili da implementare negli ambienti esistenti.
  • Migliorare la qualità e le prestazioni del servizio.
  • Automatizzare e accelerare i rollout delle applicazioni per ottenere un time to market più rapido e cicli più brevi.
  • Utilizzo di API e servizi di alto livello per accelerare lo sviluppo.
  • Accelerare il provisioning delle risorse di computing e archiviazione.
  • Utilizzo di servizi serverless per creare servizi e funzionalità elastici più rapidamente e su larga scala.
  • Utilizzo delle funzionalità dell'infrastruttura globale per creare architetture globali o multiregionali per soddisfare determinati requisiti tecnici.

Il driver tecnico più comune per le architetture ibride e multicloud temporanee è quello di facilitare la migrazione da on-premise al cloud o a un cloud aggiuntivo. In generale, le migrazioni al cloud portano quasi sempre in modo naturale alla configurazione del cloud ibrido. Le aziende spesso devono eseguire la transizione di applicazioni e dati in base alle loro priorità. Allo stesso modo, una configurazione a breve termine potrebbe essere pensata per facilitare una proof of concept utilizzando tecnologie avanzate disponibili nel cloud per un determinato periodo.

Decisioni di progettazione tecnica

L'obiettivo tecnico identificato e i relativi fattori trainanti sono fondamentali per prendere una decisione sull'architettura basata sull'attività e per selezionare uno dei pattern di architettura descritti in questa guida. Ad esempio, per supportare un obiettivo aziendale specifico, un'azienda potrebbe impostare un obiettivo aziendale per creare una pratica di ricerca e sviluppo per un periodo di tre-sei mesi. Il requisito aziendale principale per supportare questo obiettivo potrebbe essere quello di creare l'ambiente tecnologico necessario per la ricerca e la progettazione con il CAPEX più basso possibile.

L'obiettivo tecnico in questo caso è disporre di una configurazione cloud ibrido temporanea. Lo scopo di questo obiettivo tecnico è sfruttare il modello di prezzi on demand del cloud per soddisfare il requisito aziendale menzionato in precedenza. Un altro fattore è influenzato dai requisiti tecnologici specifici che richiedono una soluzione basata sul cloud con elevata capacità di calcolo e configurazione rapida.

Utilizzare Google Cloud per architetture ibride e multi-cloud

L'utilizzo di soluzioni open source può semplificare l'adozione di un approccio ibrido e multi-cloud e ridurre al minimo i vincoli al fornitore. Tuttavia, quando pianifichi un'architettura, devi considerare le seguenti potenziali complessità:

  • Interoperabilità
  • Gestibilità
  • Costo
  • Sicurezza

Basarsi su una piattaforma cloud che contribuisce e supporta l'open source potrebbe semplificare il percorso di adozione di architetture ibride e multi-cloud. Open Cloud ti offre un approccio che offre la massima scelta e astrae la complessità. Inoltre, Google Cloud offre la flessibilità necessaria per eseguire la migrazione, creare e ottimizzare le applicazioni in ambienti ibridi e multi-cloud, riducendo al minimo i vincoli al fornitore, utilizzando le migliori soluzioni e rispettando i requisiti normativi.

Google è anche uno dei maggiori contributori dell'ecosistema open source e collabora con la community open source per sviluppare note tecnologie open source come Kubernetes. Se implementato come servizio gestito, Kubernetes può contribuire a ridurre le complessità relative alla gestibilità e alla sicurezza ibride e multicloud.

Pianificare una strategia ibrida e multi-cloud

Questo documento si concentra su come applicare considerazioni aziendali predefinite durante la pianificazione di una strategia ibrida e multi-cloud. Si basa sulle indicazioni riportate in Motivazioni, considerazioni, strategia e approcci. Questo articolo definisce e analizza le considerazioni commerciali che le aziende devono tenere in considerazione quando pianificano una strategia di questo tipo.

Chiarire e concordare la vision e gli obiettivi

In definitiva, lo scopo principale di una strategia ibrida o multicloud è quello di soddisfare i requisiti aziendali identificati e gli obiettivi tecnici associati per ogni caso d'uso aziendale in linea con obiettivi aziendali specifici. Per raggiungere questo obiettivo, crea un piano ben strutturato che includa le seguenti considerazioni:

Tieni presente che definire un piano che tenga conto di tutti i workload e i requisiti è difficile, soprattutto in un ambiente IT complesso. Inoltre, la pianificazione richiede tempo e potrebbe portare a visioni contrastanti degli stakeholder.

Per evitare situazioni di questo tipo, formula inizialmente una dichiarazione della vision che risponda almeno alle seguenti domande:

  • Qual è il caso d'uso aziendale mirato per raggiungere obiettivi commerciali specifici?
  • Perché l'approccio e l'ambiente di computing attuali non sono sufficienti a soddisfare gli obiettivi aziendali?
  • Quali sono gli aspetti tecnologici principali da ottimizzare utilizzando il cloud pubblico?
  • Perché e in che modo il nuovo approccio ottimizzerà e soddisferà i tuoi obiettivi commerciali?
  • Per quanto tempo prevedi di utilizzare la configurazione ibrida o multicloud?

Concordare gli obiettivi e i fattori chiave aziendali e tecnici, quindi ottenere l'approvazione delle parti interessate pertinenti può fornire una base per i passaggi successivi della procedura di pianificazione. Per allineare in modo efficace la soluzione proposta alla vision architettonica generale della tua organizzazione, collabora con il tuo team e con gli stakeholder responsabili della guida e della sponsorizzazione di questa iniziativa.

Identificare e chiarire altre considerazioni

Quando pianifichi un'architettura ibrida o multicloud, è importante identificare e concordare i vincoli architetturali e operativi del tuo progetto.

Dal punto di vista operativo, il seguente elenco non esaustivo fornisce alcuni requisiti che potrebbero creare alcuni vincoli da considerare durante la pianificazione dell'architettura:

  • Gestione e configurazione di più cloud separatamente rispetto alla creazione di un modello olistico per gestire e proteggere i diversi ambienti cloud.
  • Garantire autenticazione, autorizzazione, controllo e criteri coerenti in tutti gli ambienti.
  • Utilizzo di strumenti e processi coerenti in tutti gli ambienti per fornire una visione olistica di sicurezza, costi e opportunità di ottimizzazione.
  • Utilizzo di standard di conformità e sicurezza coerenti per applicare una governance unificata.

Per quanto riguarda la pianificazione dell'architettura, i vincoli maggiori derivano spesso dai sistemi esistenti e possono includere quanto segue:

  • Dipendenze tra le applicazioni
  • Requisiti di prestazioni e latenza per la comunicazione tra i sistemi
  • Dipendenza da hardware o sistemi operativi che potrebbero non essere disponibili nel cloud pubblico
  • Limitazioni delle licenze
  • Dipendenza dalla disponibilità delle funzionalità richieste nelle regioni selezionate di un'architettura multicloud

Per ulteriori informazioni sulle altre considerazioni relative alla portabilità dei workload, allo spostamento dei dati e agli aspetti di sicurezza, consulta Altre considerazioni.

Progettare una strategia di architettura ibrida e multi-cloud

Dopo aver chiarito i dettagli degli obiettivi aziendali e tecnici con i requisiti aziendali associati (e idealmente aver chiarito e concordato una vision statement), puoi creare la tua strategia per creare un'architettura ibrida o multicloud.

Il seguente diagramma di flusso riassume i passaggi logici per creare una strategia di questo tipo.

Quando pianifichi una strategia, considera i tuoi obiettivi commerciali, ottieni l'approvazione, crea un piano di alto livello e poi utilizzalo per definire la tua strategia.

Per aiutarti a determinare gli obiettivi e le esigenze tecniche della tua architettura ibrida o multicloud, i passaggi del diagramma di flusso precedente iniziano con i requisiti e gli obiettivi aziendali. L'implementazione della strategia può variare a seconda degli obiettivi, dei fattori trainanti e del percorso di migrazione tecnologica di ogni caso d'uso aziendale.

È importante ricordare che una migrazione è un percorso. Il seguente diagramma illustra le fasi di questo percorso descritte in Eseguire la migrazione a Google Cloud.

Percorso di migrazione con quattro fasi.

Questa sezione fornisce indicazioni sulle fasi "Valuta", "Pianifica", "Implementa" e "Ottimizza" nel diagramma precedente. Presenta queste informazioni nel contesto di una migrazione ibrida o multi-cloud. Devi allineare qualsiasi migrazione alle indicazioni e alle best practice descritte nella sezione Percorso di migrazione della guida Eseguire la migrazione a Google Cloud . Queste fasi potrebbero essere applicate a ogni workload singolarmente, non a tutti i workload contemporaneamente. In qualsiasi momento, diversi carichi di lavoro potrebbero trovarsi in fasi diverse:

Fase di valutazione

Nella fase Valuta, esegui una valutazione iniziale del carico di lavoro. Durante questa fase, considera gli obiettivi delineati nei documenti di pianificazione della visione e della strategia. Decidi un piano di migrazione identificando innanzitutto un elenco di carichi di lavoro candidati che potrebbero trarre vantaggio dall'essere implementati o migrati nel cloud pubblico.

Per iniziare, scegli un carico di lavoro non business-critical o troppo difficile da migrare (con dipendenze minime o nulle da qualsiasi carico di lavoro in altri ambienti), ma sufficientemente tipico da fungere da modello per le implementazioni o le migrazioni future.

Idealmente, il workload o l'applicazione selezionati devono far parte di un caso d'uso o di una funzione aziendale mirata che abbia un effetto misurabile sull'attività al termine.

Per valutare e mitigare eventuali potenziali rischi di migrazione, esegui una valutazione dei rischi di migrazione. È importante valutare il carico di lavoro candidato per determinare la sua idoneità alla migrazione a un ambiente multicloud. Questa valutazione prevede l'analisi di vari aspetti delle applicazioni e dell'infrastruttura, tra cui i seguenti:

  • Requisiti di compatibilità delle applicazioni con i provider cloud selezionati
  • Modelli di prezzo
  • Funzionalità di sicurezza offerte dai provider cloud selezionati
  • Requisiti di interoperabilità delle applicazioni

L'esecuzione di una valutazione ti aiuta anche a identificare i requisiti di privacy dei dati, i requisiti di conformità, i requisiti di coerenza e le soluzioni in più ambienti cloud. I rischi che identifichi possono influire sui carichi di lavoro che scegli di migrare o gestire.

Esistono diversi tipi di strumenti, come il Centro di migrazione Google Cloud, per aiutarti a valutare i carichi di lavoro esistenti. Per ulteriori informazioni, vedi Migrazione a Google Cloud: scegli uno strumento di valutazione.

Dal punto di vista della modernizzazione dei workload, lo strumento di valutazione di idoneità consente di valutare un workload VM per determinare se è idoneo per la modernizzazione a un container o per la migrazione a Compute Engine.

Fase di pianificazione

Nella fase Pianifica, inizia con le applicazioni identificate e i carichi di lavoro cloud richiesti ed esegui le seguenti attività:

  1. Sviluppa una strategia di migrazione con priorità che definisca le ondate di migrazione delle applicazioni e i percorsi.
  2. Identifica il pattern di architettura di applicazioni ibride o multi-cloud di alto livello applicabile.
  3. Seleziona un pattern di architettura di rete che supporti il pattern di architettura dell'applicazione selezionato.

Idealmente, dovresti incorporare il pattern di rete cloud con la progettazione della landing zone. La progettazione della landing zone funge da elemento fondamentale delle architetture ibride e multi-cloud complessive. Il design richiede un'integrazione senza interruzioni con questi pattern. Non progettare la zona di destinazione in isolamento. Considera questi pattern di networking come un sottoinsieme della progettazione della landing zone.

Una landing zone può essere costituita da diverse applicazioni, ognuna con un pattern di architettura di rete diverso. Inoltre, in questa fase è importante decidere la progettazione della gerarchia di organizzazione, progetti e risorse per preparare la zona di destinazione dell'ambiente cloud per l'integrazione e il deployment ibridi o multi-cloud.Google Cloud

Nell'ambito di questa fase, devi considerare quanto segue:

  • Definisci l'approccio di migrazione e modernizzazione. Puoi trovare maggiori informazioni sugli approcci alla migrazione più avanti in questa guida. Questo aspetto è trattato in modo più dettagliato nella sezione Tipi di migrazione di Esegui la migrazione a Google Cloud.
  • Utilizza i risultati della fase di valutazione e scoperta. allineali al workload candidato di cui prevedi di eseguire la migrazione. Poi sviluppa un piano per le wave di migrazione delle applicazioni. Il piano deve incorporare i requisiti di dimensionamento delle risorse stimati che hai determinato durante la fase di valutazione.
  • Definisci il modello di comunicazione richiesto tra le applicazioni distribuite e tra i componenti dell'applicazione per l'architettura ibrida o multicloud prevista.
  • Scegli un archetipo di deployment adatto per eseguire il deployment del carico di lavoro, ad esempio zonale, regionale, multiregionale o globale, per il pattern di architettura scelto. L'archetipo che selezioni costituisce la base per la creazione di architetture di deployment specifiche per l'applicazione, personalizzate in base alle tue esigenze aziendali e tecniche.
  • Decidi i criteri di successo misurabili per la migrazione, con traguardi chiari per ogni fase o ondata di migrazione. La selezione dei criteri è essenziale, anche se l'obiettivo tecnico è quello di avere l'architettura ibrida come configurazione a breve termine.
  • Definisci SLA e KPI delle applicazioni quando queste operano in una configurazione ibrida, in particolare per quelle che potrebbero avere componenti distribuiti in più ambienti.

Per ulteriori informazioni, consulta la sezione Informazioni sulla pianificazione della migrazione per pianificare una migrazione riuscita e ridurre al minimo i rischi associati.

Fase di deployment

Nella fase Esegui il deployment, puoi iniziare a eseguire la strategia di migrazione. Dato il potenziale numero di requisiti, è meglio adottare un approccio iterativo.

Assegna la priorità ai tuoi workload in base alle wave di migrazione e applicazione che hai sviluppato durante la fase di pianificazione. Con le architetture ibride e multi-cloud, inizia il deployment stabilendo la connettività necessaria tra Google Cloud e gli altri ambienti di computing. Per facilitare il modello di comunicazione richiesto per l'architettura ibrida o multicloud, basa il deployment sul tipo di connettività di rete e sul design selezionati, nonché sul pattern di networking applicabile. Ti consigliamo di adottare questo approccio per la decisione di progettazione complessiva della zona di destinazione.

Inoltre, devi testare e convalidare l'applicazione o il servizio in base ai criteri di successo dell'applicazione definiti. Idealmente, questi criteri dovrebbero includere requisiti di test funzionali e di carico (non funzionali) prima di passare alla produzione.

Fase di ottimizzazione

Nella fase Ottimizza, testa il deployment: dopo aver completato i test e se l'applicazione o il servizio soddisfa le aspettative di capacità funzionale e di rendimento, puoi spostarlo in produzione. Strumenti di monitoraggio e visibilità del cloud, come Cloud Monitoring, possono fornire informazioni su prestazioni, disponibilità e integrità delle tue applicazioni e della tua infrastruttura e aiutarti a ottimizzare dove necessario.

Per maggiori informazioni, vedi Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente. Per saperne di più su come progettare questi strumenti per l'architettura ibrida o multicloud, consulta Pattern di monitoraggio e logging ibridi e multicloud.

Valuta i workload candidati

La scelta degli ambienti di computing per i diversi carichi di lavoro influisce in modo significativo sul successo di una strategia ibrida e multicloud. Le decisioni di posizionamento dei workload devono essere in linea con obiettivi aziendali specifici. Pertanto, queste decisioni devono essere guidate da casi d'uso aziendali mirati che consentano di ottenere effetti aziendali misurabili. Tuttavia, iniziare con il carico di lavoro/l'applicazione più importante per l'attività non è sempre necessario né consigliato. Per maggiori informazioni, consulta Scegliere le app da migrare per prime nella guida Eseguire la migrazione a Google Cloud .

Come descritto nella sezione Fattori tecnici e aziendali, esistono diversi tipi di fattori e considerazioni per le architetture ibride e multicloud.

Il seguente elenco riepilogativo di fattori può aiutarti a valutare il tuo caso d'uso della migrazione nel contesto di un'architettura ibrida o multicloud con opportunità di avere un effetto misurabile sull'attività:

  • Potenziale di differenziazione o innovazione del mercato reso possibile dall'utilizzo di servizi cloud per attivare determinate funzioni o funzionalità aziendali, come le funzionalità di intelligenza artificiale che utilizzano dati on-premise esistenti per addestrare modelli di machine learning.
  • Potenziali risparmi sul costo totale di proprietà di un'applicazione.
  • Potenziali miglioramenti in termini di disponibilità, resilienza, sicurezza o rendimento, ad esempio l'aggiunta di un sitoripristino di emergenzay RER) nel cloud.
  • Potenziale accelerazione dei processi di sviluppo e rilascio, ad esempio la creazione degli ambienti di sviluppo e test nel cloud.

I seguenti fattori possono aiutarti a valutare i rischi di migrazione:

  • Il potenziale effetto delle interruzioni causate da una migrazione.
  • L'esperienza del tuo team con le implementazioni di cloud pubblico o con le implementazioni per un nuovo o secondo cloud provider.
  • La necessità di rispettare eventuali restrizioni legali o normative esistenti.

I seguenti fattori possono aiutarti a valutare le difficoltà tecniche di una migrazione:

  • Le dimensioni, la complessità e l'età dell'applicazione.
  • Il numero di dipendenze con altre applicazioni e servizi in diversi ambienti di computing.
  • Qualsiasi limitazione imposta dalle licenze di terze parti.
  • Eventuali dipendenze da versioni specifiche di sistemi operativi, database o altre configurazioni dell'ambiente.

Dopo aver valutato i carichi di lavoro iniziali, puoi iniziare ad assegnare loro la priorità e a definire le wave di migrazione e gli approcci. Poi puoi identificare i pattern di architettura applicabili e i pattern di rete di supporto. Questo passaggio potrebbe richiedere più iterazioni, perché la tua valutazione potrebbe cambiare nel tempo. Pertanto, vale la pena rivalutare i carichi di lavoro dopo aver eseguito i primi deployment sul cloud.

Approcci architetturali per adottare un'architettura ibrida o multi-cloud

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 multicloud ibrido e la modernizzazione dell'IT sono concetti distinti, ma 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.

Diagramma di flusso che mostra diversi approcci alla migrazione dei workload dal tuo ambiente cloud.

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.

Altre considerazioni

Questo documento evidenzia le considerazioni di progettazione principali che svolgono un ruolo fondamentale nella definizione dell'architettura ibrida e multicloud complessiva. Analizza e valuta in modo olistico queste considerazioni nell'intera architettura della soluzione, comprendendo tutti i carichi di lavoro, non solo quelli specifici.

Refactor

In una migrazione di refactoring, modifichi i tuoi carichi di lavoro per sfruttare le funzionalità del cloud, non solo per farli funzionare nel nuovo ambiente. Puoi migliorare ogni workload in termini di prestazioni, funzionalità, costi ed esperienza utente. Come evidenziato in Refactoring: sposta e migliora, alcuni scenari di refactoring ti consentono di modificare i carichi di lavoro prima di eseguirne la migrazione al cloud. Questo approccio di refactoring offre i seguenti vantaggi, soprattutto se il tuo obiettivo è creare un'architettura ibrida come architettura di destinazione a lungo termine:

  • Puoi migliorare il processo di deployment.
  • Puoi contribuire ad accelerare la cadenza di rilascio e ridurre i cicli di feedback investendo in strumenti e infrastrutture di integrazione continua/deployment continuo (CI/CD).
  • Puoi utilizzare il refactoring come base per creare e gestire un'architettura ibrida con portabilità delle applicazioni.

Per funzionare bene, questo approccio in genere richiede determinati investimenti in infrastrutture e strumenti on-premise. Ad esempio, la configurazione di un Container Registry locale e il provisioning di cluster Kubernetes per containerizzare le applicazioni. La versione GKE Enterprise può essere utile in questo approccio per gli ambienti ibridi. Ulteriori informazioni su GKE Enterprise sono disponibili nella sezione seguente. Per ulteriori dettagli, puoi anche consultare l'architettura di riferimento dell'ambiente ibrido GKE Enterprise.

Portabilità del carico di lavoro

Con le architetture ibride e multicloud, potresti voler spostare i carichi di lavoro tra gli ambienti di computing che ospitano i tuoi dati. Per facilitare lo spostamento senza interruzioni dei carichi di lavoro tra gli ambienti, considera i seguenti fattori:

  • Puoi spostare un'applicazione da un ambiente di computing a un altro senza modificare in modo significativo l'applicazione e il relativo modello operativo:
    • Il deployment e la gestione delle applicazioni sono coerenti in tutti gli ambienti di computing.
    • Visibilità, configurazione e sicurezza sono coerenti in tutti gli ambienti di computing.
  • La possibilità di rendere un workload portatile non deve essere in conflitto con il fatto che il workload sia cloud-first.

Automazione dell'infrastruttura

L'automazione dell'infrastruttura è essenziale per la portabilità nelle architetture ibride e multi-cloud. Un approccio comune per automatizzare la creazione dell'infrastruttura è tramite Infrastructure as Code (IaC). IaC prevede la gestione dell'infrastruttura nei file anziché la configurazione manuale delle risorse, come una VM, un gruppo di sicurezza o un bilanciatore del carico, in un'interfaccia utente. Terraform è uno strumento IaC popolare per definire le risorse dell'infrastruttura in un file. Terraform consente anche di automatizzare la creazione di queste risorse in ambienti eterogenei.

Per saperne di più sulle funzioni principali di Terraform che possono aiutarti ad automatizzare il provisioning e la gestione delle risorse Google Cloud , consulta Modelli e moduli Terraform per Google Cloud.

Puoi utilizzare strumenti di gestione della configurazione come Ansible, Puppet, o Chef per stabilire un processo di deployment e configurazione comune. In alternativa, puoi utilizzare uno strumento di creazione di immagini come Packer per creare immagini VM per piattaforme diverse. Utilizzando un unico file di configurazione condiviso, puoi utilizzare Packer e Cloud Build per creare un'immagine VM da utilizzare su Compute Engine. Infine, puoi utilizzare soluzioni come Prometheus e Grafana per garantire un monitoraggio coerente in tutti gli ambienti.

In base a questi strumenti, puoi assemblare una toolchain comune come illustrato nel seguente diagramma logico. Questa catena di strumenti comune astrae le differenze tra gli ambienti di computing. Consente inoltre di unificare il provisioning, l'implementazione, la gestione e il monitoraggio.

Una toolchain consente la portabilità delle applicazioni.

Sebbene una catena di strumenti comune possa aiutarti a ottenere la portabilità, è soggetta a diversi dei seguenti svantaggi:

  • L'utilizzo delle VM come base comune può rendere difficile l'implementazione di vere applicazioni cloud-first. Inoltre, l'utilizzo delle sole VM può impedirti di utilizzare i servizi gestiti dal cloud. Potresti perdere opportunità per ridurre l'overhead amministrativo.
  • La creazione e la manutenzione di una catena di strumenti comuni comporta costi generali e operativi.
  • Man mano che la catena di strumenti si espande, può sviluppare complessità uniche su misura per le esigenze specifiche della tua azienda. Questa maggiore complessità può contribuire all'aumento dei costi di addestramento.

Prima di decidere di sviluppare strumenti e automazione, esplora i servizi gestiti offerti dal tuo fornitore di servizi cloud. Quando il tuo provider offre servizi gestiti che supportano lo stesso caso d'uso, puoi astrarre parte della sua complessità. In questo modo puoi concentrarti sul carico di lavoro e sull'architettura dell'applicazione anziché sull'infrastruttura sottostante.

Ad esempio, puoi utilizzare il modello di risorse Kubernetes per automatizzare la creazione di cluster Kubernetes utilizzando un approccio di configurazione dichiarativa. Puoi utilizzare Deployment Manager convert per convertire le configurazioni e i modelli di Deployment Manager in altri formati di configurazione dichiarativa supportati da Google Cloud (come Terraform e Kubernetes Resource Model) in modo che siano portatili quando li pubblichi.

Puoi anche valutare l'automazione della creazione di progetti e di risorse all'interno di questi progetti. Questa automazione può aiutarti ad adottare un approccio Infrastructure as Code per il provisioning dei progetti.

Container e Kubernetes

L'utilizzo di funzionalità gestite dal cloud contribuisce a ridurre la complessità della creazione e della manutenzione di una toolchain personalizzata per ottenere l'automazione e la portabilità dei carichi di lavoro. Tuttavia, l'utilizzo delle sole VM come base comune rende difficile l'implementazione di applicazioni veramente cloud-first. Una soluzione è utilizzare i container e Kubernetes.

I container aiutano il software a essere eseguito in modo affidabile quando lo sposti da un ambiente all'altro. Poiché i container separano le applicazioni dall'infrastruttura host sottostante, facilitano il deployment in ambienti di computing, come quelli ibridi e multi-cloud.

Kubernetes gestisce l'orchestrazione, il deployment, lo scaling e la gestione delle applicazioni containerizzate. È open source e regolato dalla Cloud Native Computing Foundation. L'utilizzo di Kubernetes fornisce i servizi che costituiscono la base di un'applicazione cloud-first. Poiché puoi installare ed eseguire Kubernetes in molti ambienti di computing, puoi utilizzarlo anche per stabilire un livello di runtime comune in tutti gli ambienti di computing:

  • Kubernetes fornisce gli stessi servizi e API in un ambiente di cloud o di computing privato. Inoltre, il livello di astrazione è molto più alto rispetto a quando si lavora con le VM, il che in genere si traduce in un lavoro preparatorio meno impegnativo e in una maggiore produttività degli sviluppatori.
  • A differenza di una toolchain personalizzata, Kubernetes è ampiamente adottato sia per lo sviluppo che per la gestione delle applicazioni, quindi puoi sfruttare competenze, documentazione e supporto di terze parti esistenti.
  • Kubernetes supporta tutte le implementazioni di container che:

Quando un workload è in esecuzione su Google Cloud, puoi evitare lo sforzo di installare e utilizzare Kubernetes utilizzando una piattaforma Kubernetes gestita come Google Kubernetes Engine (GKE). In questo modo, il personale operativo può spostare la propria attenzione dalla creazione e dalla manutenzione dell'infrastruttura alla creazione e alla manutenzione delle applicazioni.

Puoi anche utilizzare Autopilot, una modalità operativa di GKE che gestisce la configurazione del cluster, inclusi nodi, scalabilità, sicurezza e altre impostazioni preconfigurate. Quando utilizzi GKE Autopilot, considera i tuoi requisiti di scalabilità e i relativi limiti di scalabilità.

Tecnicamente, puoi installare ed eseguire Kubernetes in molti ambienti di computing per stabilire un livello di runtime comune. Tuttavia, in pratica, la creazione e la gestione di un'architettura di questo tipo possono creare complessità. L'architettura diventa ancora più complessa quando richiedi il controllo della sicurezza a livello di container (service mesh).

Per semplificare la gestione dei deployment multi-cluster, puoi utilizzare GKE Enterprise per eseguire applicazioni moderne ovunque su larga scala. GKE include potenti componenti open source gestiti per proteggere i carichi di lavoro, applicare criteri di conformità e fornire osservabilità e risoluzione dei problemi di rete approfondite.

Come illustrato nel seguente diagramma, l'utilizzo di GKE Enterprise ti consente di gestire applicazioni multi-cluster come parchi risorse.

Diagramma dello stack che mostra le opportunità di gestione dei parchi risorse offerte da GKE Enterprise.

GKE Enterprise offre le seguenti opzioni di progettazione per supportare architetture ibride e multi-cloud:

  • Progetta e crea esperienze simili al cloud on-premise o soluzioni unificate per la transizione delle applicazioni all'ambiente ibrido GKE Enterprise. Per maggiori informazioni, consulta l'architettura di riferimento dell'ambiente ibrido GKE Enterprise.

  • Progetta e crea una soluzione per risolvere la complessità multicloud con una strategia coerente per governance, operazioni e sicurezza con GKE Multi-Cloud. Per saperne di più, consulta la documentazione di GKE Multi-Cloud.

GKE Enterprise fornisce anche raggruppamenti logici di ambienti simili con gestione coerente di sicurezza, configurazione e servizi. Ad esempio, GKE Enterprise supporta un'architettura distribuita Zero Trust. In un'architettura distribuita zero trust, i servizi di cui è stato eseguito il deployment on-premise o in un altro ambiente cloud possono comunicare tra gli ambienti tramite comunicazioni service-to-service sicure mTLS end-to-end.

Considerazioni sulla portabilità del workload

Kubernetes e GKE Enterprise forniscono un livello di astrazione per i carichi di lavoro che può nascondere le numerose complessità e differenze tra gli ambienti di computing. L'elenco seguente descrive alcune di queste astrazioni:

  • Un'applicazione potrebbe essere trasferibile a un ambiente diverso con modifiche minime, ma ciò non significa che le prestazioni dell'applicazione siano ugualmente buone in entrambi gli ambienti.
    • Differenze nel calcolo sottostante, nelle funzionalità di sicurezza dell'infrastruttura o nell'infrastruttura di rete, nonché la vicinanza ai servizi dipendenti, potrebbero comportare prestazioni sostanzialmente diverse.
  • Lo spostamento di un workload tra ambienti di computing potrebbe richiedere anche lo spostamento dei dati.
    • Ambienti diversi possono avere servizi e strutture di archiviazione e gestione dei dati diversi.
  • Il comportamento e il rendimento dei bilanciatori del carico di cui è stato eseguito il provisioning con Kubernetes o GKE Enterprise potrebbero variare a seconda dell'ambiente.

Spostamento dei dati

Poiché lo spostamento, la condivisione e l'accesso ai dati su larga scala tra ambienti di computing possono essere complessi, le aziende di livello enterprise potrebbero esitare a creare un'architettura ibrida o multicloud. Questa esitazione potrebbe aumentare se già archiviano la maggior parte dei loro dati on-premise o in un cloud.

Tuttavia, le varie opzioni di spostamento dei dati offerte da Google Cloudforniscono alle aziende un insieme completo di soluzioni per spostare, integrare e trasformare i dati. Queste opzioni aiutano le aziende ad archiviare, condividere e accedere ai dati in diversi ambienti in un modo che soddisfi i loro casi d'uso specifici. Questa capacità, in definitiva, semplifica l'adozione di architetture ibride e multi-cloud per i responsabili delle decisioni aziendali e tecnologiche.

Lo spostamento dei dati è un aspetto importante da considerare per la strategia ibrida e multi-cloud e la pianificazione dell'architettura. Il tuo team deve identificare i diversi casi d'uso della tua attività e i dati che li alimentano. Devi anche pensare al tipo di spazio di archiviazione, alla capacità, all'accessibilità e alle opzioni di movimento.

Se un'azienda ha una classificazione dei dati per i settori regolamentati, questa classificazione può aiutare a identificare le posizioni di archiviazione e le limitazioni al trasferimento dei dati tra regioni per determinate classi di dati. Per ulteriori informazioni, consulta Sensitive Data Protection. Protezione dei dati sensibili è un servizio completamente gestito progettato per aiutarti a scoprire, classificare e proteggere i tuoi asset di dati.

Per esplorare il processo, dalla pianificazione di un trasferimento dati all'utilizzo delle best practice durante l'implementazione di un piano, consulta Migrazione verso Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni.

Sicurezza

Man mano che le organizzazioni adottano architetture ibride e multicloud, la loro superficie di attacco può aumentare a seconda della modalità di distribuzione dei sistemi e dei dati in ambienti diversi. In combinazione con il panorama delle minacce in continua evoluzione, l'aumento delle superfici di attacco può portare a un maggiore rischio di accesso non autorizzato, perdita di dati e altri incidenti di sicurezza. Valuta attentamente la sicurezza quando pianifichi e implementi strategie ibride o multi-cloud.

Per saperne di più, consulta Attack Surface Management per Google Cloud.

Quando si progetta un'architettura ibrida, non è sempre tecnicamente fattibile o praticabile estendere al cloud gli approcci di sicurezza on-premise. Tuttavia, molte delle funzionalità di sicurezza di rete degli appliance hardware sono funzionalità cloud-first e funzionano in modo distribuito. Per saperne di più sulle funzionalità di sicurezza di rete cloud-first di Google Cloud, consulta Sicurezza della rete cloud.

Le architetture ibride e multi-cloud possono introdurre ulteriori sfide di sicurezza, come coerenza e osservabilità. Ogni fornitore di cloud pubblico ha il proprio approccio alla sicurezza, inclusi modelli, best practice, funzionalità di sicurezza di infrastruttura e applicazioni, obblighi di conformità e persino i nomi dei servizi di sicurezza. Queste incongruenze possono aumentare il rischio per la sicurezza. Inoltre, il modello di responsabilità condivisa di ogni provider cloud può variare. È essenziale identificare e comprendere la demarcazione esatta delle responsabilità in un'architettura multicloud.

L'osservabilità è fondamentale per ottenere insight e metriche dai diversi ambienti. In un'architettura multicloud, ogni cloud in genere fornisce strumenti per monitorare la postura di sicurezza e le configurazioni errate. Tuttavia, l'utilizzo di questi strumenti comporta una visibilità isolata, che impedisce la creazione di informazioni avanzate sulle minacce nell'intero ambiente. Di conseguenza, il team di sicurezza deve passare da uno strumento all'altro e da un dashboard all'altro per mantenere il cloud sicuro. Senza una visibilità end-to-end della sicurezza per gli ambienti ibridi e multi-cloud, è difficile dare la priorità alle vulnerabilità e mitigarle.

Per ottenere la visibilità e la postura complete di tutti i tuoi ambienti, dai la priorità alle vulnerabilità e mitiga quelle che identifichi. Ti consigliamo un modello di visibilità centralizzato. Un modello di visibilità centralizzato evita la necessità di correlazione manuale tra diversi strumenti e dashboard di piattaforme diverse. Per maggiori informazioni, consulta Pattern di logging e monitoraggio per cloud ibrido e multi-cloud.

Nell'ambito della pianificazione per mitigare i rischi per la sicurezza ed eseguire il deployment dei carichi di lavoro su Google Cloude per aiutarti a pianificare e progettare la tua soluzione cloud per raggiungere i tuoi obiettivi di sicurezza e conformità, esplora il Google Cloud centro per le best practice di sicurezza e il progetto base per la sicurezza.

Gli obiettivi di conformità possono variare, in quanto sono influenzati sia dalle normative specifiche del settore sia dai diversi requisiti normativi di regioni e paesi diversi. Per saperne di più, consulta il Google Cloud Centro risorse per la conformità. Di seguito sono riportati alcuni degli approcci principali consigliati per la progettazione di un'architettura ibrida e multi-cloud sicura:

  • Sviluppa una strategia e un'architettura di sicurezza cloud unificate e personalizzate. Le strategie di sicurezza ibride e multicloud devono essere adattate alle esigenze e agli obiettivi specifici della tua organizzazione.

    È essenziale comprendere l'architettura e l'ambiente di destinazione prima di implementare i controlli di sicurezza, perché ogni ambiente può utilizzare funzionalità, configurazioni e servizi diversi.

  • Prendi in considerazione un'architettura di sicurezza unificata negli ambienti ibridi e multi-cloud.

  • Standardizzare la progettazione e i deployment cloud, in particolare la progettazione e le funzionalità di sicurezza. In questo modo è possibile migliorare l'efficienza e attivare la governance e gli strumenti unificati.

  • Utilizza più controlli di sicurezza.

    In genere, nessun singolo controllo di sicurezza può soddisfare adeguatamente tutti i requisiti di protezione della sicurezza. Pertanto, le organizzazioni devono utilizzare una combinazione di controlli di sicurezza in un approccio di difesa a più livelli, noto anche come difesa in profondità.

  • Monitora e migliora continuamente le posture di sicurezza: la tua organizzazione deve monitorare i diversi ambienti per rilevare minacce e vulnerabilità alla sicurezza. Inoltre, dovrebbe cercare di migliorare continuamente la propria strategia di sicurezza.

  • Valuta la possibilità di utilizzare la gestione della postura di sicurezza nel cloud (CSPM) per identificare e correggere errori di configurazione della sicurezza e minacce informatiche. CSPM fornisce anche valutazioni delle vulnerabilità in ambienti ibridi e multi-cloud.

Security Command Center è una soluzione integrata di sicurezza e gestione dei rischi per Google Cloudche aiuta a identificare configurazioni errate, vulnerabilità e altro ancora. Security Health Analytics è uno strumento di scansione gestito per la valutazione delle vulnerabilità. Si tratta di una funzionalità di Security Command Center che identifica i rischi e le vulnerabilità per la sicurezza nel tuo ambienteGoogle Cloud e fornisce consigli per la loro correzione.

Mandiant Attack Surface Management per Google Cloud consente alla tua organizzazione di visualizzare meglio gli asset dell'ambiente multi-cloud o cloud ibrido. Rileva automaticamente gli asset di più provider cloud, DNS e la superficie di attacco esterna estesa per fornire alla tua azienda una comprensione più approfondita del suo ecosistema. Utilizza queste informazioni per dare la priorità alla correzione delle vulnerabilità e delle esposizioni che presentano il rischio maggiore.

  • Soluzione di gestione degli eventi e delle informazioni di sicurezza (SIEM) nel cloud: consente di raccogliere e analizzare i log di sicurezza da ambienti ibridi e multicloud per rilevare e rispondere alle minacce. Google Security Operations SIEM di Google Cloud consente di fornire la gestione degli eventi e delle informazioni di sicurezza raccogliendo, analizzando, rilevando e analizzando tutti i dati di sicurezza in un unico posto.

Crea architetture ibride e multi-cloud utilizzando Google Cloud: What's next