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 dei tuoi 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 illustra molti modelli di architettura ibrida e multi-cloud comprovati.

Il set di documenti per i modelli di architettura ibrida e multi-cloud è costituito 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 cambiamento delle richieste del mercato ha aumentato i requisiti e le aspettative nei confronti dell'IT aziendale, ad esempio la scalabilità dinamica, l'aumento delle prestazioni per un'esperienza utente ottimizzata e la sicurezza. Molte aziende di livello enterprise riscontrano difficoltà a soddisfare queste richieste ed aspettative utilizzando solo infrastrutture e processi tradizionali. Anche i reparti IT sono sotto pressione per migliorare la redditività, il che rende difficile giustificare ulteriori investimenti di capitale in data center ed equipaggiamento.

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

Aggiungendo una o più soluzioni basate su cloud pubblico, come Google Cloud, alla tua infrastruttura esistente, non solo salvaguardi i tuoi investimenti esistenti, ma eviti anche di impegnarti con un singolo fornitore di servizi cloud. Inoltre, utilizzando una strategia ibrida, puoi modernizzare le applicazioni e le procedure in modo incrementale, in base alle risorse disponibili.

Per aiutarti a pianificare la tua decisione sull'architettura e la strategia ibrida o multi-cloud, devi prendere in considerazione diverse potenziali sfide e considerazioni di progettazione. Questa guida all'architettura in più parti sottolinea sia i potenziali vantaggi di varie architetture sia le potenziali sfide.

Panoramica del cloud ibrido e multi-cloud

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

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

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

Diagramma delle tre architetture discusse in questa serie: ibrida, multi-cloud e combinazione di architetture ibride e multi-cloud.

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

Fattori, considerazioni, strategia e approcci

Questo documento definisce e illustra gli scopi, i fattori di stimolo e i requisiti aziendali e spiega in che modo questi fattori possono influenzare le decisioni di progettazione durante la costruzione di architetture ibride e multi-cloud.

Obiettivi

Un'organizzazione può adottare un'architettura ibrida o multi-cloud come soluzione permanente per raggiungere obiettivi commerciali specifici o come stato temporaneo per semplificare 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 raggiungerlo tecnicamente.

  • Quali obiettivi commerciali stanno guidando la decisione di adottare un'architettura ibrida o multicloud?
  • Quali obiettivi commerciali e tecnici aiuterà a raggiungere un'architettura ibrida o multi-cloud?
  • Quali fattori aziendali hanno influenzato questi obiettivi?
  • Quali sono i requisiti specifici dell'attività?

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

Per supportare i requisiti e gli obiettivi commerciali sopra menzionati, un potenziale obiettivo tecnico principale è 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 dell'espansione in termini di regioni e tempistiche target.

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

È importante distinguere tra gli scopi commerciali e gli scopi tecnici del progetto IT. Gli scopi commerciali devono essere incentrati sull'obiettivo 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 suoi requisiti e obiettivi commerciali.

I fattori di successo aziendali influiscono sul raggiungimento degli scopi e degli obiettivi commerciali. Pertanto, identificare chiaramente i fattori di successo aziendali può contribuire a definire scopi o obiettivi commerciali più pertinenti alle esigenze e alle tendenze del mercato.

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

Organigramma che mostra gli aspetti da considerare durante lo sviluppo dei requisiti tecnici, inclusi fattori di successo, scopi, obiettivi e requisiti aziendali, nonché scopi tecnici.

Fattori commerciali e tecnici

Valuta in che modo i fattori di crescita della tua attività influiscono sui tuoi obiettivi tecnici. Ecco alcuni fattori determinanti comuni per le attività quando scelgono un'architettura ibrida:

  • Rispettare le leggi e le normative sulla sovranità dei dati.
  • Riduzione della spesa in conto capitale (CapEx) o della spesa IT generale con il supporto della gestione finanziaria e dell'ottimizzazione dei costi del cloud, come FinOps.
    • L'adozione del cloud può essere guidata da scenari che contribuiscono a ridurre i CAPEX, ad esempio la creazione di una soluzione di ripristino di emergenza in un'architettura ibrida o multi-cloud.
  • Migliorare l'esperienza utente.
  • Maggiore flessibilità e agilità per rispondere alle mutevoli esigenze del mercato.
  • Miglioramento della trasparenza in merito a costi e consumo di risorse.

Valuta insieme l'elenco dei fattori determinanti per l'adozione di un'architettura ibrida o multi-cloud. Non considerarle singolarmente. La decisione finale deve dipendere dal bilanciamento delle priorità della tua attività.

Una volta che la tua organizzazione avrà compreso i vantaggi del cloud, potrebbe decidere di eseguire la migrazione completa se non esistono vincoli, come costi o requisiti di conformità specifici che richiedono l'hosting on-premise di dati altamente sicuri, che ne impediscono l'esecuzione.

