Questo documento è il secondo di un insieme di tre documenti. Vengono descritti i modelli di architettura ibrida e multi-cloud comuni. Descrive inoltre gli scenari per cui questi pattern sono più adatti. Infine, fornisce le best practice che puoi utilizzare quando implementi queste architetture in Google Cloud.

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

• Crea architetture ibride e multi-cloud: descrive la pianificazione di una strategia per la progettazione di una configurazione ibrida e multi-cloud con Google Cloud.
• Modelli di architettura ibrida e multi-cloud: descrive i modelli di architettura comuni da adottare nell'ambito di una strategia ibrida e multi-cloud (questo documento).
• Modelli di architettura di rete sicura ibrida e multi-cloud: vengono illustrati i modelli di architettura di rete ibrida e multi-cloud da una prospettiva di rete.

Ogni azienda ha un portafoglio unico di carichi di lavoro delle applicazioni che impongono requisiti e vincoli all'architettura di una configurazione ibrida o multi-cloud. Sebbene tu debba progettare e personalizzare l'architettura per soddisfare questi vincoli e requisiti, puoi fare affidamento su alcuni pattern comuni per definire l'architettura di base.

Un pattern architetturale è un modo ripetibile per strutturare più componenti funzionali di una soluzione tecnologica, un'applicazione o un servizio per creare una soluzione riutilizzabile che soddisfi determinati requisiti o casi d'uso. Una soluzione tecnologica basata sul cloud è spesso costituita da diversi servizi cloud distinti e distribuiti. Questi servizi collaborano per fornire le funzionalità richieste. In questo contesto, ogni servizio è considerato un componente funzionale della soluzione tecnologica. Analogamente, un'applicazione può essere costituita da più livelli, moduli o servizi funzionali e ognuno può rappresentare un componente funzionale dell'architettura dell'applicazione. Questa architettura può essere standardizzata per rispondere a casi d'uso aziendali specifici e fungere da modello di base riutilizzabile.

Per definire in generale un pattern architetturale per un'applicazione o una soluzione, identifica e definisci quanto segue:

• I componenti della soluzione o dell'applicazione.
• Le funzioni previste per ogni componente, ad esempio le funzioni frontend per fornire una GUI o le funzioni backend per fornire l'accesso ai dati.
• Come i componenti comunicano tra loro e con sistemi esterni o utenti. Nelle applicazioni moderne, questi componenti interagiscono tramite interfacce o API ben definite. Esiste un'ampia gamma di modelli di comunicazione, come asincrono e sincrono, richiesta-risposta o basato su code.

Di seguito sono riportate le due categorie principali di pattern di architettura ibrida e multicloud:

• Pattern di architettura distribuita: Questi pattern si basano su un deployment distribuito di carichi di lavoro o componenti di applicazioni. Ciò significa che eseguono un'applicazione (o componenti specifici di quell'applicazione) nell'ambiente di computing più adatto al pattern. In questo modo, il pattern può sfruttare le diverse proprietà e caratteristiche degli ambienti di computing distribuiti e interconnessi.
• Pattern di architettura ridondanti: Questi pattern si basano su deployment ridondanti di workload. In questi pattern, esegui il deployment delle stesse applicazioni e dei relativi componenti in più ambienti di computing. L'obiettivo è aumentare la capacità o la resilienza di un'applicazione oppure replicare un ambiente esistente per lo sviluppo e il test.

Quando implementi il pattern di architettura che selezioni, devi utilizzare un archetipo di deployment adatto. Gli archetipi di deployment sono zonali, regionali, multiregionali o globali. Questa selezione costituisce la base per la creazione di architetture di deployment specifiche per l'applicazione. Ogni archetipo di deployment definisce una combinazione di domini di errore in cui un'applicazione può operare. Questi domini di errore possono comprendere una o più Google Cloud zone o regioni e possono essere espansi per includere i data center on-premise o i domini di errore in altri fornitori di servizi cloud.

Questa serie contiene le seguenti pagine:

• Pattern di architettura distribuita

  • Pattern ibrido multilivello

  • Pattern multi-cloud partizionato

  • Pattern ibrido e multi-cloud di Analytics

  • Pattern ibrido Edge

• Modelli di architettura ridondanti

  • Pattern ibrido dell'ambiente
  • Pattern ibridi e multi-cloud per la continuità aziendale
  • Pattern di cloud bursting

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

• Saud Albazei | Customer Engineer, modernizzazione delle applicazioni
• Anna Berenberg | Engineering Fellow
• Marco Ferrari | Cloud Solutions Architect
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Cloud Solutions Architect
• Mark Schlagenhauf | Technical Writer, Networking
• Daniel Strebel | EMEA Solution Lead, Application Modernization
• Ammett Williams | Developer Relations Engineer

Pattern di architettura distribuita

Quando esegui la migrazione da un ambiente di computing non ibrido o non multi-cloud a un'architettura ibrida o multi-cloud, considera innanzitutto i vincoli delle tue applicazioni esistenti e come questi vincoli potrebbero causare errori dell'applicazione. Questa considerazione diventa più importante quando le tue applicazioni o i componenti delle applicazioni operano in modo distribuito in ambienti diversi. Dopo aver valutato i tuoi vincoli, sviluppa un piano per evitarli o superarli. Assicurati di considerare le funzionalità uniche di ogni ambiente di computing in un'architettura distribuita.

Considerazioni sulla progettazione

Le seguenti considerazioni sulla progettazione si applicano ai pattern di deployment distribuiti. A seconda della soluzione target e degli scopi commerciali, la priorità e l'effetto di ogni considerazione possono variare.

Latenza

In qualsiasi pattern di architettura che distribuisce i componenti dell'applicazione (frontend, backend o microservizi) in diversi ambienti di computing, può verificarsi una latenza di comunicazione. Questa latenza è influenzata dalla connettività di rete ibrida (Cloud VPN e Cloud Interconnect) e dalla distanza geografica tra il sito on-premise e le regioni cloud o tra le regioni cloud in una configurazione multicloud. Pertanto, è fondamentale valutare i requisiti di latenza delle tue applicazioni e la loro sensibilità ai ritardi di rete. Le applicazioni che possono tollerare la latenza sono candidati più adatti per il deployment distribuito iniziale in un ambiente ibrido o multicloud.

Architettura dello stato temporaneo e finale

Per specificare le aspettative e le potenziali implicazioni per costi, scalabilità e rendimento, è importante analizzare il tipo di architettura necessario e la durata prevista nella fase di pianificazione. Ad esempio, se prevedi di utilizzare un'architettura ibrida o multicloud per un lungo periodo di tempo o in modo permanente, potresti prendere in considerazione l'utilizzo di Cloud Interconnect. Per ridurre i costi di trasferimento dei dati in uscita e ottimizzare le prestazioni di rete della connettività ibrida, Cloud Interconnect sconta gli addebiti per il trasferimento dei dati in uscita che soddisfano le condizioni della tariffa di trasferimento dei dati scontata.

Affidabilità

L'affidabilità è una considerazione importante quando si progettano sistemi IT. La disponibilità di uptime è un aspetto essenziale dell'affidabilità del sistema. In Google Cloud, puoi aumentare la resilienza di un'applicazione eseguendo il deployment dei componenti ridondanti di questa applicazione in più zone di una singola regione¹ o in più regioni, con funzionalità di failover. La ridondanza è uno degli elementi chiave per migliorare la disponibilità complessiva di un'applicazione. Per le applicazioni con una configurazione distribuita in ambienti ibridi e multi-cloud, è importante mantenere un livello di disponibilità coerente.

Per migliorare la disponibilità di un sistema in un ambiente on-premise o in altri ambienti cloud, valuta la ridondanza hardware o software, con meccanismi di failover, necessaria per le tue applicazioni e i relativi componenti. Idealmente, dovresti considerare la disponibilità di un servizio o di un'applicazione nei vari componenti e nell'infrastruttura di supporto (inclusa la disponibilità della connettività ibrida) in tutti gli ambienti. Questo concetto è anche chiamato disponibilità composita di un'applicazione o di un servizio.

In base alle dipendenze tra i componenti o i servizi, la disponibilità composita per un'applicazione potrebbe essere superiore o inferiore a quella di un singolo servizio o componente. Per saperne di più, consulta Disponibilità composita: calcolo della disponibilità complessiva dell'infrastruttura cloud.

Per raggiungere il livello di affidabilità del sistema che desideri, definisci metriche di affidabilità chiare e progetta applicazioni in modo che si ripristinino autonomamente e resistano in modo efficace alle interruzioni nei diversi ambienti. Per aiutarti a definire modi appropriati per misurare l'esperienza cliente dei tuoi servizi, consulta Definisci l'affidabilità in base agli obiettivi dell'esperienza utente.

Connettività ibrida e multi-cloud

I requisiti di comunicazione tra i componenti delle applicazioni distribuite devono influenzare la scelta di un'opzione di connettività di rete ibrida. Ogni opzione di connettività presenta vantaggi e svantaggi, nonché driver specifici da considerare, come costi, volume di traffico, sicurezza e così via. Per saperne di più, consulta la sezione Considerazioni sulla progettazione della connettività.

Gestibilità

Strumenti di gestione e monitoraggio coerenti e unificati sono essenziali per configurazioni ibride e multi-cloud riuscite (con o senza portabilità del carico di lavoro). Nel breve termine, questi strumenti possono aumentare i costi di sviluppo, test e operazioni. Tecnicamente, più provider cloud utilizzi, più complessa diventa la gestione degli ambienti. La maggior parte dei fornitori di servizi cloud pubblico non solo dispone di funzionalità diverse, ma ha anche vari strumenti, SLA e API per la gestione dei servizi cloud. Pertanto, valuta i vantaggi strategici dell'architettura selezionata rispetto alla potenziale complessità a breve termine rispetto ai vantaggi a lungo termine.

Costo

Ogni provider di servizi cloud in un ambiente multicloud ha metriche e strumenti di fatturazione propri. Per fornire una migliore visibilità e dashboard unificate, valuta la possibilità di utilizzare strumenti di gestione e ottimizzazione dei costi multicloud. Ad esempio, quando crei soluzioni cloud-first in più ambienti cloud, i prodotti, i prezzi, gli sconti e gli strumenti di gestione di ciascun provider possono creare incoerenze di costo tra questi ambienti.

Ti consigliamo di utilizzare un metodo unico e ben definito per calcolare i costi totali delle risorse cloud e di fornire visibilità sui costi. La visibilità dei costi è essenziale per l'ottimizzazione dei costi. Ad esempio, combinando i dati di fatturazione dei provider cloud che utilizzi e utilizzando il Google Cloud blocco di gestione dei costi cloud di Looker, puoi creare una visualizzazione centralizzata dei costi multicloud. Questa visualizzazione può aiutarti a fornire una visualizzazione consolidata dei report della spesa su più cloud. Per ulteriori informazioni, consulta La strategia per ottimizzare in modo efficace la gestione dei costi di fatturazione Cloud.

Ti consigliamo inoltre di utilizzare la pratica FinOps per rendere visibili i costi. Nell'ambito di una solida pratica FinOps, un team centrale può delegare il processo decisionale per l'ottimizzazione delle risorse a qualsiasi altro team coinvolto in un progetto per incoraggiare la responsabilità individuale. In questo modello, il team centrale deve standardizzare il processo, i report e gli strumenti per l'ottimizzazione dei costi. Per saperne di più sui diversi aspetti dell'ottimizzazione dei costi e sui consigli da prendere in considerazione, consulta Google Cloud Well-Architected Framework: ottimizzazione dei costi.

Spostamento dei dati

Lo spostamento dei dati è un aspetto importante da considerare per la pianificazione della strategia e dell'architettura ibrida e multi-cloud, soprattutto per i sistemi distribuiti. Le aziende devono identificare i diversi casi d'uso aziendali, i dati che li alimentano e la modalità di classificazione dei dati (per i settori regolamentati). Devono anche valutare in che modo l'archiviazione, la condivisione e l'accesso ai dati per i sistemi distribuiti nei vari ambienti potrebbero influire sulle prestazioni delle applicazioni e sulla coerenza dei dati. Questi fattori potrebbero influenzare l'applicazione e l'architettura della pipeline di dati. Il set completo diGoogle Cloudopzioni di spostamento dei dati consente alle aziende di soddisfare le proprie esigenze specifiche e adottare architetture ibride e multicloud senza compromettere semplicità, efficienza o prestazioni.