Sebbene l'adozione di un singolo fornitore di servizi cloud possa offrire diversi vantaggi, come la complessità ridotta, le integrazioni integrate tra i servizi e le opzioni di ottimizzazione dei costi come gli sconti per utilizzo a livello di impegno, esistono ancora alcuni scenari in cui un'architettura multicloud può essere utile per un'attività. Di seguito sono riportati i fattori aziendali comuni per l'adozione di un'architettura multicloud, insieme alle considerazioni associate a ciascun fattore:

  • Rispetto delle leggi e normative sulla sovranità dei dati: lo scenario più comune è quando un'organizzazione espande la propria attività in una nuova regione o in un nuovo paese e deve rispettare le nuove normative sull'hosting dei dati.
    • Se il fornitore di servizi cloud (CSP) esistente non ha una regione cloud locale in quel paese, per motivi di conformità la soluzione comune è utilizzare un altro CSP con una regione cloud locale in quel paese.
  • Riduzione dei costi: la riduzione dei costi è spesso il motivo commerciale più comune per adottare una tecnologia o un'architettura. Tuttavia, è importante considerare più del solo costo dei servizi e dei potenziali sconti sui prezzi quando si decide 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 difficoltà associate a una strategia multicloud possono superare i vantaggi. Una strategia multi-cloud potrebbe introdurre costi aggiuntivi in un secondo momento.

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

  • e una gestione complessa.
  • Mantenimento di una sicurezza coerente.
  • Integrazione di ambienti software.
  • Raggiungere prestazioni e affidabilità coerenti in più cloud.
  • La creazione di un team tecnico con competenze multicloud potrebbe essere costosa e richiedere l'ampliamento del team, a meno che non sia gestito da un'azienda di terze parti.
  • Gestire gli strumenti di gestione e determinazione dei prezzi dei prodotti di ciascun CSP.
  • Utilizzo delle funzionalità uniche di ciascun 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 potenziali difficoltà tramite una valutazione di fattibilità ed efficacia, incluse le difficoltà comuni menzionate in precedenza.
  • Evitare i vincoli al fornitore: a volte le aziende vogliono evitare di essere vincolate a un singolo fornitore di cloud. Un approccio multi-cloud consente di scegliere la soluzione migliore per le esigenze aziendali. Tuttavia, la fattibilità di questa decisione dipende da diversi fattori, tra cui:
    • Dipendenze tecniche
    • Considerazioni sull'interoperabilità tra le applicazioni
    • Costi di ricostruzione o refactoring delle applicazioni
    • Competenze tecniche
    • Sicurezza e gestibilità coerenti
  • Migliorare il livello di affidabilità e disponibilità delle applicazioni di importanza critica per l'attività: in alcuni scenari, un'architettura multicloud può offrire resilienza alle interruzioni del servizio. Ad esempio, se una regione di un CSP non è disponibile, il traffico può essere indirizzato a un altro CSP nella stessa regione. Questo scenario assume che entrambi i provider cloud supportino le funzionalità o i servizi richiesti nella regione.

Quando le normative sulla residenza dei dati in un paese o una regione specifici richiedono 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 fornitori di servizi cloud in una regione per garantire la resilienza alle interruzioni, puoi facilitare la conformità alle limitazioni normative e allo stesso tempo 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 spostarsi all'interno del tuo ambiente multicloud?
    • Il trasferimento dei dati potrebbe comportare costi significativi?
  • Sicurezza e gestibilità: sono presenti potenziali complessità relative alla sicurezza o alla gestione?
  • Parità di funzionalità: entrambi i fornitori di servizi cloud nella regione selezionata offrono le funzionalità e i servizi richiesti?
  • Competenze tecniche: il team tecnico ha le competenze necessarie per gestire un'architettura multicloud?

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 per un aumento dell'affidabilità potrebbe far lievitare i costi nel breve termine, ma potrebbe impedire interruzioni o errori. Questi errori possono causare danni finanziari e di reputazione a lungo termine. Pertanto, è importante valutare i costi a breve termine rispetto al valore potenziale a lungo termine dell'adozione del multi-cloud. Inoltre, il valore potenziale a lungo termine può variare in base alle dimensioni dell'organizzazione, alla scala della tecnologia, alla criticità della soluzione tecnologica e al settore.

Le organizzazioni che prevedono di creare un ambiente ibrido o multi-cloud di successo dovrebbero prendere in considerazione la creazione di un Cloud Center of Excellence (COE). Un team 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ù velocemente, promuovere la standardizzazione e mantenere un allineamento più solido tra la strategia aziendale e gli investimenti cloud.

Se lo scopo dell'architettura ibrida o multi-cloud è creare un stato temporaneo, i fattori di business comuni includono:

  • La necessità di ridurre la spesa CAPEX o IT generale per progetti a breve termine.
  • La possibilità di eseguire il provisioning di questa infrastruttura in modo rapido per supportare un caso d'uso aziendale. Ad esempio:
    • Questa architettura potrebbe essere utilizzata per progetti a tempo limitato. Potrebbe essere utilizzato per supportare un progetto che richiede un'infrastruttura distribuita su larga scala per una durata limitata, continuando a utilizzare i dati on-premise.
  • La necessità di progetti di trasformazione digitale pluriennali che richiedono a una grande azienda di stabilire e utilizzare un'architettura ibrida per un certo tempo per aiutarla ad allineare la modernizzazione delle infrastrutture e delle applicazioni alle sue 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 nuova architettura cloud. È normale che due aziende che si fondono utilizzino cloud provider diversi o che una utilizzi un data center privato on-premise e l'altra il cloud. In entrambi i casi, il primo passaggio in una fusione e acquisizione è quasi sempre integrare i sistemi IT.

Fattori tecnici

La sezione precedente ha discusso i fattori di crescita aziendale. Per essere approvate, le decisioni architettoniche importanti richiedono quasi sempre l'appoggio di questi fattori. Tuttavia, i fattori tecnici, che possono essere basati su un vantaggio tecnico o su un vincolo, possono anche influenzare i fattori aziendali. In alcuni scenari, è necessario tradurre i fattori tecnici in fattori aziendali e spiegare in che modo possono 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 i servizi di analisi avanzata e AI, che potrebbero essere difficili da implementare negli ambienti esistenti.
  • Migliorare la qualità e le prestazioni del servizio.
  • Automatizzazione e accelerazione dell'implementazione delle applicazioni per ottenere un time to market più rapido e tempi di ciclo più brevi.
  • Utilizzo di API e servizi di alto livello per accelerare lo sviluppo.
  • Accelera il provisioning delle risorse di calcolo e archiviazione.
  • Utilizzo di servizi serverless per creare servizi e funzionalità elastici più velocemente e su larga scala.
  • Utilizzo delle funzionalità di infrastruttura globale per creare architetture globali o multiregionali al fine di soddisfare determinati requisiti tecnici.

Il fattore tecnico più comune sia per le architetture multi-cloud temporanee che per quelle ibride temporanee è facilitare la migrazione da on-premise al cloud o a un altro cloud. In generale, le migrazioni al cloud portano quasi sempre in modo naturale alla configurazione di un cloud ibrido. Le aziende devono spesso eseguire la transizione sistematica di applicazioni e dati in base alle loro priorità. Analogamente, una configurazione a breve termine potrebbe essere finalizzata a facilitare un 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 sono fondamentali per prendere una decisione sull'architettura basata sulle esigenze aziendali e per selezionare uno dei pattern di architettura discussi in questa guida. Ad esempio, per supportare un obiettivo aziendale specifico, un'azienda potrebbe impostare uno scopo commerciale per creare una pratica di ricerca e sviluppo per un periodo compreso tra tre e sei mesi. Il requisito aziendale principale per supportare questo obiettivo potrebbe essere creare l'ambiente tecnologico necessario per la ricerca e il design con il CAPEX più basso possibile.

In questo caso, l'obiettivo tecnico è avere una configurazione cloud ibrido temporanea. L'obiettivo di questo scopo tecnico è sfruttare il modello di prezzi on demand del cloud per soddisfare il requisito aziendale sopra indicato. Un altro fattore determinante è costituito dai requisiti tecnologici specifici che richiedono una soluzione basata su cloud con elevata capacità di calcolo e configurazione rapida.

Utilizzo 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

Sfruttare una piattaforma cloud che contribuisce a supportare l'open source potrebbe aiutarti a semplificare il percorso di adozione di architetture ibride e multi-cloud. Il cloud aperto ti offre un approccio che offre la massima scelta e rimuove 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 una delle aziende che contribuiscono maggiormente all'ecosistema open source e collabora con la community open source per sviluppare tecnologie open source ben note come Kubernetes. Se implementato come servizio gestito, Kubernetes può contribuire a ridurre le complessità legate alla gestione e alla sicurezza ibrida e multi-cloud.

Pianifica una strategia ibrida e multi-cloud

Questo documento illustra come applicare considerazioni aziendali predefinite quando pianifichi una strategia ibrida e multi-cloud. Espande le indicazioni riportate in Fattori, considerazioni, strategia e approcci. L'articolo definisce e analizza le considerazioni commerciali che le aziende devono tenere presenti 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 è 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 in concorrenza tra gli stakeholder.

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

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

Concordare gli obiettivi e i fattori chiave di business e tecnici, quindi ottenere la firma degli stakeholder pertinenti, può fornire una base per i passaggi successivi della procedura di pianificazione. Per allineare efficacemente la soluzione proposta alla visione architettonica complessiva della tua organizzazione, allineati al tuo team e agli stakeholder responsabili della guida e del patrocinio di questa iniziativa.

Identificare e chiarire altre considerazioni

Durante la pianificazione di un'architettura ibrida o multicloud, è importante identificare e concordare i vincoli architettonici e operativi del 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:

  • Gestire e configurare più cloud separatamente rispetto alla creazione di un modello olistico per gestire e proteggere i diversi ambienti cloud.
  • Garantire l'autenticazione, l'autorizzazione, il controllo e i criteri coerenti in tutti gli ambienti.
  • Utilizzo di strumenti e processi coerenti in tutti gli ambienti per fornire una panoramica 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 più grandi spesso derivano da 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 relative alle licenze
  • Dipendenza dalla disponibilità delle funzionalità richieste nelle regioni selezionate di un'architettura multicloud

Per ulteriori informazioni sulle altre considerazioni relative alla portabilità del carico di lavoro, al trasferimento dei dati e agli aspetti di sicurezza, consulta Altre considerazioni.

Progetta una strategia di architettura ibrida e multi-cloud

Dopo aver chiarito le specifiche degli scopi commerciali e tecnici con i requisiti aziendali associati (e aver chiarito e concordato una dichiarazione di visione), puoi elaborare 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 crei una strategia, prendi in considerazione gli obiettivi commerciali, ottieni il consenso, crea un piano di alto livello e utilizzalo per definire la tua strategia.

Per aiutarti a determinare gli scopi e le esigenze tecniche della tua architettura ibrida o multi-cloud, i passaggi del diagramma di flusso precedente iniziano con i requisiti e gli scopi aziendali. Il modo in cui implementi la tua strategia può variare in base agli obiettivi, ai fattori di stimolo e al 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, come descritto in Eseguire la migrazione a Google Cloud.

Percorso di migrazione con quattro fasi.