Sicurezza

Quando esegui la migrazione delle applicazioni al cloud, è importante considerare le funzionalità di sicurezza cloud-first come coerenza, osservabilità e visibilità unificata della sicurezza. Ogni provider di servizi cloud pubblico ha il proprio approccio, le proprie best practice e le proprie funzionalità per la sicurezza. È importante analizzare e allineare queste funzionalità per creare un'architettura di sicurezza standard e funzionale. Anche controlli IAM efficaci, crittografia dei dati, analisi delle vulnerabilità e conformità alle normative di settore sono aspetti importanti della sicurezza del cloud.

Quando pianifichi una strategia di migrazione, ti consigliamo di analizzare le considerazioni menzionate in precedenza. Possono aiutarti a ridurre al minimo le possibilità di introdurre complessità nell'architettura man mano che le tue applicazioni o i volumi di traffico aumentano. Inoltre, la progettazione e la creazione di una landing zone sono quasi sempre un prerequisito per il deployment di carichi di lavoro aziendali in un ambiente cloud. Una zona di destinazione aiuta la tua azienda a eseguire il deployment, utilizzare e scalare i servizi cloud in modo più sicuro in più aree e include diversi elementi, come identità, gestione delle risorse, sicurezza e networking. Per maggiori informazioni, consulta Progettazione della landing zone in Google Cloud.

I seguenti documenti di questa serie descrivono altri pattern di architettura distribuita:

• Pattern ibrido multilivello
• Pattern multi-cloud partizionato
• Pattern ibrido e multi-cloud di Analytics
• Pattern ibrido Edge

Pattern ibrido multilivello

I componenti dell'architettura di un'applicazione possono essere classificati come frontend o backend. In alcuni scenari, questi componenti possono essere ospitati per operare da ambienti di computing diversi. Nell'ambito del pattern di architettura ibrida a livelli, gli ambienti di computing si trovano in un ambiente di computing privato on-premise e in Google Cloud.

I componenti dell'applicazione frontend sono esposti direttamente agli utenti finali o ai dispositivi. Di conseguenza, queste applicazioni sono spesso sensibili alle prestazioni. Per sviluppare nuove funzionalità e miglioramenti, gli aggiornamenti software possono essere frequenti. Poiché le applicazioni frontend in genere si basano su applicazioni backend per archiviare e gestire i dati e, possibilmente, la logica di business e l'elaborazione dell'input utente dell'utente, sono spesso senza stato o gestiscono solo volumi limitati di dati.

Per renderle accessibili e utilizzabili, puoi creare le tue applicazioni frontend con vari framework e tecnologie. Alcuni fattori chiave per un'applicazione frontend di successo includono le prestazioni dell'applicazione, la velocità di risposta e la compatibilità del browser.

I componenti dell'applicazione di backend in genere si concentrano sull'archiviazione e sulla gestione dei dati. In alcune architetture, la logica di business potrebbe essere incorporata nel componente di backend. Le nuove release delle applicazioni di backend tendono a essere meno frequenti rispetto a quelle delle applicazioni di frontend. Le applicazioni di backend presentano le seguenti sfide da gestire:

• Gestione di un volume elevato di richieste
• Gestione di un volume elevato di dati
• Protezione dei dati
• Mantenere dati aggiornati e attuali in tutte le repliche del sistema

La soluzione di app web a tre livelli è una delle implementazioni più diffuse per la creazione di applicazioni web aziendali, come siti web di e-commerce contenenti diversi componenti dell'applicazione. Questa architettura contiene i seguenti livelli. Ogni livello opera in modo indipendente, ma sono strettamente collegati e funzionano tutti insieme.

• Livello di frontend web e presentazione
• Livello di applicazione
• Livello di accesso ai dati o backend

L'inserimento di questi livelli nei container separa le loro esigenze tecniche, come i requisiti di scalabilità, e ne facilita la migrazione in un approccio graduale. Inoltre, ti consente di eseguirne il deployment su servizi cloud indipendenti dalla piattaforma che possono essere portati in diversi ambienti, utilizzare la gestione automatica e scalare con piattaforme gestite dal cloud, come Cloud Run o Google Kubernetes Engine (GKE) Enterprise. Inoltre, i database gestiti daGoogle Cloud come Cloud SQL contribuiscono a fornire il backend come livello di database.

Il pattern di architettura ibrida a livelli si concentra sul deployment dei componenti dell'applicazione frontend esistenti nel cloud pubblico. In questo pattern, mantieni tutti i componenti dell'applicazione backend esistenti nel loro ambiente di computing privato. A seconda delle dimensioni e del design specifico dell'applicazione, puoi migrare i componenti dell'applicazione frontend caso per caso. Per maggiori informazioni, vedi Eseguire la migrazione a Google Cloud.

Se hai un'applicazione esistente con componenti di backend e frontend ospitati nel tuo ambiente on-premise, considera i limiti della tua architettura attuale. Ad esempio, man mano che la tua applicazione viene scalata e aumentano le esigenze di prestazioni e affidabilità, dovresti iniziare a valutare se alcune parti dell'applicazione devono essere sottoposte a refactoring o spostate in un'architettura diversa e più ottimale. Il pattern di architettura ibrida a livelli ti consente di trasferire alcuni carichi di lavoro e componenti dell'applicazione al cloud prima di eseguire una transizione completa. È inoltre essenziale considerare i costi, il tempo e i rischi connessi a una migrazione di questo tipo.

Il seguente diagramma mostra un tipico pattern di architettura ibrida a più livelli.

Nel diagramma precedente, le richieste client vengono inviate al frontend dell'applicazione ospitato in Google Cloud. A sua volta, il frontend dell'applicazione invia i dati all'ambiente on-premise in cui è ospitato il backend dell'applicazione (idealmente tramite un gateway API).

Con il pattern di architettura ibrida a livelli, puoi sfruttare l'infrastruttura e i servizi globali diGoogle Cloud , come mostrato nell'architettura di esempio nel diagramma seguente. È possibile raggiungere il frontend dell'applicazione tramite Google Cloud. Può anche aggiungere elasticità al frontend utilizzando lo scalabilità automatica per rispondere in modo dinamico ed efficiente alla domanda di scalabilità senza eseguire il provisioning eccessivo dell'infrastruttura. Esistono diverse architetture che puoi utilizzare per creare ed eseguire app web scalabili su Google Cloud. Ogni architettura presenta vantaggi e svantaggi per requisiti diversi.

Per saperne di più, guarda Tre modi per eseguire app web scalabili su Google Cloud su YouTube. Per scoprire di più sui diversi modi per modernizzare la tua piattaforma di e-commerce su Google Cloud, consulta Come creare una piattaforma per il commercio digitale su Google Cloud.

Nel diagramma precedente, il frontend dell'applicazione è ospitato su Google Cloud per fornire un'esperienza utente multiregionale e ottimizzata a livello globale che utilizza il bilanciamento del carico globale, lo scaling automatico e la protezione DDoS tramite Google Cloud Armor.

Nel tempo, il numero di applicazioni che distribuisci nel cloud pubblico potrebbe aumentare al punto da farti prendere in considerazione lo spostamento dei componenti dell'applicazione di backend nel cloud pubblico. Se prevedi di gestire un traffico elevato, l'utilizzo di servizi gestiti dal cloud potrebbe aiutarti a risparmiare risorse di ingegneria durante la gestione della tua infrastruttura. Prendi in considerazione questa opzione, a meno che vincoli o requisiti non impongano l'hosting on-premise dei componenti dell'applicazione di backend. Ad esempio, se i dati di backend sono soggetti a restrizioni normative, probabilmente devi conservarli on-premise. Ove applicabile e conforme, tuttavia, l'utilizzo di funzionalità di protezione dei dati sensibili come le tecniche di anonimizzazione può aiutarti a spostare i dati quando necessario.

Nel pattern di architettura ibrida a più livelli, in alcuni scenari puoi utilizzare anche Google Distributed Cloud. Distributed Cloud ti consente di eseguire cluster Google Kubernetes Engine su hardware dedicato fornito e gestito da Google e separato dal data center Google Cloud . Per assicurarti che Distributed Cloud soddisfi i tuoi requisiti attuali e futuri, scopri le limitazioni di Distributed Cloud rispetto a una zona GKE convenzionale basata sul cloud.

Vantaggi

Concentrarsi prima sulle applicazioni frontend offre diversi vantaggi, tra cui:

• I componenti frontend dipendono dalle risorse di backend e occasionalmente da altri componenti frontend.
• I componenti di backend non dipendono da quelli di frontend. Pertanto, l'isolamento e la migrazione delle applicazioni frontend tendono a essere meno complessi della migrazione delle applicazioni backend.
• Poiché le applicazioni frontend spesso non hanno stato o non gestiscono i dati autonomamente, la loro migrazione tende a essere meno impegnativa rispetto ai backend.
  • I componenti frontend possono essere ottimizzati nell'ambito della migrazione per utilizzare l'architettura stateless. Per saperne di più, guarda il video How to port stateful web apps to Cloud Run su YouTube.

Il deployment di applicazioni frontend esistenti o di nuova creazione nel cloud pubblico offre diversi vantaggi:

• Molte applicazioni frontend sono soggette a modifiche frequenti. L'esecuzione di queste applicazioni nel cloud pubblico semplifica la configurazione di un processo di integrazione continua/deployment continuo (CI/CD). Puoi utilizzare CI/CD per inviare aggiornamenti in modo efficiente e automatizzato. Per ulteriori informazioni, consulta la sezione CI/CD su Google Cloud.
• I frontend sensibili alle prestazioni con carico di traffico variabile possono trarre vantaggio in modo sostanziale dal bilanciamento del carico, dai deployment multiregionali, dalla memorizzazione nella cache di Cloud CDN, dalle funzionalità serverless e di scalabilità automatica che un deployment basato sul cloud consente (idealmente con un'architettura stateless).

• L'adozione di microservizi con container utilizzando una piattaforma gestita dal cloud, come GKE, consente di utilizzare architetture moderne come i microfrontend, che estendono i microservizi ai componenti frontend.

  L'estensione dei microservizi viene comunemente utilizzata con i frontend che coinvolgono più team che collaborano alla stessa applicazione. Questo tipo di struttura del team richiede un approccio iterativo e una manutenzione continua. Ecco alcuni dei vantaggi dell'utilizzo dei microfrontend:

  • Possono essere trasformati in moduli di microservizi indipendenti per lo sviluppo, il test e il deployment.
  • Consente la separazione in modo che i singoli team di sviluppo possano selezionare le tecnologie e il codice che preferiscono.
  • Può favorire cicli rapidi di sviluppo e deployment senza influire sugli altri componenti frontend che potrebbero essere gestiti da altri team.

• Che implementino interfacce utente o API o gestiscano l'importazione dati dell'Internet delle cose (IoT), le applicazioni frontend possono trarre vantaggio dalle funzionalità di servizi cloud come Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine, o Cloud Run.

• I proxy API gestiti dal cloud consentono di:

  • Disaccoppia l'API per le app dai tuoi servizi di backend, come i microservizi.
  • Proteggere le app dalle modifiche al codice del backend.
  • Supporta le architetture frontend esistenti basate su API, come backend for frontend (BFF), microfrontend e altre.
  • Esporre le tue API su Google Cloud o altri ambienti implementando proxy API su Apigee.

Puoi anche applicare il pattern ibrido a più livelli al contrario, eseguendo il deployment dei backend nel cloud mantenendo i frontend in ambienti di computing privati. Sebbene sia meno comune, questo approccio è più adatto quando hai a che fare con un frontend pesante e monolitico. In questi casi, potrebbe essere più semplice estrarre la funzionalità di backend in modo iterativo e implementare questi nuovi backend nel cloud.

La terza parte di questa serie illustra i possibili pattern di networking per abilitare un'architettura di questo tipo. Apigee hybrid funge da piattaforma per la creazione e la gestione di proxy API in un modello di deployment ibrido. Per ulteriori informazioni, vedi Architettura a basso accoppiamento, incluse le architetture monolitiche e di microservizi a più livelli.

Best practice

Utilizza le informazioni in questa sezione per pianificare l'architettura ibrida a più livelli.

Best practice per ridurre la complessità

Quando applichi il pattern di architettura ibrida a livelli, considera le seguenti best practice che possono contribuire a ridurre la complessità operativa e di deployment complessiva:

• In base alla valutazione dei modelli di comunicazione delle applicazioni identificate, seleziona la soluzione di comunicazione più efficiente ed efficace per queste applicazioni.

Poiché la maggior parte delle interazioni degli utenti coinvolge sistemi che si connettono a più ambienti di computing, è importante una connettività veloce e a bassa latenza tra questi sistemi. Per soddisfare le aspettative di disponibilità e prestazioni, devi progettare per alta disponibilità, bassa latenza e livelli di throughput appropriati. Dal punto di vista della sicurezza, la comunicazione deve essere granulare e controllata. Idealmente, dovresti esporre i componenti dell'applicazione utilizzando API sicure. Per saperne di più, consulta la sezione Egress controllato.

• Per ridurre al minimo la latenza di comunicazione tra gli ambienti, seleziona una Google Cloud regione geograficamente vicina all'ambiente di calcolo privato in cui sono ospitati i componenti di backend dell'applicazione. Per saperne di più, consulta Best practice per la scelta delle regioni di Compute Engine.
• Riduci al minimo le dipendenze elevate tra i sistemi in esecuzione in ambienti diversi, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni, ridurre la disponibilità complessiva e potenzialmente comportare costi aggiuntivi per il trasferimento di dati in uscita.
• Con il pattern di architettura ibrida a livelli, potresti avere volumi maggiori di traffico in entrata dagli ambienti on-premise inGoogle Cloud rispetto al traffico in uscita da Google Cloud. Tuttavia, devi conoscere il volume previsto di trasferimento di dati in uscita da Google Cloud. Se prevedi di utilizzare questa architettura a lungo termine con volumi elevati di trasferimento di dati in uscita, valuta la possibilità di utilizzare Cloud Interconnect. Cloud Interconnect può contribuire a ottimizzare le prestazioni della connettività e potrebbe ridurre gli addebiti per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.
• Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito. Se è necessaria la crittografia a livello di connettività, puoi utilizzare tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

• Per superare le incoerenze nei protocolli, nelle API e nei meccanismi di autenticazione tra diversi backend, ti consigliamo, ove applicabile, di eseguire il deployment di un gateway API o di un proxy come facciata unificante. Questo gateway o proxy funge da punto di controllo centralizzato ed esegue le seguenti operazioni:

  • Implementa misure di sicurezza aggiuntive.
  • Protegge le app client e altri servizi dalle modifiche al codice del backend.
  • Facilita i log di controllo per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
  • Funge da livello di comunicazione intermedio tra i servizi legacy e quelli modernizzati.
    • Apigee e Apigee hybrid ti consentono di ospitare e gestire gateway ibridi e di livello aziendale in ambienti on-premise, edge, altri cloud e ambientiGoogle Cloud .

• Per facilitare la configurazione di configurazioni ibride, utilizza Cloud Load Balancing con la connettività ibrida. Ciò significa che puoi estendere i vantaggi del bilanciamento del carico cloud ai servizi ospitati nel tuo ambiente di calcolo on-premise. Questo approccio consente migrazioni dei carichi di lavoro in più fasi a Google Cloud con interruzioni minime o nulle del servizio, garantendo una transizione fluida per i servizi distribuiti. Per maggiori informazioni, consulta la panoramica dei gruppi di endpoint di rete con connettività ibrida.

• A volte, l'utilizzo combinato di un gateway API o di un proxy e di un bilanciatore del carico delle applicazioni può fornire una soluzione più solida per la gestione, la protezione e la distribuzione del traffico API su larga scala. L'utilizzo di Cloud Load Balancing con i gateway API consente di eseguire le seguenti operazioni:

  • Fornisci API ad alte prestazioni con Apigee e Cloud CDN, per ridurre la latenza, ospitare le API a livello globale e aumentare la disponibilità per le stagioni di picco del traffico. Per saperne di più, guarda Distribuzione di API ad alte prestazioni con Apigee e Cloud CDN su YouTube.
  • Implementa la gestione avanzata del traffico.
  • Utilizza Cloud Armor come servizio di protezione DDoS e sicurezza di rete per proteggere le tue API.
  • Gestisci il bilanciamento del carico efficiente tra i gateway in più regioni. Per saperne di più, guarda Securing APIs and Implementing multi-region failover with Private Service Connect and Apigee su YouTube.

• Utilizza la gestione delle API e il service mesh per proteggere e controllare la comunicazione e l'esposizione dei servizi con l'architettura di microservizi.

  • Utilizza Cloud Service Mesh per consentire la comunicazione tra servizi, che mantiene la qualità del servizio in un sistema composto da servizi distribuiti in cui puoi gestire l'autenticazione, l'autorizzazione e la crittografia tra i servizi.
  • Utilizza una piattaforma di gestione delle API come Apigee che consente alla tua organizzazione e alle entità esterne di utilizzare questi servizi esponendoli come API.

• Stabilisci un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro oltre i confini dell'ambiente.

• Esegui il deployment di sistemi CI/CD e di gestione della configurazione nel cloud pubblico. Per maggiori informazioni, consulta la pagina Modello di architettura di networking mirroring.

• Per aumentare l'efficienza operativa, utilizza strumenti e pipeline CI/CD coerenti in tutti gli ambienti.

Best practice per le architetture di singoli carichi di lavoro e applicazioni

• Sebbene questo pattern sia incentrato sulle applicazioni frontend, tieni presente la necessità di modernizzare le applicazioni backend. Se il ritmo di sviluppo delle applicazioni di backend è notevolmente più lento rispetto a quello delle applicazioni frontend, la differenza può causare una maggiore complessità.
• Il trattamento delle API come interfacce di backend semplifica le integrazioni, lo sviluppo del frontend, le interazioni dei servizi e nasconde le complessità del sistema di backend. Per affrontare queste sfide, Apigee facilita lo sviluppo e la gestione di gateway/proxy API per deployment ibridi e multi-cloud.
• Scegli l'approccio di rendering per la tua applicazione web frontend in base ai contenuti (statici o dinamici), al rendimento dell'ottimizzazione per i motori di ricerca e alle aspettative in merito alla velocità di caricamento delle pagine.
• Quando selezioni un'architettura per applicazioni web basate sui contenuti, sono disponibili varie opzioni, tra cui architetture monolitiche, serverless, basate sugli eventi e a microservizi. Per selezionare l'architettura più adatta, valuta attentamente queste opzioni in base ai requisiti attuali e futuri dell'applicazione. Per aiutarti a prendere una decisione architetturale in linea con i tuoi obiettivi aziendali e tecnici, consulta Confronto tra diverse architetture per i backend di applicazioni web basate sui contenuti e Considerazioni chiave per i backend web.

• Con un'architettura di microservizi, puoi utilizzare applicazioni containerizzate con Kubernetes come livello di runtime comune. Con il pattern di architettura ibrida a più livelli, puoi eseguirlo in uno dei seguenti scenari:

  • In entrambi gli ambienti (Google Cloud e i tuoi ambienti on-premise).

    • Quando utilizzi container e Kubernetes in diversi ambienti, hai la flessibilità di modernizzare i carichi di lavoro e poi eseguire la migrazione a Google Cloud in momenti diversi. Ciò è utile quando un carico di lavoro dipende fortemente da un altro e non può essere migrato singolarmente o per utilizzare la portabilità dei carichi di lavoro ibridi per utilizzare le migliori risorse disponibili in ogni ambiente. In tutti i casi, GKE Enterprise può essere una tecnologia abilitante chiave. Per maggiori informazioni, consulta Ambiente ibrido GKE Enterprise.

  • In un ambiente Google Cloud per i componenti dell'applicazione migrati e modernizzati.

    • Utilizza questo approccio quando hai backend legacy on-premise che non supportano la containerizzazione o richiedono tempi e risorse significativi per la modernizzazione nel breve termine.

    Per ulteriori informazioni sulla progettazione e sul refactoring di un'app monolitica in un'architettura di microservizi per modernizzare l'architettura dell'applicazione web, consulta Introduzione ai microservizi.

• Puoi combinare le tecnologie di archiviazione dei dati in base alle esigenze delle tue applicazioni web. L'utilizzo di Cloud SQL per i dati strutturati e di Cloud Storage per i file multimediali è un approccio comune per soddisfare diverse esigenze di archiviazione dei dati. Detto questo, la scelta dipende in gran parte dal caso d'uso. Per maggiori informazioni sulle opzioni di archiviazione dei dati per i backend delle applicazioni basate sui contenuti e sulle modalità efficaci, consulta Opzioni di archiviazione dei dati per le app web basate sui contenuti. Consulta anche Opzioni del database Google Cloud spiegate.

Pattern multi-cloud partizionato

Il pattern di architettura multi-cloud partizionato combina più ambienti cloud pubblici gestiti da diversi fornitori di servizi cloud. Questa architettura offre la flessibilità di eseguire il deployment di un'applicazione in un ambiente di computing ottimale che tiene conto dei fattori e delle considerazioni multicloud discussi nella prima parte di questa serie.

Il seguente diagramma mostra un pattern di architettura multicloud partizionata.

Questo pattern di architettura può essere creato in due modi diversi. Il primo approccio si basa sul deployment dei componenti dell'applicazione in diversi ambienticloud pubblicoi. Questo approccio è anche noto come architettura composita ed è lo stesso dell'pattern di architettura ibrida a più livelli. Anziché utilizzare un ambiente on-premise con un cloud pubblico, utilizza almeno due ambienti cloud. In un'architettura composita, un singolo carico di lavoro o applicazione utilizza componenti di più cloud. Il secondo approccio esegue il deployment di applicazioni diverse in ambienti cloud pubblico diversi. Il seguente elenco non esaustivo descrive alcuni dei fattori aziendali del secondo approccio:

• Per integrare completamente le applicazioni ospitate in ambienti cloud diversi durante uno scenario di fusione e acquisizione tra due aziende.
• Per promuovere la flessibilità e soddisfare le diverse preferenze cloud all'interno della tua organizzazione. Adotta questo approccio per incoraggiare le unità organizzative a scegliere il cloud provider più adatto alle loro esigenze e preferenze specifiche.
• Per operare in un deployment multi-regionale o globale del cloud. Se un'azienda è tenuta a rispettare le normative sulla residenza dei dati in regioni o paesi specifici, deve scegliere tra i fornitori di servizi cloud disponibili in quella località se il suo fornitore di servizi cloud principale non dispone di una regione cloud in quella località.

Con il pattern di architettura multi-cloud partizionata, puoi, se vuoi, mantenere la possibilità di spostare i carichi di lavoro in base alle esigenze da un ambiente cloud pubblico a un altro. In questo caso, la portabilità dei carichi di lavoro diventa un requisito fondamentale. Quando esegui il deployment dei carichi di lavoro in più ambienti di computing e vuoi mantenere la possibilità di spostarli tra gli ambienti, devi astrarre le differenze tra gli ambienti. Utilizzando GKE Enterprise, puoi progettare e creare una soluzione per risolvere la complessità multicloud con strategie coerenti per governance, operazioni e sicurezza. Per maggiori informazioni, consulta GKE Multi-Cloud.

Come accennato in precedenza, in alcune situazioni potrebbero esserci motivi aziendali e tecnici per combinare Google Cloud con un altro provider cloud e per partizionare i carichi di lavoro in questi ambienti cloud. Le soluzioni multi-cloud ti offrono la flessibilità necessaria per eseguire la migrazione, creare e ottimizzare la portabilità delle applicazioni in ambienti multi-cloud, riducendo al minimo i vincoli e aiutandoti a soddisfare i requisiti normativi. Ad esempio, potresti connetterti Google Cloud a Oracle Cloud Infrastructure (OCI) per creare una soluzione multi-cloud che sfrutti le funzionalità di ogni piattaforma utilizzando un'interconnessione privata Cloud Interconnect per combinare i componenti in esecuzione in OCI con le risorse in esecuzione su Google Cloud. Per saperne di più, consulta Google Cloud e Oracle Cloud Infrastructure: sfruttare al meglio il multi-cloud. Inoltre, Cross-Cloud Interconnect facilita la connettività dedicata a elevata larghezza di banda tra Google Cloud e altri provider di servizi cloud supportati, consentendoti di progettare e creare soluzioni multi-cloud per gestire volumi elevati di traffico inter-cloud.

Vantaggi

L'utilizzo di un'architettura multicloud offre diversi vantaggi tecnici e aziendali, come descritto in Fattori, considerazioni, strategia e approcci. È essenziale eseguire una valutazione dettagliata della fattibilità di ogni potenziale vantaggio. La tua valutazione deve considerare attentamente eventuali sfide dirette o indirette o potenziali ostacoli e la tua capacità di superarli in modo efficace. Inoltre, tieni presente che la crescita a lungo termine delle tue applicazioni o dei tuoi servizi può introdurre complessità che potrebbero superare i vantaggi iniziali.

Ecco alcuni vantaggi chiave del pattern di architettura multicloud partizionata:

• Negli scenari in cui potresti dover ridurre al minimo l'impegno con un singolo provider cloud, puoi distribuire le applicazioni su più provider cloud. Di conseguenza, potresti ridurre relativamente il vendor lock-in con la possibilità di cambiare piano (in una certa misura) tra i tuoi provider cloud. Open Cloud consente di portare le funzionalità di Google Cloud , come GKE Enterprise, in diverse posizioni fisiche. Estendendo Google Cloud le funzionalità on-premise, in più cloud pubblici e sull'edge, offre flessibilità, agilità e favorisce la trasformazione.

• Per motivi normativi, puoi pubblicare un determinato segmento della tua base utenti e dei tuoi dati da un paese in cui Google Cloud non dispone di una regione cloud.

• Il pattern di architettura multi-cloud partizionato può contribuire a ridurre la latenza e migliorare la qualità complessiva dell'esperienza utente nelle località in cui il fornitore di servizi cloud principale non dispone di una regione cloud o di un point of presence. Questo pattern è particolarmente utile quando si utilizza la connettività multicloud a bassa latenza e ad alta capacità, ad esempio Cross-Cloud Interconnect e CDN Interconnect con una CDN distribuita.

• Puoi eseguire il deployment delle applicazioni su più cloud provider in modo da scegliere tra i migliori servizi offerti dagli altri cloud provider.

• Il pattern di architettura multicloud partizionato può contribuire a facilitare e accelerare gli scenari di fusione e acquisizione, in cui le applicazioni e i servizi delle due aziende potrebbero essere ospitati in ambienti cloud pubblico diversi.

Best practice

• Inizia con il deployment di un workload non mission critical. Questo deployment iniziale nel cloud secondario può quindi fungere da modello per deployment o migrazioni futuri. Tuttavia, questo approccio probabilmente non è applicabile in situazioni in cui è richiesto per legge o per regolamento che il workload specifico risieda in una regione cloud specifica e il provider cloud principale non disponga di una regione nel territorio richiesto.
• Riduci al minimo le dipendenze tra i sistemi in esecuzione in ambienti cloud pubblico diversi, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni, ridurre la disponibilità complessiva e potenzialmente comportare costi aggiuntivi per il trasferimento di dati in uscita.
• Per eliminare le differenze tra gli ambienti, valuta la possibilità di utilizzare container e Kubernetes, se supportati dalle applicazioni e fattibili.
• Assicurati che le pipeline CI/CD e gli strumenti per il deployment e il monitoraggio siano coerenti in tutti gli ambienti cloud.
• Seleziona il pattern di architettura di rete ottimale che fornisca la soluzione di comunicazione più efficiente ed efficace per le applicazioni che utilizzi.
  • La comunicazione deve essere granulare e controllata. Utilizza API sicure per esporre i componenti dell'applicazione.
  • Prendi in considerazione l'utilizzo del pattern di architettura mesh o di uno dei pattern di networking controllati, in base ai tuoi requisiti aziendali e tecnici specifici.
• Per soddisfare le tue aspettative di disponibilità e prestazioni, progetta per disponibilità elevata (HA) end-to-end, bassa latenza e livelli di throughput appropriati.

• Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito.

  • Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cross-Cloud Interconnect.

• Se utilizzi più CDN nell'ambito del pattern di architettura partizionata multicloud e stai compilando l'altra CDN con file di dati di grandi dimensioni da Google Cloud, valuta la possibilità di utilizzare i link CDN Interconnect tra Google Cloud e i provider supportati per ottimizzare questo traffico e, potenzialmente, il suo costo.

• Estendi la tua soluzione di gestione delle identità tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro oltre i confini dell'ambiente.

• Per bilanciare in modo efficace le richieste tra Google Cloud e un'altra piattaforma cloud, puoi utilizzare Cloud Load Balancing. Per saperne di più, vedi Routing del traffico a una posizione on-premise o a un altro cloud.

  • Se il volume di trasferimento di dati in uscita da Google Cloud verso altri ambienti è elevato, valuta la possibilità di utilizzare Cross-Cloud Interconnect.

• Per superare le incoerenze nei protocolli, nelle API e nei meccanismi di autenticazione tra diversi backend, ti consigliamo, ove applicabile, di eseguire il deployment di un gateway API o di un proxy come facciata unificante. Questo gateway o proxy funge da punto di controllo centralizzato ed esegue le seguenti operazioni:

  • Implementa misure di sicurezza aggiuntive.
  • Protegge le app client e altri servizi dalle modifiche al codice del backend.
  • Facilita i log di controllo per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
  • Funge da livello di comunicazione intermedio tra i servizi legacy e quelli modernizzati.
    • Apigee e Apigee hybrid ti consentono di ospitare e gestire gateway ibridi e di livello aziendale in ambienti on-premise, edge, altri cloud e ambientiGoogle Cloud .

• In alcuni dei seguenti casi, l'utilizzo di Cloud Load Balancing con un gateway API può fornire una soluzione solida e sicura per gestire, proteggere e distribuire il traffico API su larga scala in più regioni:

  • Deployment del failover multiregionale per i runtime API Apigee in regioni diverse.

  • Aumento delle prestazioni con Cloud CDN.

  • Fornisce WAF e protezione DDoS tramite Google Cloud Armor.

• Se possibile, utilizza strumenti coerenti per il logging e il monitoraggio in tutti gli ambienti cloud. Potresti prendere in considerazione l'utilizzo di sistemi di monitoraggio open source. Per maggiori informazioni, vedi Pattern di logging e monitoraggio per cloud ibrido e multi-cloud.

• Se esegui il deployment dei componenti dell'applicazione in modo distribuito, ovvero se i componenti di una singola applicazione vengono implementati in più di un ambiente cloud, consulta le best practice per il pattern di architettura ibrida a più livelli.

Pattern ibrido e multi-cloud di Analytics

Questo documento spiega che l'obiettivo del pattern ibrido e multicloud di Analytics è sfruttare la divisione tra carichi di lavoro transazionali e analitici.

Nei sistemi aziendali, la maggior parte dei carichi di lavoro rientra in queste categorie:

• I workload transazionali includono applicazioni interattive come vendite, elaborazione finanziaria, pianificazione delle risorse aziendali o comunicazione.
• I carichi di lavoro di analisi includono applicazioni che trasformano, analizzano, perfezionano o visualizzano i dati per facilitare i processi decisionali.

I sistemi di analisi ottengono i dati dai sistemi transazionali eseguendo query sulle API o accedendo ai database. Nella maggior parte delle aziende, i sistemi di analisi e transazionali tendono a essere separati ea basso accoppiamentoo. L'obiettivo del pattern ibrido e multi-cloud di Analytics è sfruttare questa divisione preesistente eseguendo i workload transazionali e di analisi in due ambienti di computing diversi. I dati non elaborati vengono prima estratti dai carichi di lavoro in esecuzione nell'ambiente di computing privato e poi caricati in Google Cloud, dove vengono utilizzati per l'elaborazione analitica. Alcuni risultati potrebbero poi essere ritrasmessi ai sistemi transazionali.

Il seguente diagramma illustra le architetture concettualmente possibili mostrando potenziali pipeline di dati. Ogni percorso/freccia rappresenta una possibile opzione di pipeline di trasformazione e spostamento dei dati che può essere basata su ETL o ELT, a seconda della qualità dei dati disponibile e del caso d'uso mirato.

Per trasferire i tuoi dati in Google Cloud e sbloccarne il valore, utilizza i servizi di spostamento dei dati, una suite completa di servizi di importazione, integrazione e replica dei dati.

Come mostrato nel diagramma precedente, la connessione Google Cloud con ambienti on-premise e altri ambienti cloud può consentire vari casi d'uso di analisi dei dati, come lo streaming di dati e i backup dei database. Per alimentare il trasporto fondamentale di un pattern di analisi ibrido e multi-cloud che richiede un volume elevato di trasferimento di dati, Cloud Interconnect e Cross-Cloud Interconnect forniscono una connettività dedicata a on-premise e ad altri provider di servizi cloud.

Vantaggi

L'esecuzione dei carichi di lavoro di analisi nel cloud offre diversi vantaggi chiave:

• Il traffico in entrata, ovvero lo spostamento di dati dal tuo ambiente di computing privato o da altri cloud aGoogle Cloud, potrebbe essere gratuito.
• I carichi di lavoro di analisi spesso devono elaborare grandi quantità di dati e possono essere burst, quindi sono particolarmente adatti per essere implementati in un ambiente cloud pubblico. Scalando dinamicamente le risorse di calcolo, puoi elaborare rapidamente set di dati di grandi dimensioni evitando investimenti iniziali o di dover eseguire il provisioning eccessivo delle apparecchiature di computing.
• Google Cloud fornisce un ricco insieme di servizi per gestire i dati durante l'intero ciclo di vita, dall'acquisizione iniziale all'elaborazione e all'analisi fino alla visualizzazione finale.
  • I servizi di spostamento dei dati su Google Cloud offrono una suite completa di prodotti per spostare, integrare e trasformare i dati in modo semplice e in diversi modi.
  • Cloud Storage è adatto per creare un data lake.

• Google Cloud ti aiuta a modernizzare e ottimizzare la tua piattaforma di dati per abbattere i silos di dati. L'utilizzo di una data lakehouse consente di standardizzare i diversi formati di archiviazione. Può anche fornire la flessibilità, la scalabilità e l'agilità necessarie per garantire che i tuoi dati generino valore per la tua attività, piuttosto che inefficienze. Per maggiori informazioni, consulta BigLake.

• BigQuery Omni fornisce potenza di calcolo che viene eseguita localmente sullo spazio di archiviazione su AWS o Azure. Ti aiuta anche a eseguire query sui tuoi dati archiviati in Amazon Simple Storage Service (Amazon S3) o Azure Blob Storage. Questa funzionalità di analisi multi-cloud consente ai team di dati di abbattere le barriere tra i dati. Per saperne di più sull'esecuzione di query sui dati archiviati al di fuori di BigQuery, consulta Introduzione alle origini dati esterne.

Best practice

Per implementare il pattern di architettura ibrida e multicloud di Analytics, considera le seguenti best practice generali:

• Utilizza il pattern di networking di trasferimento per attivare l'importazione dei dati. Se i risultati analitici devono essere ritrasmessi ai sistemi transazionali, puoi combinare sia il trasferimento che il pattern di uscita controllata.
• Utilizza le code Pub/Sub o i bucket Cloud Storage per trasferire i dati da sistemi transazionali in esecuzione nel tuo ambiente di computing privato a Google Cloud . Queste code o bucket possono quindi fungere da origini per pipeline e workload di elaborazione dei dati.
• Per eseguire il deployment delle pipeline di dati ETL ed ELT, valuta la possibilità di utilizzare Cloud Data Fusion o Dataflow a seconda dei requisiti specifici del caso d'uso. Entrambi sono servizi di elaborazione dei dati cloud-first completamente gestiti per creare e gestire pipeline di dati.
• Per scoprire, classificare e proteggere i tuoi preziosi asset di dati, valuta la possibilità di utilizzare le funzionalità di Google Cloud Sensitive Data Protection, come le tecniche di anonimizzazione. Queste tecniche consentono di mascherare, criptare e sostituire i dati sensibili, come le informazioni che consentono l'identificazione personale (PII), utilizzando una chiave generata in modo casuale o predeterminata, ove applicabile e conforme.

• Quando esegui un trasferimento iniziale dei dati dal tuo ambiente di computing privato a Google Cloud, scegli l'approccio di trasferimento più adatto alle dimensioni del tuo set di dati e alla larghezza di banda disponibile. Per ulteriori informazioni, vedi Migrazione verso Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni.

• Se è necessario il trasferimento o lo scambio di dati tra Google Cloud e altri cloud a lungo termine con un volume di traffico elevato, valuta l'utilizzo di Google Cloud Cross-Cloud Interconnect per stabilire una connettività dedicata a elevata larghezza di banda tra Google Cloud e altri provider di servizi cloud (disponibile in alcune località).

• Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cross-Cloud Interconnect.

• Utilizza strumenti e processi coerenti in tutti gli ambienti. In uno scenario ibrido di analisi, questa pratica può contribuire ad aumentare l'efficienza operativa, anche se non è un prerequisito.

Pattern ibrido Edge

L'esecuzione di workload nel cloud richiede che i client in alcuni scenari dispongano di una connettività internet veloce e affidabile. Date le reti attuali, questo requisito raramente pone problemi per l'adozione del cloud. Tuttavia, esistono scenari in cui non puoi fare affidamento su una connettività continua, ad esempio:

• Le navi marittime e altri veicoli potrebbero essere connessi solo in modo intermittente o avere accesso solo a collegamenti satellitari ad alta latenza.
• Fabbriche o centrali elettriche potrebbero essere connesse a internet. Queste strutture potrebbero avere requisiti di affidabilità superiori alle dichiarazioni di disponibilità del loro provider di servizi internet.
• I negozi di vendita al dettaglio e i supermercati potrebbero essere connessi solo occasionalmente o utilizzare link che non forniscono l'affidabilità o la velocità di trasmissione necessarie per gestire le transazioni fondamentali per l'attività.

Il pattern di architettura ibrida edge risolve queste sfide eseguendo i carichi di lavoro critici per il tempo e l'attività localmente, all'edge della rete, mentre utilizza il cloud per tutti gli altri tipi di carichi di lavoro. In un'architettura ibrida edge, il collegamento a internet è un componente non critico che viene utilizzato per scopi di gestione e per sincronizzare o caricare i dati, spesso in modo asincrono, ma non è coinvolto in transazioni critiche per il tempo o l'attività.

Vantaggi

L'esecuzione di determinati carichi di lavoro all'edge e di altri nel cloud offre diversi vantaggi:

• Il traffico in entrata, ovvero il trasferimento di dati dall'edge aGoogle Cloud, potrebbe essere gratuito.
• L'esecuzione di workload business-critical e sensibili al tempo a livello perimetrale contribuisce a garantire bassa latenza e autosufficienza. Se la connettività a internet non funziona o non è temporaneamente disponibile, puoi comunque eseguire tutte le transazioni importanti. Allo stesso tempo, puoi usufruire dell'utilizzo del cloud per una parte significativa del tuo carico di lavoro complessivo.
• Puoi riutilizzare gli investimenti esistenti in apparecchiature di calcolo e archiviazione.
• Nel tempo, puoi ridurre gradualmente la frazione di carichi di lavoro eseguiti all'edge e spostarli nel cloud, rielaborando alcune applicazioni o dotando alcune località edge di collegamenti a internet più affidabili.
• I progetti correlati all'Internet of Things (IoT) possono diventare più convenienti eseguendo i calcoli dei dati in locale. Ciò consente alle aziende di eseguire ed elaborare alcuni servizi localmente all'edge, più vicino alle origini dati. Consente inoltre alle aziende di inviare selettivamente i dati al cloud, il che può contribuire a ridurre la capacità, il trasferimento dei dati, l'elaborazione e i costi complessivi della soluzione IoT.
• L'edge computing può fungere da livello di comunicazione intermedio tra servizi legacy e modernizzati. Ad esempio, servizi che potrebbero eseguire un gateway API containerizzato come Apigee hybrid. Ciò consente a sistemi e applicazioni legacy di integrarsi con servizi modernizzati, come le soluzioni IoT.

Best practice

Quando implementi il pattern di architettura ibrida edge, tieni presente i seguenti suggerimenti:

• Se la comunicazione è unidirezionale, utilizza il pattern di ingresso controllato.
• Se la comunicazione è bidirezionale, prendi in considerazione il pattern di uscita controllata e ingresso controllato.
• Se la soluzione è costituita da molti siti remoti periferici che si connettono a Google Cloud tramite internet pubblico, puoi utilizzare una soluzione SD-WAN (WAN software-defined). Puoi anche utilizzare Network Connectivity Center con un router SD-WAN di terze parti supportato da un Google Cloud partner per semplificare il provisioning e la gestione della connettività sicura su larga scala.
• Ridurre al minimo le dipendenze tra i sistemi in esecuzione all'edge e i sistemi in esecuzione nell'ambiente cloud. Ogni dipendenza può compromettere l'affidabilità e i vantaggi di latenza di una configurazione ibrida edge.
• Per gestire e utilizzare in modo efficiente più sedi perimetrali, devi disporre di un piano di gestione centralizzato e di una soluzione di monitoraggio nel cloud.
• Assicurati che le pipeline CI/CD e gli strumenti per il deployment e il monitoraggio siano coerenti negli ambienti cloud ed edge.
• Valuta la possibilità di utilizzare container e Kubernetes, se applicabile e fattibile, per astrarre le differenze tra le varie località edge e anche tra le località edge e il cloud. Poiché Kubernetes fornisce un livello di runtime comune, puoi sviluppare, eseguire e gestire i carichi di lavoro in modo coerente in tutti gli ambienti di computing. Puoi anche spostare i carichi di lavoro tra l'edge e il cloud.
  • Per semplificare la configurazione e l'operazione ibrida, puoi utilizzare GKE Enterprise per questa architettura (se i container vengono utilizzati in tutti gli ambienti). Valuta le possibili opzioni di connettività che devi utilizzare per connettere un cluster GKE Enterprise in esecuzione nel tuo ambiente on-premise o edge a Google Cloud.
• Nell'ambito di questo pattern, anche se alcuni componenti di GKE Enterprise potrebbero essere mantenuti durante un'interruzione temporanea della connettività a Google Cloud, non utilizzare GKE Enterprise quando è disconnesso da Google Cloud come modalità di funzionamento nominale. Per ulteriori informazioni, vedi Impatto della disconnessione temporanea da Google Cloud.
• Per superare le incoerenze nei protocolli, nelle API e nei meccanismi di autenticazione tra diversi servizi di backend e edge, ti consigliamo, ove applicabile, di implementare un gateway API o un proxy come facade unificante. Questo gateway o proxy funge da punto di controllo centralizzato ed esegue le seguenti operazioni:
  • Implementa misure di sicurezza aggiuntive.
  • Protegge le app client e altri servizi dalle modifiche al codice del backend.
  • Facilita i log di controllo per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
  • Funge da livello di comunicazione intermedio tra i servizi legacy e quelli modernizzati.
    • Apigee e Apigee Hybrid ti consentono di ospitare e gestire gateway ibridi e di livello aziendale in ambienti on-premise, edge, altri cloud e ambientiGoogle Cloud .
• Stabilisci un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro oltre i confini dell'ambiente.
• Poiché i dati scambiati tra gli ambienti potrebbero essere sensibili, assicurati che tutte le comunicazioni siano criptate in transito utilizzando tunnel VPN, TLS o entrambi.

Pattern ibrido dell'ambiente

Con il pattern di architettura ibrida dell'ambiente, mantieni l'ambiente di produzione di un carico di lavoro nel data center esistente. Poi utilizzi il cloud pubblico per gli ambienti di sviluppo e test o altri ambienti. Questo pattern si basa sul deployment ridondante delle stesse applicazioni in più ambienti di computing. L'obiettivo dell'implementazione è contribuire ad aumentare la capacità, l'agilità e la resilienza.

Quando valuti quali carichi di lavoro migrare, potresti notare casi in cui l'esecuzione di un'applicazione specifica nel cloud pubblico presenta delle sfide:

• Vincoli giurisdizionali o normativi potrebbero richiedere di conservare i dati in un paese specifico.
• I termini di licenza di terze parti potrebbero impedirti di utilizzare determinati software in un ambiente cloud.
• Un'applicazione potrebbe richiedere l'accesso a dispositivi hardware disponibili solo localmente.

In questi casi, considera non solo l'ambiente di produzione, ma tutti gli ambienti coinvolti nel ciclo di vita di un'applicazione, inclusi i sistemi di sviluppo, test e gestione temporanea. Queste limitazioni spesso si applicano all'ambiente di produzione e ai relativi dati. Potrebbero non essere applicabili ad altri ambienti che non utilizzano i dati effettivi. Contatta il reparto conformità della tua organizzazione o il team equivalente.

Il seguente diagramma mostra un tipico pattern di architettura ibrida dell'ambiente:

L'esecuzione di sistemi di sviluppo e test in ambienti diversi da quelli di produzione potrebbe sembrare rischiosa e potrebbe discostarsi dalle best practice esistenti o dai tentativi di ridurre al minimo le differenze tra gli ambienti. Sebbene queste preoccupazioni siano giustificate, non si applicano se distingui tra le fasi dei processi di sviluppo e test:

Sebbene i processi di sviluppo, test e deployment varino per ogni applicazione, in genere prevedono variazioni delle seguenti fasi:

• Sviluppo: creazione di una release candidata.
• Test funzionali o test di accettazione utente: verifica che la release candidate soddisfi i requisiti funzionali.
• Test di prestazioni e affidabilità: verifica che la versione candidata soddisfi i requisiti non funzionali. È noto anche come test di carico.
• Test di staging o deployment: verifica che la procedura di deployment funzioni.
• Produzione: rilascio di applicazioni nuove o aggiornate.

L'esecuzione di più di una di queste fasi in un unico ambiente è raramente pratica, quindi ogni fase richiede in genere uno o più ambienti dedicati.

Lo scopo principale di un ambiente di test è eseguire test funzionali. Lo scopo principale di un ambiente di staging è verificare se le procedure di deployment dell'applicazione funzionano come previsto. Quando una release raggiunge un ambiente di staging, i test funzionali devono essere completati. Lo staging è l'ultimo passaggio prima di eseguire il deployment del software nel deployment di produzione.

Per garantire che i risultati dei test siano significativi e che si applichino al deployment di produzione, l'insieme di ambienti che utilizzi durante il ciclo di vita di un'applicazione deve soddisfare le seguenti regole, per quanto possibile:

• Tutti gli ambienti sono funzionalmente equivalenti. ovvero l'architettura, le API e le versioni di sistemi operativi e librerie sono equivalenti e i sistemi si comportano allo stesso modo in tutti gli ambienti. Questa equivalenza evita situazioni in cui le applicazioni funzionano in un ambiente ma non in un altro o in cui i difetti non sono riproducibili.
• Gli ambienti utilizzati per i test di prestazioni e affidabilità, lo staging e la produzione sono non equivalenti a livello funzionale. ovvero le loro prestazioni, la loro scalabilità e la loro configurazione, nonché il modo in cui vengono gestiti e mantenuti, sono uguali o differiscono solo in modi insignificanti. In caso contrario, i test di prestazioni e di staging diventano privi di significato.

In generale, non ci sono problemi se gli ambienti utilizzati per lo sviluppo e i test funzionali differiscono in modo non funzionale dagli altri ambienti.

Come illustrato nel seguente diagramma, gli ambienti di test e sviluppo sono basati su Google Cloud. Un database gestito, come Cloud SQL, può essere utilizzato come opzione per lo sviluppo e il test in Google Cloud. Lo sviluppo e il test possono utilizzare lo stesso motore del database e la stessa versione nell'ambiente on-premise, una versione funzionalmente equivalente o una nuova versione implementata nell'ambiente di produzione dopo la fase di test. Tuttavia, poiché l'infrastruttura sottostante dei due ambienti non è identica, questo approccio al test di carico delle prestazioni non è valido.

I seguenti scenari si adattano bene al pattern ibrido dell'ambiente:

• Raggiungi l'equivalenza funzionale in tutti gli ambienti facendo affidamento su Kubernetes come livello di runtime comune, ove applicabile e fattibile. La versione GKE Enterprise di Google Kubernetes Engine (GKE) può essere una tecnologia abilitante chiave per questo approccio.
  • Garantire la portabilità dei carichi di lavoro e astrarre le differenze tra gli ambienti di computing. Con una service mesh zero trust, puoi controllare e mantenere la separazione della comunicazione richiesta tra i diversi ambienti.
• Esegui ambienti di sviluppo e test funzionali nel cloud pubblico. Questi ambienti possono essere funzionalmente equivalenti agli altri, ma potrebbero differire per aspetti non funzionali, come le prestazioni. Questo concetto è illustrato nel diagramma precedente.
• Esegui ambienti per la produzione, lo staging e i test delle prestazioni (test di carico) e di affidabilità nell'ambiente di calcolo privato, garantendo l'equivalenza funzionale e non funzionale.

Considerazioni sulla progettazione

• Esigenze aziendali: ogni strategia di deployment e rilascio per le applicazioni presenta vantaggi e svantaggi. Per assicurarti che l'approccio che scegli sia in linea con i tuoi requisiti specifici, basa le tue selezioni su una valutazione approfondita delle esigenze e dei vincoli della tua attività.
• Differenze tra gli ambienti: nell'ambito di questo pattern, lo scopo principale dell'utilizzo di questo ambiente cloud è lo sviluppo e il test. Lo stato finale è ospitare l'applicazione testata nell'ambiente on-premise privato (produzione). Per evitare di sviluppare e testare una funzionalità che potrebbe funzionare come previsto nell'ambiente cloud e non nell'ambiente di produzione (on-premise), il team tecnico deve conoscere e comprendere le architetture e le funzionalità di entrambi gli ambienti. Ciò include le dipendenze da altre applicazioni e dall'infrastruttura hardware, ad esempio i sistemi di sicurezza che eseguono l'ispezione del traffico.
• Governance: per controllare cosa è consentito sviluppare alla tua azienda nel cloud e quali dati può utilizzare per i test, utilizza un processo di approvazione e governance. Questo processo può anche aiutare la tua azienda ad assicurarsi di non utilizzare funzionalità cloud negli ambienti di sviluppo e test che non esistono nell'ambiente di produzione on-premise.
• Criteri di successo: devono essere presenti criteri di successo dei test chiari, predefiniti e misurabili che siano in linea con gli standard di controllo qualità del software per la tua organizzazione. Applica questi standard a qualsiasi applicazione che sviluppi e testi.
• Ridondanza: sebbene gli ambienti di sviluppo e test potrebbero non richiedere la stessa affidabilità dell'ambiente di produzione, hanno comunque bisogno di funzionalità ridondanti e della possibilità di testare diversi scenari di errore. I requisiti dello scenario di errore potrebbero richiedere la ridondanza come parte dell'ambiente di sviluppo e test.

Vantaggi

L'esecuzione di carichi di lavoro di test funzionali e di sviluppo nel cloud pubblico presenta diversi vantaggi:

• Puoi avviare e arrestare automaticamente gli ambienti in base alle esigenze. Ad esempio, puoi eseguire il provisioning di un intero ambiente per ogni commit o pull request, consentire l'esecuzione dei test e poi disattivarlo di nuovo. Questo approccio offre anche i seguenti vantaggi:
  • Puoi ridurre i costi arrestando le istanze di macchine virtuali (VM) quando sono inattive o eseguendo il provisioning degli ambienti solo on demand.
  • Puoi accelerare lo sviluppo e i test avviando ambienti effimeri per ogni richiesta pull. In questo modo si riducono anche le spese generali di manutenzione e le incoerenze nell'ambiente di build.
• L'esecuzione di questi ambienti nel cloud pubblico contribuisce a creare familiarità e fiducia nel cloud e negli strumenti correlati, il che potrebbe facilitare la migrazione di altri carichi di lavoro. Questo approccio è particolarmente utile se decidi di esplorare la portabilità dei carichi di lavoro utilizzando container e Kubernetes, ad esempio utilizzando GKE Enterprise in tutti gli ambienti.

Best practice

Per implementare correttamente il pattern di architettura ibrida dell'ambiente, prendi in considerazione i seguenti consigli:

• Definisci i requisiti di comunicazione dell'applicazione, inclusi la rete e la progettazione della sicurezza ottimali. Quindi, utilizza il pattern di rete mirroring per progettare l'architettura di rete in modo da impedire le comunicazioni dirette tra sistemi di ambienti diversi. Se è necessaria la comunicazione tra gli ambienti, questa deve avvenire in modo controllato.

• La strategia di deployment e test delle applicazioni che scegli deve essere in linea con i tuoi obiettivi e requisiti aziendali. Ciò potrebbe comportare l'implementazione di modifiche senza tempi di inattività o l'implementazione graduale delle funzionalità in un ambiente o gruppo di utenti specifico prima del rilascio più ampio.

• Per rendere i carichi di lavoro portabili e astrarre le differenze tra gli ambienti, puoi utilizzare i container con Kubernetes. Per saperne di più, consulta Architettura di riferimento dell'ambiente ibrido GKE Enterprise.

• Stabilisci una catena di strumenti comune che funzioni in tutti gli ambienti di computing per il deployment, la configurazione e l'operazione dei carichi di lavoro. L'utilizzo di Kubernetes ti offre questa coerenza.

• Assicurati che le pipeline CI/CD siano coerenti tra gli ambienti di computing e che lo stesso insieme di file binari, pacchetti o container venga implementato in questi ambienti.

• Quando utilizzi Kubernetes, utilizza un sistema CI come Tekton per implementare una pipeline di deployment che esegue il deployment nei cluster e funziona in tutti gli ambienti. Per saperne di più, consulta Soluzioni DevOps su Google Cloud.

• Per aiutarti a rilasciare continuamente applicazioni sicure e affidabili, incorpora la sicurezza come parte integrante del processo DevOps (DevSecOps). Per maggiori informazioni, consulta Distribuire e proteggere la tua applicazione rivolta a internet in meno di un'ora utilizzando Dev(Sec)Ops Toolkit.

• Utilizza gli stessi strumenti per il logging e il monitoraggio in Google Cloud e negli ambienti cloud esistenti. Valuta la possibilità di utilizzare sistemi di monitoraggio open source. Per maggiori informazioni, vedi Pattern di logging e monitoraggio per cloud ibrido e multi-cloud.

• Se team diversi gestiscono i carichi di lavoro di test e produzione, l'utilizzo di strumenti separati potrebbe essere accettabile. Tuttavia, l'utilizzo degli stessi strumenti con autorizzazioni di visualizzazione diverse può contribuire a ridurre l'impegno e la complessità dell'addestramento.

• Quando scegli servizi di database, archiviazione e messaggistica per i test funzionali, utilizza prodotti con un equivalente gestito su Google Cloud. L'utilizzo di servizi gestiti contribuisce a ridurre l'impegno amministrativo di manutenzione degli ambienti di sviluppo e test.

• Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito. Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni basate sulla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

La tabella seguente mostra quali Google Cloud prodotti sono compatibili con i prodotti OSS comuni.

Prodotto OSS	Compatibile con il prodotto Google Cloud
Apache HBase	Bigtable
Apache Beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL, PostgreSQL	Cloud SQL
Cluster Redis, Redis, Memcached	Memorystore
Network File System (NFS)	Filestore
JMS, Kafka	Pub/Sub
Kubernetes	GKE Enterprise

Pattern ibridi e multi-cloud di business continuity

Il motivo principale per cui si prende in considerazione la continuità operativa per i sistemi mission-critical è aiutare un'organizzazione a essere resiliente e a continuare le sue operazioni aziendali durante e dopo gli eventi di errore. Grazie alla replica di sistemi e dati in più regioni geografiche ed evitando single point of failure, puoi ridurre al minimo i rischi di un disastro naturale che interessa l'infrastruttura locale. Altri scenari di errore includono un grave errore del sistema, un attacco informatico o persino un errore di configurazione del sistema.

L'ottimizzazione di un sistema per resistere ai guasti è essenziale per stabilire una continuità aziendale efficace. L'affidabilità del sistema può essere influenzata da diversi fattori, tra cui, a titolo esemplificativo, prestazioni, resilienza, disponibilità di uptime, sicurezza ed esperienza utente. Per saperne di più su come progettare e gestire servizi affidabili su Google Cloud, consulta il pilastro affidabilità del Google Cloud framework Well-Architected e gli elementi costitutivi dell'affidabilità in Google Cloud.

Questo pattern di architettura si basa su un deployment ridondante delle applicazioni in più ambienti di computing. In questo pattern, esegui il deployment delle stesse applicazioni in più ambienti di computing con l'obiettivo di aumentare l'affidabilità. La continuità aziendale può essere definita come la capacità di un'organizzazione di continuare le sue funzioni o i suoi servizi aziendali chiave a livelli accettabili predefiniti in seguito a un evento dirompente.

Il ripristino di emergenza (RE) è considerato un sottoinsieme della continuità aziendale, incentrato esplicitamente sull'assicurare che i sistemi IT che supportano le funzioni aziendali critiche siano operativi il prima possibile dopo un'interruzione. In generale, le strategie e i pianiREa spesso aiutano a formare una strategia di continuità aziendale più ampia. Dal punto di vista tecnologico, quando inizi a creare strategie di ripristino di emergenza, l'analisi dell'impatto aziendale deve definire due metriche chiave: il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO). Per ulteriori istruzioni sull'utilizzo di Google Cloud per il disaster recovery, consulta la Guida alla pianificazione del disaster recovery.