Questa sezione fornisce indicazioni sulle fasi "Valuta", "Pianifica", "Esegui il deployment" e "Ottimizza" nel diagramma precedente. Presenta queste informazioni nel contesto di una migrazione ibrida o multi-cloud. Devi allineare qualsiasi migrazione alle linee guida e alle best practice descritte nella sezione sul percorso di migrazione della guida Esegui la migrazione a Google Cloud . Queste fasi potrebbero essere applicate a ciascun carico di lavoro singolarmente, non a tutti 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, prendi in considerazione gli obiettivi descritti nei documenti di pianificazione della visione e della strategia. Scegli un piano di migrazione identificando innanzitutto un elenco di carichi di lavoro candidati che potrebbero trarre vantaggio dall'esecuzione o dalla migrazione nel cloud pubblico.

Per iniziare, scegli un carico di lavoro non fondamentale per l'attività o troppo difficile da eseguire la migrazione (con dipendenze minime o nulle da qualsiasi carico di lavoro in altri ambienti), ma abbastanza tipico da fungere da modello per i prossimi implementazioni o migrazioni.

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 la valutazione di vari aspetti delle applicazioni e dell'infrastruttura, tra cui:

  • 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 relativi alla privacy dei dati, ai requisiti di conformità, alla coerenza e alle soluzioni in più ambienti cloud. I rischi identificati possono influire sui carichi di lavoro di cui scegli di eseguire la migrazione o l'utilizzo.

Esistono diversi tipi di strumenti, come il Centro di migrazione di Google Cloud, che ti aiutano a valutare i workload esistenti. Per ulteriori informazioni, consulta Migrazione a Google Cloud: scegliere uno strumento di valutazione.

Dal punto di vista della modernizzazione dei carichi di lavoro, lo strumento di valutazione di idoneità aiuta a valutare un carico di lavoro VM per determinare se è idoneo per la modernizzazione in un contenitore 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. Sviluppare una strategia di migrazione con priorità che definisce i percorsi e le ondate di migrazione delle applicazioni.
  2. Identifica il modello 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, devi incorporare il pattern di rete cloud con il design della landing zone. Il design della landing zone funge da elemento di base 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 del design della zona di destinazione.

Una landing zone può essere composta da applicazioni diverse, ciascuna con un pattern di architettura di rete diverso. Inoltre, in questa fase è importante decidere il design della Google Cloud gerarchia di organizzazioni, progetti e risorse per preparare la zona di destinazione dell'ambiente cloud all'integrazione e al deployment ibridi o multi-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 nelle pagine successive di questa guida. È trattato anche 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. Allinea li al workload candidato di cui prevedi di eseguire la migrazione. Quindi, sviluppa un piano di wave di migrazione per le applicazioni. Il piano deve includere i requisiti stimati per le dimensioni delle risorse che hai stabilito 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 multi-cloud prevista.
  • Scegli un archetipo di deployment adatto per eseguire il deployment del tuo carico di lavoro, ad esempio zonale, regionale, multiregionale o globale, per il pattern di architettura scelto. L'archetipo selezionato costituisce la base per la costruzione delle architetture di deployment specifiche per l'applicazione, personalizzate in base alle tue esigenze tecniche e aziendali.
  • Decidi 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 è avere l'architettura ibrida come configurazione a breve termine.
  • Definisci gli SLA e i 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 aiutarti a pianificare una migrazione efficace e ridurre al minimo i rischi associati.

Fase di deployment

Nella fase 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 carichi di lavoro in base alle ondate 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 calcolo. Per facilitare il modello di comunicazione richiesto per la tua architettura ibrida o multicloud, basa il deployment sul design selezionato e sul tipo di connettività di rete, nonché sul pattern di networking applicabile. Ti consigliamo di adottare questo approccio per la decisione complessiva sul design della landing zone.

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

Fase di ottimizzazione

Nella fase Ottimizza, testa il deployment: al termine dei test, se l'applicazione o il servizio soddisfa le aspettative relative alla funzionalità e alla capacità di rendimento, puoi passare alla produzione. Gli 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 saperne di più, consulta la pagina Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente. Per scoprire di più su come progettare questi strumenti per un'architettura ibrida o multi-cloud, consulta Modelli di monitoraggio e logging ibridi e multi-cloud.

Valutare i carichi di lavoro candidati

La scelta degli ambienti di calcolo per carichi di lavoro diversi influisce notevolmente sul successo di una strategia ibrida e multi-cloud. Le decisioni relative al posizionamento dei carichi di lavoro devono essere in linea con obiettivi commerciali specifici. Pertanto, queste decisioni devono essere guidate da casi d'uso aziendali mirati che consentano effetti aziendali misurabili. Tuttavia, iniziare con il carico di lavoro/l'applicazione più importante per l'attività non è sempre necessario né consigliato. Per ulteriori informazioni, consulta la sezione Scegliere le app di cui eseguire prima la migrazione nella guida Esegui la migrazione a Google Cloud .