Più piccoli sono i valori target RPO e RTO, più rapidamente i servizi possono riprendersi da un'interruzione con una perdita di dati minima. Tuttavia, ciò implica costi più elevati perché significa creare sistemi ridondanti. I sistemi ridondanti in grado di eseguire la replica dei dati quasi in tempo reale e che operano alla stessa scala in seguito a un evento di errore aumentano la complessità, il sovraccarico amministrativo e i costi.

La decisione di selezionare una strategia di recupero di emergenza o un pattern deve essere basata su un'analisi dell'impatto sull'attività. Ad esempio, le perdite finanziarie subite anche per pochi minuti di inattività da un'organizzazione di servizi finanziari potrebbero superare di gran lunga il costo di implementazione di un sistema di RE. Tuttavia, le attività di altri settori potrebbero subire ore di inattività senza un impatto significativo sull'attività.

Quando esegui sistemi mission-critical in un data center on-premise, un approccio di RE consiste nel mantenere sistemi di standby in un secondo data center in una regione diversa. Un approccio più conveniente, tuttavia, consiste nell'utilizzare un ambiente di computing basato su cloud pubblico per scopi di failover. Questo approccio è il principale motore del pattern ibrido di business continuity. Il cloud può essere particolarmente interessante dal punto di vista dei costi, perché ti consente di disattivare parte dell'infrastruttura di RE quando non è in uso. Per ottenere una soluzione di RE a costi inferiori, una soluzione cloud consente a un'azienda di accettare il potenziale aumento dei valori RPO e RTO.

Il diagramma precedente illustra l'utilizzo del cloud come ambiente di failover o di ripristino di emergenza per un ambiente on-premise.

Una variante meno comune (e raramente richiesta) di questo pattern è il pattern multicloud di continuità operativa. In questo pattern, l'ambiente di produzione utilizza un provider di servizi cloud e l'ambienteREa utilizza un altro provider di servizi cloud. Se esegui il deployment di copie dei carichi di lavoro su più cloud provider, potresti aumentare la disponibilità oltre a quanto offerto da un deployment multiregionale.

La valutazione di un RE in più cloud rispetto all'utilizzo di un solo fornitore di servizi cloud con regioni diverse richiede un'analisi approfondita di diverse considerazioni, tra cui:

• Gestibilità
• Sicurezza
• Fattibilità complessiva.
• Costo
  • I potenziali costi per il trasferimento di dati in uscita da più di un cloud provider potrebbero essere elevati con la comunicazione inter-cloud continua.
  • Durante la replica dei database, il volume di traffico può essere elevato.
  • TCO e costo della gestione dell'infrastruttura di rete intercloud.

Se i tuoi dati devono rimanere nel tuo paese per soddisfare i requisiti normativi, l'utilizzo di un secondo provider di servizi cloud che si trova anche nel tuo paese come RE può essere un'opzione. L'utilizzo di un secondo cloud provider presuppone che non esista un'opzione per utilizzare un ambiente on-premise per creare una configurazione ibrida. Per evitare di riprogettare la tua soluzione cloud, idealmente il secondo provider cloud dovrebbe offrire tutte le funzionalità e i servizi necessari nella regione.