Come discusso nella sezione Fattori aziendali e tecnici, 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 di migrazione nel contesto di un'architettura ibrida o multicloud con opportunità di avere un effetto misurabile sull'attività:

  • Potenziale di differenziazione o innovazione sul mercato reso possibile dall'utilizzo di servizi cloud per attivare determinate funzionalità o funzioni aziendali, come le funzionalità di intelligenza artificiale che utilizzano i dati on-premise esistenti per addestrare i 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 sito di ripristino di emergenza (RE) nel cloud.
  • Potenziale accelerazione dei processi di sviluppo e rilascio, ad esempio la creazione di 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 i deployment in cloud pubblico o con i deployment per un nuovo o un secondo provider cloud.
  • 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 la data di creazione dell'applicazione.
  • Il numero di dipendenze con altre applicazioni e servizi in diversi ambienti di calcolo.
  • Eventuali limitazioni imposte 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 assegnarli una priorità e a definire le ondate di migrazione e gli approcci. In seguito, puoi identificare i pattern di architettura applicabili e i pattern di networking di supporto. Questo passaggio potrebbe richiedere più iterazioni, perché la valutazione potrebbe cambiare nel tempo. Pertanto, vale la pena rivalutare i carichi di lavoro dopo aver eseguito i primi implementazioni nel cloud.

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

Questo documento fornisce indicazioni su approcci e considerazioni comuni e comprovati per eseguire la migrazione del tuo carico di lavoro nel cloud. Espande le indicazioni riportate in Creare una strategia di architettura ibrida e multi-cloud, che illustra diversi passaggi possibili e consigliati per progettare una strategia per l'adozione di un'architettura ibrida o multi-cloud.

Cloud-first

Un modo comune per iniziare a utilizzare il cloud pubblico è l'approccio cloud-first. In questo approccio, esegui il deployment dei nuovi carichi di lavoro nel cloud pubblico, mentre i carichi di lavoro esistenti rimangono invariati. In questo caso, valuta la possibilità di un deployment classico in un ambiente di calcolo privato solo se un deployment in 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) le complessità della migrazione dei carichi di lavoro esistenti.

Sebbene un approccio cloud-first possa offrire determinati vantaggi, potrebbe potenzialmente comportare opportunità perse per migliorare o utilizzare i carichi di lavoro esistenti. I nuovi carichi di lavoro potrebbero rappresentare una frazione dell'intero panorama IT e il loro effetto sulle spese e sulle prestazioni 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 sostanziali rispetto al tentativo di adattare un nuovo carico di lavoro all'ambiente cloud.

Inoltre, seguire un approccio cloud-first rigoroso rischia di aumentare la complessità complessiva del tuo ambiente IT. Questo approccio potrebbe creare ridondanze, ridurre il rendimento a causa di una potenziale comunicazione eccessiva tra ambienti o generare un ambiente di calcolo non adatto al singolo carico di lavoro. Inoltre, la conformità alle normative di settore e alle leggi sulla privacy dei dati può limitare le aziende nella migrazione di determinate applicazioni che contengono dati sensibili.

Tenendo conto di questi rischi, ti consigliamo di utilizzare un approccio cloud-first solo per carichi di lavoro selezionati. L'utilizzo di un approccio cloud-first ti consente di concentrarti sui carichi di lavoro che possono trarre il massimo vantaggio da un deployment o una migrazione nel cloud. Questo approccio prende in considerazione anche la modernizzazione dei carichi di lavoro esistenti.

Un esempio comune di architettura ibrida cloud-first è quando le applicazioni e i servizi legacy che contengono dati critici devono essere integrati con nuovi dati o applicazioni. Per completare l'integrazione, puoi utilizzare un'architettura ibrida che modernizza i servizi legacy utilizzando interfacce API, che li sblocca per il consumo da parte di nuovi servizi e applicazioni cloud. Con una piattaforma di gestione delle API cloud, come Apigee, puoi implementare questi casi d'uso con modifiche minime all'applicazione e aggiungere sicurezza, analisi e scalabilità ai servizi legacy.

Migrazione e modernizzazione

Il multicloud ibrido e la modernizzazione IT sono concetti distinti collegati in un circolo virtuoso. L'utilizzo del cloud pubblico può agevolare e semplificare la modernizzazione dei carichi di lavoro IT. La modernizzazione dei carichi di lavoro IT può aiutarti a ottenere di più dal cloud.

Gli obiettivi principali della modernizzazione dei workload sono i seguenti:

  • Ottieni una maggiore agilità per adattarti ai requisiti in evoluzione.
  • 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 contemporaneamente tutte le applicazioni nel processo di migrazione. Come descritto in Migrazione a Google Cloud, puoi implementare uno dei seguenti tipi di migrazione o anche combinarne più di uno, se necessario:

  • Rehosting (lift and shift)
  • Replatforming (trasferimento e ottimizzazione)
  • Refactoring (sposta e migliora)
  • Riprogettazione dell'architettura (continua a modernizzare)
  • Ricostruisci (rimuovi e sostituisci, a volte chiamata elimina e sostituisci)
  • Riacquisto

Quando prendi decisioni strategiche sulle tue architetture ibride e multicloud, è importante valutare la fattibilità della tua strategia dal punto di vista dei costi e dei tempi. Ti consigliamo di prendere in considerazione un approccio di migrazione graduale, iniziando con il sollevamento e lo spostamento o il cambio di piattaforma 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 sono in esecuzione nel cloud, è più facile utilizzare e integrare i servizi cloud per ottimizzarli ulteriormente utilizzando architetture e funzionalità cloud-first. Inoltre, queste applicazioni possono comunque comunicare con altri ambienti tramite una connessione di rete ibrida.

Ad esempio, puoi eseguire il refactoring o la riprogettazione di un'applicazione monolitica di grandi dimensioni basata su VM e trasformarla in diversi microservizi indipendenti, in base a un'architettura di microservizi basata su cloud. In questo esempio, 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 è supportata così com'è nell'ambiente cloud di destinazione, ti consigliamo di iniziare con il replatforming, il refactoring o la riprogettazione della tua strategia di migrazione per superare questi vincoli, se possibile.