Considerazioni sulla progettazione

• Aspettativa di DR: gli obiettivi RPO e RTO che la tua attività vuole raggiungere devono guidare la pianificazione della creazione e dell'architettura di RE.
• Architettura della soluzione: con questo pattern, devi replicare le funzioni e le funzionalità esistenti del tuo ambiente on-premise per soddisfare le tue aspettativREza. Pertanto, devi valutare la fattibilità e la praticabilità del rehosting, del refactoring o della riprogettazione delle tue applicazioni per fornire le stesse funzioni (o più ottimizzate) e le stesse prestazioni nell'ambiente cloud.
• Progettazione e creazione: la creazione di una landing zone è quasi sempre un prerequisito per il deployment di carichi di lavoro aziendali in un ambiente cloud. Per maggiori informazioni, consulta Progettazione della landing zone in Google Cloud.

• Richiamo del ripristino di emergenza: è importante che la progettazione e la procedura di RE prendano in considerazione le seguenti domande:

  • Cosa attiva uno scenario di RE? Ad esempio, un RE potrebbe essere attivato dal malfunzionamento di funzioni o sistemi specifici nel sito principale.
  • Come viene richiamato il failover all'ambiente di RE? Si tratta di una procedura di approvazione manuale o può essere automatizzata per raggiungere un RTO target basso?
  • Come devono essere progettati i meccanismi di rilevamento e notifica degli errori di sistema per richiamare il failover in linea con l'RTO previsto?
  • Come viene reindirizzato il traffico all'ambiente di RE dopo il rilevamento dell'errore?

  Convalida le risposte a queste domande tramite i test.