Quando utilizzi uno di questi approcci di migrazione, valuta la possibilità di modernizzare le tue applicazioni (se applicabile e fattibile). La modernizzazione può richiedere l'adozione e l'implementazione di principi di Site Reliability Engineering (SRE) o DevOps, pertanto potrebbe essere necessario estendere la modernizzazione delle applicazioni al tuo ambiente privato in una configurazione ibrida. Anche se l'implementazione dei principi SRE prevede l'ingegneria come elemento fondamentale, si tratta più di un processo di trasformazione che di una sfida tecnica. Di conseguenza, è probabile che richieda modifiche procedurali e culturali. Per scoprire di più su come il primo passo per implementare SRE in un'organizzazione sia ottenere l'approvazione del management, consulta Con SRE, non pianificare significa pianificare di fallire.

Combinare approcci di migrazione

Ogni approccio alla migrazione discusso qui presenta determinati punti di forza e di debolezza. Un vantaggio chiave dell'adozione di una strategia ibrida e multi-cloud è che non è necessario optare per un unico approccio. Puoi invece decidere quale approccio è più adatto per ogni carico di lavoro o stack di applicazioni, come mostrato nel seguente diagramma.

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

Questo diagramma concettuale illustra i vari percorsi o approcci di migrazione e modernizzazione che possono essere applicati contemporaneamente a carichi di lavoro diversi, in base ai requisiti tecnici, agli obiettivi e alle esigenze aziendali specifici di ciascun carico di lavoro o applicazione.

Inoltre, non è necessario che gli stessi componenti dello stack dell'applicazione seguano la stessa strategia o lo stesso approccio di migrazione. Ad esempio:

  • Il database on-premise di backend di un'applicazione può essere sottoposto a una nuova piattaforma da MySQL auto-hosted a un database gestito utilizzando Cloud SQL in Google Cloud.
  • Le macchine virtuali frontend dell'applicazione possono essere sottoposte a refactoring per essere eseguite su contenitori utilizzando GKE Autopilot, in cui Google gestisce la configurazione del cluster, inclusi nodi, scalabilità, sicurezza e altre impostazioni preconfigurate.
  • La soluzione di bilanciamento del carico hardware on-premise e le funzionalità WAF del firewall delle applicazioni web possono essere sostituite con il Bilanciatore del carico di Google Cloud e Google Cloud Armor.

Scegli il rehosting (lift and shift) se una delle seguenti condizioni è vera per i carichi di lavoro:

  • Hanno un numero relativamente ridotto di dipendenze dal loro ambiente.
  • Non sono considerati meritevoli di refactoring o il refactoring prima della migrazione non è fattibile.
  • Si basano su software di terze parti.

Valuta la possibilità di eseguire il refactoring (sposta e migliora) per questi tipi di workload:

  • Hanno dipendenze che devono essere slegate.
  • Si basano su sistemi operativi, hardware o database che non possono essere supportati nel cloud.
  • Non utilizzano in modo efficiente le risorse di calcolo o di archiviazione.
  • Non possono essere implementati in modo automatico senza un certo impegno.

Valuta se la ricostruzione (rimozione e sostituzione) soddisfa le tue esigenze per questi tipi di carichi di lavoro:

  • Non soddisfano più i requisiti attuali.
  • Possono essere incorporate in altre applicazioni che forniscono funzionalità simili senza compromettere i requisiti aziendali.
  • Si basano su una tecnologia di terze parti che ha raggiunto la fine del suo ciclo di vita.
  • Richiedono tariffe di licenza di terze parti non più convenienti.

Il programma di migrazione rapida mostra in che modo 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 mette in evidenza le considerazioni di progettazione di base che svolgono un ruolo fondamentale nella definizione dell'architettura ibrida e multi-cloud complessiva. Analizza e valuta in modo olistico queste considerazioni nell'intera architettura della soluzione, includendo tutti i carichi di lavoro, non solo quelli specifici.

Refactor

In una migrazione di refactoring, modifichi i carichi di lavoro per sfruttare le funzionalità del cloud, non solo per farli funzionare nel nuovo ambiente. Puoi migliorare ogni carico di lavoro in termini di prestazioni, funzionalità, costi ed esperienza utente. Come evidenziato in Refactor: 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, in particolare se il tuo obiettivo è creare un'architettura ibrida come architettura mirata a lungo termine:

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

Per funzionare bene, questo approccio in genere richiede determinati investimenti in infrastrutture e strumenti on-premise. Ad esempio, configurare un Container Registry locale ed eseguire il provisioning di cluster Kubernetes per containerizzare le applicazioni. La versione Enterprise di Google Kubernetes Engine (GKE) può essere utile in questo approccio per gli ambienti ibridi. Ulteriori informazioni su GKE Enterprise sono riportate 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 multi-cloud, potresti voler spostare i carichi di lavoro tra gli ambienti di calcolo che ospitano i tuoi dati. Per contribuire a abilitare il trasferimento senza problemi dei carichi di lavoro tra gli ambienti, prendi in considerazione i seguenti fattori:

  • Puoi spostare un'applicazione da un ambiente di calcolo all'altro senza modificarla in modo significativo e il relativo modello operativo:
    • Il deployment e la gestione delle applicazioni sono coerenti tra gli ambienti di calcolo.
    • Visibilità, configurazione e sicurezza sono coerenti tra gli ambienti di calcolo.
  • La possibilità di rendere un carico di lavoro portabile non deve essere in conflitto con il fatto che il carico di lavoro sia cloud-first.