• Test: testa e valuta attentamente il failover al RE. Assicurati che soddisfi le tue aspettative di RPO e RTO. In questo modo, potrai avere più sicurezza nell'invocare RE quando necessario. Ogni volta che viene apportata una nuova modifica o un nuovo aggiornamento alla soluzione di processo o tecnologica, esegui nuovamente i test.

• Competenze del team: uno o più team tecnici devono disporre delle competenze e dell'esperienza necessarie per creare, gestire e risolvere i problemi del carico di lavoro di produzione nell'ambiente cloud, a meno che l'ambiente non sia gestito da una terza parte.

Vantaggi

L'utilizzo di Google Cloud per la continuità operativa offre diversi vantaggi:

• Poiché Google Cloud ha molte regioni in tutto il mondo tra cui scegliere, puoi utilizzarlo per eseguire il backup o la replica dei dati in un sito diverso all'interno dello stesso continente. Puoi anche eseguire il backup o la replica dei dati in un sito su un altro continente.
• Google Cloud offre la possibilità di archiviare i dati in Cloud Storage in un bucket a due o più regioni. I dati vengono archiviati in modo ridondante in almeno due regioni geografiche separate. I dati archiviati in bucket multiregionali e a doppia regione vengono replicati in più regioni geografiche utilizzando la replica predefinita.
  • I bucket a due regioni forniscono ridondanza geografica per supportare i piani di continuità aziendale e di RE. Inoltre, per eseguire la replica più rapidamente, con un RPO inferiore, gli oggetti archiviati in due regioni possono utilizzare facoltativamente la replica turbo tra queste regioni.
  • Allo stesso modo, la replica multiregionale fornisce ridondanza in più regioni, archiviando i dati all'interno del confine geografico della multiregione.
• Fornisce una o più delle seguenti opzioni per ridurre le spese di capitale e le spese operative per creare un RE:
  • Le istanze VM arrestate comportano solo costi di archiviazione e sono notevolmente più economiche rispetto alle istanze VM in esecuzione. Ciò significa che puoi ridurre al minimo il costo di manutenzione dei sistemi di standby a freddo.
  • Il modello pay-per-use di Google Cloud significa che paghi solo per la capacità di archiviazione e di calcolo che utilizzi effettivamente.
  • Le funzionalità di elasticità, come la scalabilità automatica, ti consentono di scalare o ridurre automaticamente l'ambiente di RE in base alle esigenze.

Ad esempio, il seguente diagramma mostra un'applicazione in esecuzione in un ambiente on-premise (produzione) che utilizza componenti di ripristino suGoogle Cloud con Compute Engine, Cloud SQL e Cloud Load Balancing. In questo scenario, il database viene sottoposto a provisioning preliminare utilizzando un database basato su VM o un database gestito, come Cloud SQL, per un ripristino più rapido con replica continua dei dati. Google Cloud Puoi avviare le VM Compute Engine da snapshot pre-creati per ridurre i costi durante le normali operazioni. Con questa configurazione e dopo un evento di errore, il DNS deve puntare all'indirizzo IP esterno di Cloud Load Balancing.

Per rendere operativa l'applicazione nel cloud, devi eseguire il provisioning delle VM web e delle applicazioni. A seconda del livello RTO target e delle norme aziendali, l'intera procedura per richiamare un RE, eseguire il provisioning del carico di lavoro nel cloud e reindirizzare il traffico può essere completata manualmente o automaticamente.

Per velocizzare e automatizzare il provisioning dell'infrastruttura, valuta la possibilità di gestirla come codice. Puoi utilizzare Cloud Build, un servizio di integrazione continua, per applicare automaticamente i manifest Terraform al tuo ambiente. Per maggiori informazioni, consulta Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps.

Best practice

Quando utilizzi il pattern di continuità operativa, tieni presenti le seguenti best practice:

• Crea un piano di ripristino di emergenza che documenti la tua infrastruttura insieme alle procedure di failover e ripristino.
• Prendi in considerazione le seguenti azioni in base all'analisi dell'impatto sull'attività e agli RPO e RTO target identificati:
  • Decidi se il backup dei dati su Google Cloud è sufficiente o se devi prendere in considerazione un'altra strategia di RE (sistemi di standby freddo, caldo o attivo).
  • Definisci i servizi e i prodotti che puoi utilizzare come componenti di base per il tuo piano di RE.
  • Inquadra gli scenari di RE applicabili per le tue applicazioni e dati nell'ambito della strategia di RE selezionata.
• Valuta la possibilità di utilizzare il pattern di trasferimento quando esegui solo il backup dei dati. In caso contrario, il pattern mesh potrebbe essere una buona opzione per replicare l'architettura di rete dell'ambiente esistente.
• Riduci al minimo le dipendenze tra i sistemi in esecuzione in ambienti diversi, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni e ridurre la disponibilità complessiva.

• Evita il problema di split-brain. Se replichi i dati in modo bidirezionale tra gli ambienti, potresti essere esposto al problema di split-brain. Il problema di split-brain si verifica quando due ambienti che replicano i dati in modo bidirezionale perdono la comunicazione tra loro. Questa divisione può indurre i sistemi di entrambi gli ambienti a concludere che l'altro ambiente non è disponibile e che hanno accesso esclusivo ai dati. Ciò può portare a modifiche in conflitto dei dati. Esistono due modi comuni per evitare il problema di split-brain:

  • Utilizza un terzo ambiente di computing. Questo ambiente consente ai sistemi di verificare la presenza di un quorum prima di modificare i dati.

  • Consenti la riconciliazione delle modifiche ai dati in conflitto dopo il ripristino della connettività.

    Con i database SQL, puoi evitare il problema di split-brain rendendo inaccessibile l'istanza primaria originale prima che i client inizino a utilizzare la nuova istanza primaria. Per ulteriori informazioni, consulta Ripristino di emergenza per database Cloud SQL.

• Assicurati che i sistemi CI/CD e i repository di artefatti non diventino un unico punto di errore. Quando un ambiente non è disponibile, devi comunque essere in grado di eseguire il deployment di nuove release o applicare modifiche alla configurazione.

• Rendi tutti i workload portabili quando utilizzi sistemi di standby. Tutti i carichi di lavoro devono essere portabili (se supportati dalle applicazioni e fattibili) in modo che i sistemi rimangano coerenti tra gli ambienti. Puoi ottenere questo approccio prendendo in considerazione i container e Kubernetes. Utilizzando Google Kubernetes Engine (GKE) Enterprise, puoi semplificare la creazione e le operazioni.

• Integra la distribuzione dei sistemi di standby nella tua pipeline CI/CD. Questa integrazione contribuisce a garantire che le versioni e le configurazioni delle applicazioni siano coerenti nei vari ambienti.

• Assicurati che le modifiche al DNS vengano propagate rapidamente configurando il DNS con un valore Time to Live ragionevolmente breve in modo da poter reindirizzare gli utenti ai sistemi di standby in caso di emergenza.

• Seleziona i criteri DNS e di routing che corrispondono all'architettura e al comportamento della soluzione. Inoltre, puoi combinare più bilanciatori del carico regionali con norme di routing DNS per creare architetture di bilanciamento del carico globali per diversi casi d'uso, inclusa la configurazione ibrida.

• Utilizza più provider DNS. Quando utilizzi più provider DNS, puoi:

  • Migliora la disponibilità e la resilienza delle tue applicazioni e dei tuoi servizi.

  • Semplifica il deployment o la migrazione di applicazioni ibride che hanno dipendenze tra ambienti on-premise e cloud con una configurazione DNS multi-provider.

    Google Cloud offre una soluzione open source basata su octoDNS per aiutarti a configurare e gestire un ambiente con più provider DNS. Per maggiori informazioni, vedi DNS pubblico multi-provider utilizzando Cloud DNS.

• Utilizza i bilanciatori del carico quando utilizzi sistemi di standby per creare un failover automatico. Tieni presente che l'hardware del bilanciatore del carico può guastarsi.

• Utilizza Cloud Load Balancing anziché i bilanciatori del carico hardware per gestire alcuni scenari che si verificano quando utilizzi questo pattern di architettura. Le richieste dei client interni o le richieste dei client esterni possono essere reindirizzate all'ambiente principale o all'ambiente di RE in base a metriche diverse, ad esempio la divisione del traffico basata sul peso. Per saperne di più, consulta la panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.

• Prendi in considerazione l'utilizzo di Cloud Interconnect o Cross-Cloud Interconnect se il volume di trasferimento di dati in uscita da Google Cloud verso l'altro ambiente è elevato. Cloud Interconnect può contribuire a ottimizzare le prestazioni della connettività e potrebbe ridurre gli addebiti per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.

• Valuta la possibilità di utilizzare la tua soluzione partner preferita su Google Cloud Marketplace per facilitare i backup, le repliche e altre attività che soddisfano i tuoi requisiti, inclusi gli obiettivi RPO e RTO.

• Testa e valuta gli scenari di chiamata di RE per capire con quale facilità l'applicazione può ripristinarsi da un evento di disastro rispetto al valore RTO target.

• Crittografare le comunicazioni in transito. Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito. Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

Pattern di cloud bursting

Le applicazioni internet possono subire fluttuazioni estreme nell'utilizzo. Sebbene la maggior parte delle applicazioni aziendali non debba affrontare questa sfida, molte aziende devono gestire un diverso tipo di carico di lavoro burst: batch o CI/CD.

Questo pattern di architettura si basa su un deployment ridondante delle applicazioni in più ambienti di computing. L'obiettivo è aumentare la capacità, la resilienza o entrambe.

Sebbene tu possa gestire carichi di lavoro burst in un ambiente di computing basato su data center eseguendo il provisioning eccessivo delle risorse, questo approccio potrebbe non essere conveniente. Con i job batch, puoi ottimizzare l'utilizzo estendendo la loro esecuzione su periodi di tempo più lunghi, anche se ritardare i job non è pratico se sono sensibili al tempo.

L'idea del pattern cloud bursting è quella di utilizzare un ambiente di computing privato per il carico di base e passare temporaneamente al cloud quando hai bisogno di capacità aggiuntiva.

Nel diagramma precedente, quando la capacità dei dati raggiunge il limite in un ambiente privato on-premise, il sistema può ottenere capacità aggiuntiva da un ambienteGoogle Cloud quando necessario.

I principali fattori di questo pattern sono il risparmio di denaro e la riduzione del tempo e dell'impegno necessari per rispondere alle modifiche dei requisiti di scalabilità. Con questo approccio, paghi solo le risorse utilizzate per gestire i carichi aggiuntivi. Ciò significa che non devi eseguire il provisioning eccessivo dell'infrastruttura. Puoi invece sfruttare le risorse cloud on demand e scalare in base alla domanda e a qualsiasi metrica predefinita. Di conseguenza, la tua azienda potrebbe evitare interruzioni del servizio durante i periodi di picco della domanda.

Un potenziale requisito per gli scenari di cloud bursting è la portabilità dei carichi di lavoro. Quando consenti il deployment dei carichi di lavoro in più ambienti, devi astrarre le differenze tra gli ambienti. Ad esempio, Kubernetes ti offre la possibilità di ottenere coerenza a livello di carico di lavoro in diversi ambienti che utilizzano infrastrutture diverse. Per saperne di più, consulta Architettura di riferimento dell'ambiente ibrido GKE Enterprise.

Considerazioni sulla progettazione

Il pattern di cloud bursting si applica ai carichi di lavoro interattivi e batch. Quando hai a che fare con carichi di lavoro interattivi, devi determinare come distribuire le richieste tra gli ambienti:

• Puoi instradare le richieste degli utenti in entrata a un bilanciatore del carico che viene eseguito nel data center esistente, quindi fare in modo che il bilanciatore del carico distribuisca le richieste tra le risorse locali e cloud.

  Questo approccio richiede che il bilanciatore del carico o un altro sistema in esecuzione nel data center esistente tenga traccia anche delle risorse allocate nel cloud. Il bilanciamento del carico o un altro sistema deve anche avviare lo scale up o lo scale down automatico delle risorse. Utilizzando questo approccio, puoi ritirare tutte le risorse cloud durante i periodi di bassa attività. Tuttavia, l'implementazione di meccanismi per il monitoraggio delle risorse potrebbe superare le funzionalità delle tue soluzioni di bilanciamento del carico e quindi aumentare la complessità complessiva.

• Invece di implementare meccanismi per monitorare le risorse, puoi utilizzare Cloud Load Balancing con un backend gruppo di endpoint di rete (NEG) con connettività ibrida. Utilizzi questo bilanciatore del carico per instradare richieste client interni o richieste client esterni ai backend che si trovano sia on-premise sia in Google Cloud e che si basano su metriche diverse, come la suddivisione del traffico basata sul peso. Inoltre, puoi scalare i backend in base alla capacità di gestione del bilanciamento del carico per i carichi di lavoro in Google Cloud. Per saperne di più, consulta la panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.

  Questo approccio offre diversi vantaggi aggiuntivi, ad esempio la possibilità di sfruttare le funzionalità di protezione DDoS di Google Cloud Armor, WAF e la memorizzazione nella cache dei contenuti all'edge del cloud utilizzando Cloud CDN. Tuttavia, devi dimensionare la connettività di rete ibrida per gestire il traffico aggiuntivo.

• Come evidenziato in Portabilità del workload, un'applicazione potrebbe essere portabile in un ambiente diverso con modifiche minime per ottenere la coerenza del workload, ma ciò non significa che l'applicazione funzioni allo stesso modo in entrambi gli ambienti. Le differenze nel calcolo sottostante, nelle funzionalità di sicurezza dell'infrastruttura o nell'infrastruttura di rete, insieme alla vicinanza ai servizi dipendenti, in genere determinano le prestazioni. Grazie ai test, puoi avere una visibilità più accurata e comprendere le aspettative di rendimento.

• Puoi utilizzare i servizi di infrastruttura cloud per creare un ambiente per ospitare le tue applicazioni senza portabilità. Utilizza i seguenti approcci per gestire le richieste dei client quando il traffico viene reindirizzato durante i periodi di picco della domanda:

  • Utilizza strumenti coerenti per monitorare e gestire questi due ambienti.
  • Garantisci un controllo delle versioni coerente dei workload e che le origini dati siano aggiornate.
  • Potresti dover aggiungere l'automazione per eseguire il provisioning dell'ambiente cloud e reindirizzare il traffico quando la domanda aumenta e il workload cloud dovrebbe accettare le richieste dei client per la tua applicazione.

• Se intendi arrestare tutte le risorse Google Cloud durante i periodi di bassa domanda, l'utilizzo dei criteri di routing DNS principalmente per il bilanciamento del carico del traffico potrebbe non essere sempre ottimale. Ciò è dovuto principalmente a quanto segue:

  • L'inizializzazione delle risorse può richiedere un po' di tempo prima che possano essere utilizzate dagli utenti.
  • Gli aggiornamenti DNS tendono a propagarsi lentamente su internet.

  Di conseguenza:

  • Gli utenti potrebbero essere indirizzati all'ambiente cloud anche quando non sono disponibili risorse per elaborare le loro richieste.
  • Gli utenti potrebbero continuare a essere indirizzati temporaneamente all'ambiente on-premise mentre gli aggiornamenti DNS vengono propagati su internet.

Con Cloud DNS, puoi scegliere i criteri DNS e di routing che si allineano all'architettura e al comportamento della tua soluzione, ad esempio i criteri di routing DNS basati sulla geolocalizzazione. Cloud DNS supporta anche i controlli di integrità per il bilanciatore del carico di rete passthrough interno e il bilanciatore del carico delle applicazioni interno. In questo caso, potresti incorporarlo nella configurazione DNS ibrida complessiva basata su questo pattern.

In alcuni scenari, puoi utilizzare Cloud DNS per distribuire le richieste dei client con controlli di integrità su Google Cloud, ad esempio quando utilizzi bilanciatori del carico delle applicazioni interni o bilanciatori del carico delle applicazioni interni tra regioni. In questo scenario, Cloud DNS controlla l'integrità complessiva del bilanciatore del carico delle applicazioni interno, che a sua volta controlla l'integrità delle istanze di backend. Per saperne di più, consulta Gestire i criteri di routing DNS e i controlli di integrità.

Puoi anche utilizzare Cloud DNS split horizon. Lo split horizon di Cloud DNS è un approccio per configurare risposte o record DNS in base alla posizione o alla rete specifica dell'origine della query DNS per lo stesso nome di dominio. Questo approccio viene comunemente utilizzato per soddisfare i requisiti in cui un'applicazione è progettata per offrire un'esperienza privata e una pubblica, ognuna con funzionalità uniche. Questo approccio consente anche di distribuire il carico di traffico tra gli ambienti.

Tenendo conto di queste considerazioni, il cloud bursting si presta meglio ai carichi di lavoro batch che a quelli interattivi.

Vantaggi

I principali vantaggi del pattern di architettura cloud bursting includono:

• Il cloud bursting ti consente di riutilizzare gli investimenti esistenti in data center e ambienti di computing privati. Questo riutilizzo può essere permanente o in vigore fino a quando non è prevista la sostituzione delle apparecchiature esistenti, a quel punto potresti prendere in considerazione una migrazione completa.
• Poiché non devi più mantenere la capacità in eccesso per soddisfare i picchi di domanda, potresti essere in grado di aumentare l'utilizzo e l'efficacia in termini di costi dei tuoi ambienti di computing privati.
• Il cloud bursting ti consente di eseguire i job batch in modo tempestivo senza la necessità di eseguire l'overprovisioning delle risorse di calcolo.

Best practice

Quando implementi il cloud bursting, considera le seguenti best practice:

• Per garantire che i carichi di lavoro in esecuzione nel cloud possano accedere alle risorse nello stesso modo dei carichi di lavoro in esecuzione in un ambiente on-premise, utilizza il pattern mesh con il principio di accesso alla sicurezza con privilegi minimi. Se la progettazione del carico di lavoro lo consente, puoi consentire l'accesso solo dal cloud all'ambiente di computing on-premise e non viceversa.
• Per ridurre al minimo la latenza per la comunicazione tra gli ambienti, scegli una regioneGoogle Cloud geograficamente vicina al tuo ambiente di computing privato. Per maggiori informazioni, consulta Best practice per la scelta delle regioni di Compute Engine.
• Quando utilizzi il cloud bursting solo per i carichi di lavoro batch, riduci la superficie di attacco alla sicurezza mantenendo private tutte le risorse. Google Cloud Non consentire l'accesso diretto da internet a queste risorse, anche se utilizzi il bilanciamento del carico esterno Google Cloud per fornire il punto di ingresso al workload.

• Seleziona i criteri DNS e di routing che corrispondono al tuo pattern di architettura e al comportamento della soluzione di destinazione.

  • Nell'ambito di questo pattern, puoi applicare la progettazione dei criteri DNS in modo permanente o quando hai bisogno di capacità aggiuntiva utilizzando un altro ambiente durante i periodi di picco della domanda.
  • Puoi utilizzare le policy di routing DNS basate sulla geolocalizzazione per avere un endpoint DNS globale per i tuoi bilanciatori del carico regionali. Questa tattica ha molti casi d'uso per le policy di routing DNS basate sulla geolocalizzazione, incluse le applicazioni ibride che utilizzano Google Cloud insieme a un deployment on-premise in cui esiste la regione Google Cloud .

  • Se devi fornire record diversi per le stesse query DNS, puoi utilizzare DNS split horizon, ad esempio query da client interni ed esterni.

    Per saperne di più, consulta le architetture di riferimento per DNS ibrido.

• Per garantire che le modifiche DNS vengano propagate rapidamente, configura il DNS con un valore Time To Live ragionevolmente breve, in modo da poter reindirizzare gli utenti ai sistemi di standby quando hai bisogno di capacità aggiuntiva utilizzando gli ambienti cloud.

• Per i job che non sono altamente sensibili al tempo e non archiviano dati localmente, valuta la possibilità di utilizzare istanze VM spot, che sono notevolmente più economiche delle normali istanze VM. Un prerequisito, tuttavia, è che se il job VM viene prerilasciato, il sistema deve essere in grado di riavviarlo automaticamente.

• Utilizza i container per ottenere la portabilità del carico di lavoro, ove applicabile. Inoltre, GKE Enterprise può essere una tecnologia abilitante chiave per questo design. Per maggiori informazioni, consulta Architettura di riferimento dell'ambiente ibrido GKE Enterprise.

• Monitora il traffico inviato da Google Cloud a un ambiente di computing diverso. Questo traffico è soggetto a costi per il trasferimento di dati in uscita.

• Se prevedi di utilizzare questa architettura a lungo termine con un volume elevato di trasferimento di dati in uscita, valuta l'utilizzo di Cloud Interconnect. Cloud Interconnect può contribuire a ottimizzare le prestazioni della connettività e potrebbe ridurre gli addebiti per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.

• Quando viene utilizzato Cloud Load Balancing, devi utilizzare le relative funzionalità di ottimizzazione della capacità dell'applicazione , se applicabile. In questo modo, puoi affrontare alcune delle sfide di capacità che possono verificarsi nelle applicazioni distribuite a livello globale.

• Autentica le persone che utilizzano i tuoi sistemi stabilendo un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in sicurezza oltre i confini dell'ambiente.

• Per proteggere le informazioni sensibili, è consigliabile criptare tutte le comunicazioni in transito. Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

Modelli di architettura ibrida e multi-cloud: novità

• Scopri come affrontare l'architettura ibrida e multicloud e come scegliere i carichi di lavoro adatti.
• Scopri di più sui pattern di architettura di rete adatti ai pattern di architettura ibrida e multi-cloud selezionati.
• Scopri di più sugli archetipi di deployment per le applicazioni cloud.
• Scopri come progettare ed eseguire il deployment di un'applicazione web di e-commerce utilizzando diverse architetture, tra cui un'applicazione web di e-commerce basata su microservizi utilizzando GKE e un'applicazione web dinamica basata su API serverless.