Automazione dell'infrastruttura

L'automazione dell'infrastruttura è essenziale per la portabilità nelle architetture ibridhe e multi-cloud. Un approccio comune per automatizzare la creazione dell'infrastruttura è tramite Infrastructure as Code (IaC). L'IaC prevede la gestione dell'infrastruttura in 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 molto utilizzato per definire le risorse di infrastruttura in un file. Terraform consente inoltre di automatizzare la creazione di queste risorse in ambienti eterogenei.

Per ulteriori informazioni sulle funzioni di base di Terraform che possono aiutarti a automatizzare il provisioning e la gestione Google Cloud delle risorse, consulta Modelli e moduli Terraform per Google Cloud.

Puoi utilizzare strumenti di gestione della configurazione come Ansible, Puppet o Chef per stabilire una procedura 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 tra gli ambienti.

In base a questi strumenti, puoi assemblare una catena di strumenti comune come illustrato nel seguente diagramma logico. Questa catena di strumenti comuni rimuove le differenze tra gli ambienti di calcolo. Inoltre, ti consente di unificare il provisioning, il deployment, la gestione e il monitoraggio.

Una catena di strumenti consente la portabilità delle applicazioni.

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

  • L'utilizzo delle VM come base comune può rendere difficile l'implementazione di applicazioni cloud-first. Inoltre, l'utilizzo esclusivo di VM può impedirti di utilizzare i servizi gestiti nel cloud. Potresti perdere opportunità per ridurre il carico amministrativo.
  • La creazione e la gestione di una catena di strumenti comuni comportano costi operativi e di overhead.
  • Man mano che la catena di strumenti si espande, può sviluppare complessità uniche personalizzate in base alle esigenze specifiche della tua azienda. Questa maggiore complessità può contribuire all'aumento dei costi di formazione.

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

Ad esempio, puoi utilizzare il modello di risorse Kubernetes per automatizzare la creazione di cluster Kubernetes utilizzando un approccio di configurazione declarative. 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 il modello di risorse Kubernetes) in modo che siano portabili al momento della pubblicazione.

Puoi anche valutare la possibilità di automatizzare la creazione dei progetti e delle risorse al loro interno. Questa automazione può aiutarti ad adottare un approccio Infrastructure as Code per il provisioning dei progetti.

Container e Kubernetes

L'utilizzo delle funzionalità gestite dal cloud consente di ridurre la complessità di creazione e gestione di una catena di strumenti personalizzata per ottenere l'automazione e la portabilità dei carichi di lavoro. Tuttavia, l'utilizzo esclusivo delle VM come base comune rende difficile implementare applicazioni veramente cloud-first. Una soluzione è utilizzare i container e Kubernetes.

I container consentono al software di funzionare in modo affidabile quando lo sposti da un ambiente all'altro. Poiché i container separano le applicazioni dall'infrastruttura dell'host sottostante, facilitano il deployment in ambienti di calcolo, come ibridi e multi-cloud.

Kubernetes gestisce l'orchestrazione, il deployment, la scalabilità e la gestione delle tue 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 su molti ambienti di calcolo, puoi utilizzarlo anche per stabilire un livello di runtime comune in tutti gli ambienti di calcolo:

  • Kubernetes fornisce gli stessi servizi e API in un ambiente di calcolo privato o cloud. Inoltre, il livello di astrazione è molto più elevato rispetto al lavoro con le VM, il che in genere si traduce in una preparazione meno impegnativa e in una maggiore produttività degli sviluppatori.
  • A differenza di una catena di strumenti personalizzata, Kubernetes è ampiamente adottato sia per lo sviluppo sia per la gestione delle applicazioni, quindi puoi sfruttare le competenze, la documentazione e l'assistenza di terze parti esistenti.
  • Kubernetes supporta tutte le implementazioni dei container che:

Quando un carico di lavoro è in esecuzione su Google Cloud, puoi evitare la fatica di installare e utilizzare Kubernetes utilizzando una piattaforma Kubernetes gestita come Google Kubernetes Engine (GKE). In questo modo, il personale addetto alle operazioni può spostare il proprio focus 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, tieni conto dei tuoi requisiti di scalabilità e dei relativi limiti di scalabilità.

Tecnicamente, puoi installare ed eseguire Kubernetes su molti ambienti di calcolo per stabilire un livello di runtime comune. Tuttavia, in pratica, la creazione e il funzionamento di un'architettura di questo tipo possono creare complessità. L'architettura diventa ancora più complessa quando è necessario un controllo della sicurezza a livello di contenitore (mesh di servizi).

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

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

Diagramma di stack che mostra le opportunità di gestione del parco risorse offerte da GKE Enterprise.

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

  • Progetta e crea esperienze cloud-like on-premise o soluzioni unificate per la transizione delle applicazioni all'ambiente ibrido GKE Enterprise. Per ulteriori informazioni, consulta la 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 inoltre raggruppamenti logici di ambienti simili con sicurezza, configurazione e gestione dei servizi coerenti. Ad esempio, GKE Enterprise supporta l'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 ambienti tramite comunicazioni service-to-service sicure mTLS end-to-end.

Considerazioni sulla portabilità del carico di lavoro

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

  • Un'applicazione potrebbe essere portabile in un ambiente diverso con modifiche minime, ma ciò non significa che funzioni ugualmente bene in entrambi gli ambienti.
    • Le differenze nelle funzionalità di sicurezza dell'infrastruttura o di calcolo di base o nell'infrastruttura di rete, insieme alla vicinanza ai servizi dipendenti, potrebbero portare a prestazioni notevolmente diverse.
  • Lo spostamento di un carico di lavoro tra ambienti di calcolo potrebbe anche richiedere di spostare i dati.
    • Ambienti diversi possono avere servizi e strutture di archiviazione e gestione dei dati diversi.
  • Il comportamento e le prestazioni dei bilanciatori del carico di cui è stato eseguito il provisioning con Kubernetes o GKE Enterprise potrebbero variare da un ambiente all'altro.

Spostamento dei dati

Poiché può essere complesso spostare, condividere e accedere ai dati su larga scala tra ambienti di calcolo, le aziende di livello enterprise potrebbero esitare a creare un'architettura ibrida o multi-cloud. Questa esitazione potrebbe aumentare se già archiviano la maggior parte dei 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 consentono alle imprese di archiviare, condividere e accedere ai dati in ambienti diversi in modo da soddisfare i loro casi d'uso specifici. Questa capacità semplifica in definitiva la possibilità per i responsabili delle decisioni aziendali e tecnologiche di adottare architetture ibride e multicloud.

Il movimento dei dati è un aspetto importante per la strategia ibrida e multi-cloud e per la pianificazione dell'architettura. Il tuo team deve identificare i diversi casi d'uso della tua attività e i dati che li supportano. Devi anche considerare il tipo di archiviazione, la capacità, l'accessibilità e le opzioni di movimento.

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

Per esaminare la procedura, dalla pianificazione di un trasferimento dati all'utilizzo delle best practice durante l'implementazione di un piano, consulta Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni.

Sicurezza

Quando le organizzazioni adottano architetture ibride e multi-cloud, la loro superficie di attacco può aumentare a seconda del modo in cui i sistemi e i dati sono distribuiti in ambienti diversi. Se combinato con il panorama delle minacce in continua evoluzione, l'aumento delle superfici di attacco può comportare 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 possibile o fattibile estendere gli approcci di sicurezza on-premise al cloud. Tuttavia, molte delle funzionalità di sicurezza di rete delle appliance hardware sono funzionalità cloud-first e operano in modo distribuito. Per ulteriori informazioni sulle funzionalità di sicurezza della 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 provider di cloud pubblico ha il proprio approccio alla sicurezza, inclusi modelli diversi, best practice, funzionalità di sicurezza dell'infrastruttura e delle applicazioni, obblighi di conformità e persino i nomi dei servizi di sicurezza. Queste incoerenze possono aumentare il rischio per la sicurezza. Inoltre, il modello di responsabilità condivisa di ciascun provider cloud può essere diverso. È essenziale identificare e comprendere la delimitazione esatta delle responsabilità in un'architettura multicloud.

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

Per ottenere la visibilità e la postura completa 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 la sezione 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 Cloud, nonché per aiutarti a pianificare e progettare la tua soluzione cloud per raggiungere i tuoi obiettivi di sicurezza e conformità, esplora il Google Cloud Security Best Practice Center e il Enterprise Foundations Blueprint.

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 ulteriori informazioni, visita il Google Cloud Centro risorse per la conformità. Di seguito sono riportati alcuni dei principali approcci consigliati per progettare un'architettura ibrida e multi-cloud sicura:

  • Sviluppare una strategia e un'architettura di sicurezza cloud unificate e personalizzate. Le strategie di sicurezza ibride e multicloud devono essere personalizzate in base alle esigenze e agli scopi specifici della tua organizzazione.

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

  • Valuta la possibilità di adottare un'architettura di sicurezza unificata negli ambienti ibridi e multi-cloud.

  • Standardizzare la progettazione e i deployment del cloud, in particolare la progettazione e le funzionalità di sicurezza. In questo modo, puoi migliorare l'efficienza e consentire una governance e 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. Dovrebbe anche cercare di migliorare continuamente la propria strategia di sicurezza.

  • Valuta la possibilità di utilizzare la gestione della strategia di sicurezza del cloud (CSPM) per identificare e rimediare a errori di configurazione della sicurezza e minacce alla cybersicurezza. La CSPM fornisce inoltre valutazioni delle vulnerabilità in ambienti ibridi e multi-cloud.

Security Command Center è una soluzione integrata di sicurezza e gestione dei rischi per Google Cloud che aiuta a identificare errori di configurazione e vulnerabilità e altro ancora. Security Health Analytics è uno strumento di scansione per la valutazione delle vulnerabilità gestita. 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 risolverli.

Mandiant Attack Surface Management per Google Cloud consente alla tua organizzazione di vedere meglio le risorse del proprio ambiente cloud ibrido o multi-cloud. Rileva automaticamente gli asset di diversi fornitori di servizi cloud, DNS e della superficie di attacco esterna estesa per offrire alla tua azienda una comprensione più approfondita del proprio ecosistema. Utilizza queste informazioni per dare la priorità alla correzione delle vulnerabilità e delle esposizioni che presentano il rischio maggiore.

  • Soluzione SIEM (Security Information and Event Management) 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 ti aiuta a fornire gestione degli eventi e delle informazioni di sicurezza raccogliendo, analizzando, rilevando ed esaminando tutti i tuoi dati di sicurezza in un unico posto.

Crea architetture ibride e multi-cloud utilizzando Google Cloud: Novità