Modelli di architettura ibrida e multi-cloud

Last reviewed 2023-12-14 UTC

Questa pagina fornisce una visualizzazione di una sola pagina di tutte le pagine presenti nella sezione Crea modelli ibridi e multi-cloud usando Google Cloud. Puoi stampare questa pagina o salvarla in formato PDF utilizzando la funzione di stampa del browser e scegliendo l'opzione Salva come PDF. Questa pagina non fornisce un riquadro del sommario sul lato destro.

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

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

• Crea architetture ibride e multi-cloud: illustra la pianificazione di una strategia per l'architettura di un ambiente ibrido e multi-cloud e la configurazione con Google Cloud.
• Modelli di architettura ibrida e multi-cloud: illustra i modelli di architettura comuni da adottare nell'ambito di una strategia ibrida e multi-cloud (questo documento).
• Modelli di architettura di networking sicura ibrida e multi-cloud: illustra i pattern di architettura di networking ibrida e multi-cloud da un punto di vista del networking.

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 sia necessario 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 di architettura è un modo ripetibile per strutturare più componenti funzionali di una soluzione, un'applicazione o un servizio tecnologico per creare una soluzione riutilizzabile che soddisfi determinati requisiti o casi d'uso. Una soluzione tecnologica basata su cloud è spesso composta da diversi servizi cloud distinti e distribuiti. Questi servizi collaborano per fornire le funzionalità richieste. In questo contesto, ogni servizio è considerato della soluzione tecnologica. Analogamente, un'applicazione può essere composta da più livelli, moduli o servizi funzionali, ciascuno dei quali può rappresentare un componente funzionale dell'architettura dell'applicazione. Un'architettura di questo tipo può essere standardizzata per risolvere casi d'uso aziendali specifici e fungere da modello di base riutilizzabile.

Per definire in generale un pattern di architettura 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 frontend per fornire una Graphic User Interface o funzioni di backend al che forniscono l'accesso ai dati.
• Il modo in cui i componenti comunicano tra loro e con i sistemi esterni. o utenti. Nelle applicazioni moderne, questi componenti interagiscono tramite API o interfacce ben definite. Esistono diversi modelli di comunicazione, ad esempio asincroni e sincroni, basati su richiesta/risposta o su coda.

Di seguito sono riportate le due categorie principali di schemi di architettura ibrida e multi-cloud:

• Modelli di architettura distribuita: Questi pattern si basano su un deployment distribuito di carichi di lavoro o componenti. Ciò significa che eseguono un'applicazione (o componenti specifici di quell'applicazione) nell'ambiente di calcolo più adatto al pattern. In questo modo il pattern può trarre il massimo profitto dalle diverse proprietà caratteristiche degli ambienti di calcolo distribuiti e interconnessi.
• Modelli di architettura ridondanti: Questi pattern si basano su deployment ridondanti di carichi di lavoro. In queste di progettazione, il deployment delle stesse applicazioni e dei relativi componenti ambienti di computing. L'obiettivo è aumentare il rendimento capacità o resilienza di un'applicazione o per replicare per lo sviluppo e il test.

Quando implementi il pattern di architettura selezionato, devi utilizzare un archetipo di implementazione adatto. Gli archetipi di deployment sono zonali, regionali, multiregionali o globali. Questa selezione costituisce la base per la costruzione di architetture di deployment specifiche per l'applicazione. Ogni archetipo di deployment definisce una combinazione di errori domini all'interno dei quali può operare un'applicazione. Questi domini in errore possono comprendono uno o più zone o regioni Google Cloud, e può essere esteso per includere data center on-premise o domini in errore in altri cloud provider.

Questa serie contiene le seguenti pagine:

• Modelli di architettura distribuita

  • Modello ibrido multilivello

  • Pattern multi-cloud partizionato

  • Modello di analisi ibrida e multi-cloud

  • Pattern ibrido periferico

• Pattern di architettura ridondanti

  • Pattern ibrido dell'ambiente
  • Modelli di business continuity ibrida e multi-cloud
  • Modello di bursting cloud

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

• Saud Albazei | Customer Engineer, Application Modernization
• Anna Berenberg | Ingegnere
• Marco Ferrari | Cloud Solutions Architect
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Cloud Solutions Architect
• Marca Schlagenhauf | Scrittore tecnico, networking
• Daniel Strebel | Solution Lead EMEA, Application Modernization
• Ammett Williams | Developer Relations Engineer

Modelli di architettura distribuita

Quando esegui la migrazione da un ambiente di calcolo non ibrido o non multi-cloud a un'architettura ibrida o multi-cloud, valuta innanzitutto i vincoli delle tue applicazioni esistenti e in che modo questi vincoli potrebbero portare a un errore dell'applicazione. Questo considerazione diventa più importante quando le applicazioni o i componenti dell'applicazione operano in modo distribuito in ambienti diversi. Dopo il giorno hai considerato i vincoli, sviluppa un piano per evitarli o superarli. Assicurati di prendere in considerazione le funzionalità uniche di ogni ambiente di calcolo in un'architettura distribuita.

Nota: puoi applicare diversi pattern di architettura a diverse applicazioni, in base ai casi d'uso e ai requisiti. Ciò significa che potresti avere più applicazioni con diversi pattern di architettura ibrida e multi-cloud in esecuzione contemporaneamente.

Note sul layout

Le seguenti considerazioni di progettazione si applicano ai pattern di deployment distribuito. 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, che può verificarsi una latenza di comunicazione. Questa latenza è influenzata dalla connettività della 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 applicazioni e la loro sensibilità alla rete ritardi. Le applicazioni che possono tollerare la latenza sono candidati più adatte per il deployment iniziale distribuito in un ambiente ibrido o multi-cloud.

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 di cui hai bisogno e la durata prevista nell'ambito della fase di pianificazione. Ad esempio, se prevedi di utilizzare un'architettura ibrida o multi-cloud per un periodo di tempo prolungato o permanente, prendi in considerazione l'utilizzo Cloud Interconnect. Per ridurre i costi del trasferimento di dati in uscita e ottimizzare la connettività ibrida. sulle prestazioni di rete, Cloud Interconnect sconta i costi per il trasferimento di dati in uscita che soddisfano le condizioni scontate per le velocità di trasferimento di dati.

Affidabilità

L'affidabilità è un aspetto fondamentale nella progettazione di sistemi IT. La disponibilità di uptime è un aspetto essenziale dell'affidabilità del sistema. In Google Cloud, puoi aumentare la resilienza di un'applicazione implementando componenti ridondanti di quella stessa applicazione in più zone in un'unica regione o in più regioni, con funzionalità di passaggio. La ridondanza è uno degli elementi chiave per per migliorare la disponibilità complessiva di un'applicazione. Per le applicazioni con un una configurazione distribuita in ambienti ibridi e multi-cloud, è importante mantengano un livello coerente di disponibilità.

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 attraverso i vari componenti e l'infrastruttura di supporto (tra cui disponibilità connettività ibrida) in tutti gli ambienti. Questo concetto è noto anche come 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 ulteriori informazioni, consulta Disponibilità composita: calcolo della disponibilità complessiva dell'infrastruttura cloud.

Per raggiungere il livello di affidabilità del sistema desiderato, devi definire metriche di affidabilità e progettare applicazioni per autoripararsi e resistere in modo efficace alle interruzioni nei diversi ambienti. Per aiutarti a definire modi appropriati per misurare l'esperienza dei clienti con i tuoi servizi, consulta Definire gli obiettivi di affidabilità.

Connettività ibrida e multi-cloud

I requisiti di comunicazione tra le applicazioni distribuite dovrebbe influenzare la selezione della connettività di rete ibrida. . Ogni opzione di connettività presenta vantaggi e svantaggi, nonché fattori specifici da prendere in considerazione, come costo, volume di traffico, sicurezza e così via. Per ulteriori informazioni, consulta Considerazioni sulla progettazione della connettività .

Gestibilità

Strumenti di gestione e monitoraggio coerenti e unificati sono essenziali per configurazioni ibride e multi-cloud efficaci (con o senza portabilità dei carichi di lavoro). Nel breve periodo, questi strumenti possono aumentare i costi di sviluppo, test e operazioni. Tecnicamente, più cloud provider usi, più complessa è gestione degli ambienti . La maggior parte dei fornitori di servizi per il cloud pubblico non solo hanno caratteristiche diverse, ma prevedono diversi 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 e ai vantaggi a lungo termine.

Costo

Ogni provider di servizi cloud in un ambiente multicloud ha le proprie metriche e i propri strumenti di fatturazione. Per una maggiore visibilità e dashboard unificate, valuta la possibilità di utilizzare strumenti di ottimizzazione e gestione dei costi multicloud. Ad esempio, quando creando soluzioni cloud-first in più ambienti cloud, ciascuno i prodotti, i prezzi, gli sconti e gli strumenti di gestione del fornitore possono generare costi incongruenze tra questi ambienti.

Ti consigliamo di avere 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 provenienti dal cloud i provider che usi e che usano Google Cloud Blocco gestione dei costi di Looker Cloud, puoi creare una vista centralizzata dei tuoi costi multi-cloud. Questa visualizzazione può aiutarti a fornire una visualizzazione consolidata dei report sulla spesa su più cloud. Per maggiori informazioni, consulta la strategia per ottimizzare in modo efficace la gestione dei costi di fatturazione cloud.

Ti consigliamo inoltre di utilizzare la pratica di FinOps per rendere i costi visibili. 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 a incoraggiare la responsabilità individuale. In questo modello, il team centrale deve standardizzare il processo, la generazione di report, e gli strumenti per l'ottimizzazione dei costi. Per ulteriori informazioni sui diversi aspetti e consigli di ottimizzazione dei costi da prendere in considerazione, consulta Framework di architettura di Google Cloud: ottimizzazione dei costi.

Spostamento dei dati

Lo spostamento dei dati è un aspetto importante per la strategia e la pianificazione dell'architettura ibrida e multi-cloud, in particolare per i sistemi distribuiti. Le aziende devono identificare i diversi casi d'uso aziendali, i dati che li supportano e la classificazione dei dati (per i settori regolamentati). Inoltre, devono considerare in che modo la memorizzazione, la condivisione e l'accesso ai dati per i sistemi distribuiti in più ambienti possono influire sulle prestazioni delle applicazioni e sulla coerenza dei dati. Questi fattori possono influenzare l'architettura dell'applicazione e della pipeline di dati. l'insieme completo di strumenti opzioni di spostamento dei dati consente alle aziende di soddisfare le loro esigenze specifiche e adottare soluzioni e multi-cloud senza compromettere la semplicità, l'efficienza delle prestazioni.

Sicurezza

Quando esegui la migrazione delle applicazioni al cloud, è importante prendere in considerazione funzionalità di sicurezza cloud-first come coerenza, osservabilità e visibilità della sicurezza unificata. Ogni cloud provider pubblico adotta un approccio diverso, pratiche e funzionalità per la sicurezza. È importante analizzare e allineare queste capacità per creare un'architettura di sicurezza standard e funzionale. Anche controlli IAM efficaci, crittografia dei dati, scansione 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 sopra indicate. Possono aiutarti a ridurre al minimo le probabilità di introduzione di complessità nell'architettura man mano che le applicazioni o i volumi di traffico aumentano. Inoltre, la progettazione e la costruzione di una zona di destinazione è quasi sempre prerequisito per il deployment dei 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 reti. Per ulteriori informazioni, consulta Design delle zone di destinazione in Google Cloud.

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

• Pattern ibrido a più livelli
• Modello multicloud partizionato
• Modello di analisi ibrida e multi-cloud
• Modello ibrido perimetrale

Modello 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 in ambienti di calcolo diversi. Nell'ambito del pattern di architettura ibrida a più livelli, gli ambienti di calcolo si trovano in un ambiente di calcolo privato on-premise e in Google Cloud.

I componenti dell'applicazione frontend sono esposti direttamente agli utenti finali o ai dispositivi. Come 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 solitamente si basano su applicazioni di backend per archiviare e gestire i dati, nonché eventualmente la logica aziendale e l'elaborazione degli input utente, spesso sono senza stato o gestiscono solo volumi limitati di dati.

Per essere 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. Nella alcune architetture, la logica di business potrebbe essere incorporata di strumento di authoring. Le nuove release delle applicazioni di backend tendono a essere meno frequenti le release per le applicazioni di frontend. Le applicazioni di backend devono gestire le seguenti sfide:

• Gestione di un grande volume di richieste
• Gestione di un grande volume di dati
• Protezione dei dati
• Mantenimento di dati attuali e aggiornati in tutte le repliche di sistema

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

• Frontend web e livello di presentazione
• Livello di applicazione
• Accesso ai dati o livello di backend

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

Nota: l'implementazione di questa architettura e la definizione del suo possono variare a seconda che i livelli siano suddivisi in singoli sistemi e livelli o combinarli.

Il pattern di architettura ibrida a più livelli si concentra sul deployment dei componenti dell'applicazione frontend esistenti nel cloud pubblico. In questo schema, mantieni i componenti delle applicazioni di backend esistenti nel proprio ambiente di computing privato. A seconda delle dimensioni e della progettazione specifica dell'applicazione, è possibile migrare i componenti delle applicazioni frontend caso per caso. Per maggiori informazioni le informazioni, vedi Eseguire la migrazione a Google Cloud.

Se hai già un'applicazione con componenti di backend e frontend ospitati nel tuo ambiente on-premise, valuta i limiti della tua attuale architettura. Ad esempio, man mano che l'applicazione si espande e le richieste relative alle sue prestazioni e affidabilità aumentano, devi iniziare a valutare se parti dell'applicazione devono essere sottoposte a refactoring o spostate in un'architettura diversa e più ottimale. Il pattern di architettura ibrida a più livelli ti consente di spostare alcuni carichi di lavoro e componenti dell'applicazione sul cloud prima di eseguire una transizione completa. È inoltre essenziale considerare il costo, il tempo e il rischio associati ad esempio una migrazione.

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

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

Con il modello di architettura ibrida a più livelli, puoi sfruttare Infrastruttura Google Cloud e servizi globali, come mostrato nell'esempio nel diagramma seguente. Il frontend dell'applicazione è accessibile tramite Google Cloud. Può anche aggiungere elasticità al frontend utilizzando scalare automaticamente per rispondere in modo dinamico ed efficiente alla domanda di scalabilità senza rispetto al provisioning dell'infrastruttura. Esistono diverse architetture che 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 il video 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 di commercio digitale su Google Cloud.

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

Nel tempo, il numero di applicazioni di cui esegui il deployment nel cloud pubblico al punto in cui potresti prendere in considerazione lo spostamento dell'applicazione di backend al cloud pubblico. Se prevedi di gestire un traffico elevato, optare per i servizi gestiti sul cloud potrebbe aiutarti a risparmiare sui costi di progettazione per la gestione della tua infrastruttura. Valuta questa opzione, a meno che vincoli o requisiti non prevedano l'hosting dei componenti dell'applicazione di backend on-premise. Ad esempio, se i tuoi dati di backend sono soggetti a limitazioni normative, probabilmente dovrai conservarli on-premise. Tuttavia, se applicabili e conformi, l'utilizzo di funzionalità di protezione dei dati sensibili come le tecniche di anonimizzazione può aiutarti a spostare questi dati quando necessario.

Nel pattern di architettura ibrida a più livelli, puoi anche utilizzare Google Distributed Cloud in alcuni scenari. Distributed Cloud ti consente di eseguire Google Kubernetes Engine su hardware dedicato fornito e gestito da Google è separato dal data center Google Cloud. Per garantire che Distributed Cloud soddisfi le tue esigenze attuali e future i requisiti, conoscere i limiti di Distributed Cloud rispetto a una zona GKE convenzionale basata su cloud.

Vantaggi

Concentrarsi innanzitutto sulle applicazioni frontend presenta diversi vantaggi, tra cui:

• I componenti frontend dipendono dalle risorse di backend e occasionalmente da altri componenti frontend.
• I componenti di backend non dipendono dai componenti frontend. Pertanto, l'isolamento e la migrazione delle applicazioni frontend tendono a essere meno complessi rispetto alla migrazione delle applicazioni di backend.
• Poiché le applicazioni frontend spesso non hanno stato o non gestiscono i dati da sole, la migrazione è tendenzialmente meno complessa rispetto ai backend.
  • I componenti di frontend possono essere ottimizzati nell'ambito della migrazione per utilizzare stateless. Per ulteriori informazioni, guarda Come trasferire app web stateful in Cloud Run su YouTube.

Deployment di applicazioni frontend esistenti o di recente sviluppo 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/deployment continuo (CI/CD). Puoi utilizzare CI/CD per inviare aggiornamenti in modo efficiente e automatizzato. Per maggiori informazioni le informazioni, vedi CI/CD su Google Cloud.
• I frontend sensibili alle prestazioni con carico di traffico variabile possono essere vantaggiosi in modo sostanziale dal bilanciamento del carico, dai deployment multiregionali, Cloud CDN di memorizzazione nella cache, serverless e scalabilità automatica che consenta il deployment (idealmente architettura stateless).

• L'adozione di microservizi con container utilizzando una piattaforma gestita sul 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 frontend che prevedono team che collaborano alla stessa applicazione. Quel tipo di team una struttura richiede un approccio iterativo e una manutenzione continua. Alcuni dei vantaggi utilizzando il microfrontend sono i seguenti:

  • Può essere trasformato in moduli di microservizi indipendenti per sviluppo, test e deployment.
  • Offre una separazione degli elementi in cui i singoli team di sviluppo selezionare le tecnologie e il codice che preferiscono.
  • Può favorire cicli rapidi di sviluppo e implementazione senza influenzare gli altri componenti del frontend che potrebbero essere gestiti altre squadre.

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

• proxy API gestiti nel cloud aiuto per:

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

Puoi anche applicare il pattern ibrido a più livelli al contrario, eseguendo il deployment i backend nel cloud mantenendo i frontend negli ambienti di computing privati. Sebbene sia meno comune, questo approccio è preferibile quando si ha a che fare con un frontend monolitico e di grandi dimensioni. 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 di questa architettura. Apigee ibrido è utile come piattaforma per creare e gestire proxy API in un deployment ibrido un modello di machine learning. Per ulteriori informazioni, vedi Architettura a basso accoppiamento, tra cui architetture monolitiche e a microservizi a più livelli.

Best practice

Utilizza le informazioni riportate in questa sezione per pianificare la tua architettura ibrida a più livelli.

Best practice per ridurre la complessità

Quando applichi il pattern di architettura ibrida a più livelli, considera le seguenti best practice che possono aiutarti a ridurre il suo complesso di deployment e operativo complessivo:

• 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 utente coinvolge sistemi che si connettono su più ambienti di calcolo, è importante una connettività veloce e a bassa latenza tra questi sistemi. Per soddisfare le aspettative di disponibilità e prestazioni, devi progettare per garantire un'alta disponibilità, una bassa latenza e livelli di throughput appropriati. Dal punto di vista della sicurezza, la comunicazione deve essere granulare e controllato. Idealmente, dovresti esporre dell'applicazione mediante API sicure. Per ulteriori informazioni, vedi Traffico in uscita con accesso limitato.

• Per ridurre al minimo la latenza di comunicazione tra gli ambienti, seleziona un'opzione Regione Google Cloud geograficamente vicino all'ambiente di computing privato in cui sono ospitati i componenti di backend dell'applicazione. Per ulteriori informazioni, vedi Best practice per la selezione delle regioni di Compute Engine.
• Riduci al minimo le dipendenze elevate tra sistemi in esecuzione in diversi ambienti, in particolare quando le comunicazioni sono gestite in modo sincrono. Queste dipendenze possono rallentare le prestazioni, ridurre la disponibilità complessiva e potenzialmente comportare costi aggiuntivi per il trasferimento dei dati in uscita.
• Con il modello di architettura ibrida a più livelli, potresti avere dimensioni i volumi di traffico in entrata dagli ambienti on-premise in entrata rispetto al traffico in uscita da Google Cloud. Tuttavia, devi conoscere il volume previsto di trasferimenti di dati in uscita che esce da Google Cloud. Se prevedi di utilizzare questa architettura a lungo termine con volumi elevati di trasferimento di dati in uscita, ti consigliamo 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 maggiori informazioni, consulta i prezzi di Cloud Interconnect.
• Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito. Se la crittografia è richiesta a livello di connettività, puoi utilizzare i tunnel VPN, la VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

• Per superare incoerenze nei protocolli, nelle API e nell'autenticazione in backend diversi, consigliamo, ove applicabile, eseguire il deployment di un gateway API o di un proxy come facade (facade). Questo gateway o proxy agisce come punto di controllo centralizzato ed esegue le seguenti misure:

  • Implementa misure di sicurezza aggiuntive.
  • Protegge le app client e altri servizi dalle modifiche al codice del backend.
  • facilita gli audit trail per la comunicazione tra tutti delle applicazioni cross-environment e dei relativi componenti disaccoppiati.
  • Agisce come livello di comunicazione intermedio tra i servizi legacy e modernizzati.
    • Apigee e Apigee hybrid ti consentono di ospitare e gestire gateway ibridi e di livello enterprise in ambienti on-premise, edge, altri cloud e Google Cloud.

• Per facilitare l'implementazione di configurazioni ibride, utilizza il bilanciamento del carico Cloud con connettività ibrida. Ciò significa che puoi estendere i vantaggi del bilanciamento del carico del cloud ai servizi ospitati nel tuo ambiente di calcolo on-premise. Questo approccio consente di migrazioni dei carichi di lavoro a Google Cloud con un servizio minimo o nullo un'interruzione del servizio, garantendo una transizione senza problemi per i servizi distribuiti. Per ulteriori informazioni, vedi Panoramica dei gruppi di endpoint di rete con connettività ibrida.

• A volte, l'utilizzo di un gateway API o di un proxy Un bilanciatore del carico delle applicazioni insieme, possono fornire una soluzione più solida per la gestione, proteggere e distribuire il traffico delle API su larga scala. L'utilizzo del bilanciamento del carico di Cloud con i gateway API ti consente di:

  • 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 ulteriori informazioni, guarda API ad alte prestazioni con Apigee e Cloud CDN su YouTube.
  • Implementa la gestione avanzata del traffico.
  • Utilizzare Google Cloud Armor come protezione dagli attacchi DDoS e sicurezza della rete per proteggere le API.
  • Gestisci un bilanciamento del carico efficiente tra gateway in più regioni. Per saperne di più, guarda Protezione delle API e implementazione del failover multiregione con Private Service Connect e Apigee su YouTube.

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

  • Utilizza le funzionalità di Cloud Service Mesh per consentire una 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.
  • Usa una piattaforma di gestione delle API come Apigee, consente alla tua organizzazione e alle entità esterne di utilizzare questi servizi e mostrarle come API.

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

• Esegui il deployment di sistemi di gestione delle configurazioni e CI/CD nel cloud pubblico. Per ulteriori informazioni, vedi Pattern dell'architettura di networking speculare.

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

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

• Anche se in questo pattern l'attenzione si concentra sulle applicazioni frontend, consapevoli della necessità di modernizzare le applicazioni di backend. Se di sviluppo delle applicazioni di backend è notevolmente più lento rispetto a delle applicazioni frontend, la differenza può causare una maggiore complessità.
• Il trattamento delle API come interfacce di backend semplifica le integrazioni, lo sviluppo frontend, le interazioni con i servizi e nasconde le complessità del sistema di backend. Per risolvere questi problemi, Apigee facilita lo sviluppo e la gestione di API gateway/proxy per i deployment ibridi e multi-cloud.
• Scegli il tipo approccio di rendering per la tua applicazione web frontend in base ai contenuti (statici dinamica), il rendimento dell'ottimizzazione per i motori di ricerca e le aspettative sulle velocità di caricamento delle pagine.
• Quando selezioni un'architettura per le applicazioni web basate su contenuti, sono disponibili varie opzioni, tra cui architetture monolitiche, serverless, basate su eventi e di microservizi. Per selezionare il modello più adatto dell'architettura, valutate attentamente queste opzioni rispetto alla vostra i futuri requisiti dell'applicazione. Per aiutarti a prendere una decisione relativa all'architettura in linea con i tuoi obiettivi commerciali e tecnici, consulta Confronto di diverse architetture per i backend di applicazioni web basati sui contenuti, e Considerazioni principali per i backend web.

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

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

    • Quando utilizzi container e Kubernetes ambienti, hai la flessibilità necessaria per modernizzare i carichi di lavoro per poi eseguire la migrazione a Google Cloud in momenti diversi. Questo è utile quando un carico di lavoro dipende molto da un altro e non può essere sottoposto a migrazione singolarmente oppure per utilizzare la portabilità dei carichi di lavoro ibridi per utilizzare le migliori risorse disponibili in ogni ambiente. In ogni caso, GKE Enterprise può essere una tecnologia di base fondamentale. Per maggiori informazioni, consulta Ambiente ibrido GKE Enterprise.

  • In un ambiente Google Cloud per i container dei componenti dell'applicazione modernizzati.

    • Utilizza questo approccio se hai backend legacy on-premise che non supportano la containerizzazione o richiedono tempo e risorse significativi per essere modernizzati a breve termine.

    Scopri di più sulla progettazione e il refactoring di un'app monolitica un'architettura di microservizi per modernizzare l'architettura delle applicazioni web, vedi Introduzione ai microservizi.

• Puoi combinare le tecnologie di archiviazione dei dati in base alle esigenze delle tue applicazioni web. Usare Cloud SQL per i dati strutturati Cloud Storage per i file multimediali è un approccio comune per soddisfare dati diversificati le esigenze di archiviazione. Detto questo, la scelta dipende in gran parte dal caso d'uso. Per scopri di più sulle opzioni di archiviazione dei dati per l'applicazione basata sui contenuti e le modalità efficaci, Opzioni di archiviazione dei dati per le app web basate sui contenuti. Consulta anche Le opzioni di 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 calcolo 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 partizionato.

Questo modello di architettura può essere creato in due modi diversi. Il primo approccio si basa sul deployment dei componenti dell'applicazione in diversi cloud pubblico ambienti cloud-native. Questo approccio è anche noto come architettura composita ed è lo stesso approccio utilizzato modello di architettura ibrida a più livelli. Tuttavia, anziché utilizzare un ambiente on-premise con un cloud pubblico, utilizza almeno due ambienti cloud. In un elemento composito un'architettura, un singolo carico di lavoro o una singola applicazione utilizza componenti in un solo cloud. Il secondo approccio esegue il deployment di applicazioni diverse in diversi ambienti cloud pubblico. Il seguente elenco non esaustivo descrive alcuni fattori di business per il 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 relative al cloud all'interno della tua organizzazione. Adotta questo approccio per incoraggiare le unità organizzative a scegliere il cloud provider più adatto alle sue esigenze specifiche preferenze.
• Operare in un deployment multiregionale o globale. Se di un'azienda è tenuta ad aderire alle normative sulla residenza dei dati in regioni o paesi, dovrà scegliere tra quelli disponibili dai provider di servizi cloud in quella località se il loro cloud provider principale non una regione cloud.

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

Come detto in precedenza, in alcune situazioni potrebbero verificarsi per motivi aziendali e tecnici per combinare Google Cloud con un altro cloud del cloud privato e di partizionare i carichi di lavoro tra questi ambienti cloud. Soluzioni multi-cloud offrono la flessibilità necessaria per migrare, creare e ottimizzare le applicazioni la portabilità in ambienti multi-cloud, riducendo al minimo i vincoli e aiutando per soddisfare i requisiti normativi. Ad esempio, potresti collegare Google Cloud a Oracle Cloud Infrastructure (OCI) per creare una soluzione multi-cloud che sfrutta le funzionalità di ogni piattaforma utilizzando un Cloud Interconnect privato per combinare i componenti in esecuzione in OCI con le risorse in esecuzione su Google Cloud. Per ulteriori informazioni, vedi 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 altro provider di servizi cloud supportati, che ti consente di progettare e creare soluzioni multi-cloud per gestire volume di traffico tra cloud.

Vantaggi

Sebbene l'utilizzo di un'architettura multi-cloud offra diversi vantaggi tecnici e aziendali, come discusso in Fattori, considerazioni, strategia e approcci, è essenziale eseguire una valutazione dettagliata della fattibilità di ogni potenziale vantaggio. La valutazione deve considerare attentamente tutti i fattori diretti o indiretto sfide o potenziali ostacoli e la tua capacità di gestirli 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 dell'architettura multi-cloud partizionata motivo:

• In scenari in cui potrebbe essere necessario ridurre al minimo l'impegno puoi distribuire le applicazioni su più cloud di Google Cloud. Di conseguenza, potresti ridurre relativamente i vincoli al fornitore la possibilità di cambiare piano (in una certa misura) tra i vari cloud provider. Il cloud aperto aiuta a portare le funzionalità di Google Cloud, come GKE Enterprise, in località fisiche diverse. Con l'estensione delle funzionalità di Google Cloud on-premise, in più cloud pubblici e a livello perimetrale, offre flessibilità, agilità e favorisce la trasformazione.

• Per motivi normativi, puoi pubblicare annunci per un determinato segmento di utenti e i dati di un paese in cui Google Cloud non ha regione cloud.

• Il modello di architettura multi-cloud partizionata può aiutare a ridurre latenza e migliorare la qualità complessiva dell'esperienza utente nelle località in cui il cloud provider principale non abbia una regione cloud o punto di presenza. Questo pattern è particolarmente utile quando si utilizzano alta capacità e bassa latenza la connettività multi-cloud, come Cross-Cloud Interconnect e Interconnessione CDN con una rete CDN distribuita.

• Puoi eseguire il deployment delle applicazioni su più cloud provider in modo che ti permette di scegliere tra i migliori servizi che gli altri cloud provider offerta.

• Il pattern di architettura multicloud partizionato può contribuire a semplificare e accelerare 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

• Per iniziare, esegui il deployment di un carico di lavoro non mission critical. Questo deployment iniziale nel cloud secondario può quindi fungere da modello per futuri deployment o migrazioni. Tuttavia, questo approccio probabilmente non è applicabile in situazioni in cui il carico di lavoro specifico è legalmente o obbligatoriamente richiesto in una regione cloud specifica e il fornitore cloud principale non ha una regione nel territorio richiesto.
• Riduci al minimo le dipendenze tra i sistemi in esecuzione in diversi ambienti cloud pubblico, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni e diminuire in generale e potrebbero incorrere in costi aggiuntivi per il trasferimento di dati in uscita.
• Per eliminare le differenze tra gli ambienti, valuta la possibilità di utilizzare i 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 negli ambienti cloud.
• Seleziona il pattern di architettura di rete ottimale che fornisca soluzione di comunicazione efficiente ed efficace per le applicazioni che utilizzano.
  • La comunicazione deve essere capillare e controllata. Utilizza la sicurezza API per esporre i componenti dell'applicazione.
  • Valuta la possibilità di utilizzare il pattern di architettura mesh o uno dei pattern di reti con accesso controllato, in base ai tuoi requisiti tecnici e aziendali specifici.
• Per soddisfare le aspettative di disponibilità e prestazioni, progetta la tua soluzione in modo da garantire un'alta disponibilità (HA) end-to-end, una 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à, in base alla connettività ibrida selezionata soluzione. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect MACsec per Cross-Cloud Interconnect.

• Se utilizzi più CDN come parte il tuo modello di architettura partizionata multi-cloud e stai compilando l'altra CDN con file di dati di grandi dimensioni di Google Cloud, utilizzando Interconnessione CDN i collegamenti tra Google Cloud e fornitori supportati per ottimizzare questo traffico e, potenzialmente, le sue 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 degli ambienti.

• Per bilanciare efficacemente le richieste tra Google Cloud e un altro Google Cloud, puoi usare Cloud Load Balancing. Per ulteriori informazioni, consulta Indirizzare il traffico a una località 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à Cross-Cloud Interconnect.

• Per superare incoerenze nei protocolli, nelle API e nell'autenticazione in backend diversi, consigliamo, ove applicabile, eseguire il deployment di un gateway API o di un proxy come facade (facade). Questo gateway o proxy funge da punto di controllo centralizzato ed esegue le seguenti misure:

  • Implementa misure di sicurezza aggiuntive.
  • Protegge le app client e altri servizi dalle modifiche al codice del backend.
  • Facilita le procedure di controllo per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
  • Agisce come livello di comunicazione intermedio tra i servizi legacy e modernizzati.
    • Apigee e Apigee ibrido consente di ospitare e gestire gateway di livello enterprise e ibridi in ambienti on-premise, perimetrali, in altri cloud ambienti Google Cloud.

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

  • Esegui il deployment del failover multiregione per gli ambienti di runtime delle API Apigee in regioni diverse.

  • Aumento del rendimento con Cloud CDN.

  • Fornisce protezione WAF e DDoS tramite Google Cloud Armor.

• Utilizza strumenti coerenti per il logging e il monitoraggio nel cloud ove possibile. Potresti valutare la possibilità di utilizzare sistemi di monitoraggio open source. Per ulteriori informazioni, consulta Pattern di logging e monitoraggio per cloud ibrido e multi-cloud.

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

Modello di analisi ibrida e multi-cloud

Questo documento illustra che l'obiettivo del modello di analisi ibrido e multi-cloud è sfruttare al meglio la suddivisione tra carichi di lavoro transazionali e di analisi.

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

• I carichi di lavoro 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 perfezionare o visualizzare i dati per facilitare i processi decisionali.

I sistemi di analisi ottengono i dati dai sistemi transazionali tramite query sulle API o accedendo ai database. Nella maggior parte delle aziende, i sistemi di analisi e i sistemi transazionali tendono a essere separati e a basso accoppiamento. L'obiettivo il modello ibrido e multi-cloud dell'analisi dei dati deve trarre il massimo profitto da questo una suddivisione preesistente mediante l'esecuzione di carichi di lavoro transazionali e di analisi in due diversi ambienti di elaborazione. I dati non elaborati vengono prima estratti dai carichi di lavoro in esecuzione nell'ambiente di calcolo privato e poi caricati in Google Cloud, dove vengono utilizzati per l'elaborazione analitica. Alcuni dei risultati potrebbero poi essere inviati 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 spostamento e trasformazione dei dati che può essere basata su ETL o ELT, a seconda della qualità dei dati disponibile e del caso d'uso target.

Per spostare i dati in Google Cloud e generare valore da questi ultimi, utilizza spostamento dei dati servizi, una suite completa di servizi di importazione, integrazione e replica dei dati i servizi di machine learning.

Come mostrato nel diagramma precedente, il collegamento di Google Cloud ambienti on-premise e altri ambienti cloud possono abilitare vari di analisi dei dati, come flussi di dati e backup dei database. Per alimentare il trasporto di base di un modello di analisi ibrido e multi-cloud che richiede un volume elevato di trasferimenti di dati, Cloud Interconnect Cross-Cloud Interconnect fornire connettività dedicata a on-premise e ad altri cloud provider.

Vantaggi

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

• Il traffico in entrata, ovvero lo spostamento dei dati dal tuo ambiente di calcolo privato o da altri cloud a Google Cloud, potrebbe essere senza costi.
• I carichi di lavoro di analisi devono spesso elaborare quantità considerevoli di dati e possono essere intermittenti, pertanto sono particolarmente adatti per essere implementati in un ambiente cloud pubblico. La scalabilità dinamica delle risorse di calcolo consente di elaborare rapidamente set di dati di grandi dimensioni, evitando investimenti iniziali o all'overprovisioning delle apparecchiature di calcolo.
• Google Cloud offre una vasta gamma di servizi per gestire i dati durante tutto il loro ciclo di vita, dall'acquisizione iniziale all'elaborazione e all'analisi fino alla visualizzazione finale.
  • I servizi di spostamento dei dati su Google Cloud forniscono 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. Inoltre, può fornire la flessibilità, la scalabilità e l'agilità necessarie per garantire che i dati generino valore per la tua azienda, anziché inefficienze. Per ulteriori informazioni, consulta BigLake.

• BigQuery Omni fornisce potenza di calcolo che viene eseguita localmente nello spazio di archiviazione su AWS o Azure. Ti aiuta inoltre 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 dedicati ai dati di abbattere i silos di dati. Per ulteriori informazioni sull'esecuzione di query sui dati archiviati al di fuori di BigQuery, consulta Introduzione alle origini dati esterne.

Best practice

Per implementare il modello di architettura ibrida e multicloud per l'analisi, considera le seguenti best practice generali:

• Utilizza il pattern di rete di trasferimento per attivare l'importazione dei dati. Se i risultati delle analisi devono essere restituiti ai sistemi transazionali, puoi combinare passaggio di consegne e il in uscita riservato pattern.
• Utilizza le code Pub/Sub o i bucket Cloud Storage per trasferire i dati a Google Cloud da sistemi transazionali in esecuzione nel tuo ambiente di calcolo privato. Queste code o i bucket possono fungere da origini per le pipeline e i carichi di lavoro di elaborazione dati.
• Per eseguire il deployment di pipeline di dati ETL ed ELT, ti consigliamo di utilizzare Cloud Data Fusion o Dataflow a seconda dei requisiti specifici del tuo caso d'uso. Entrambi sono servizi di elaborazione dei dati cloud-first completamente gestiti per la creazione e la gestione di pipeline di dati.
• Per scoprire, classificare e proteggere i tuoi asset di dati importanti, utilizzando Google Cloud Protezione dei dati sensibili funzionalità come tecniche di anonimizzazione. Queste tecniche ti consentono di mascherare, criptare e sostituire i dati sensibili, come le informazioni che consentono l'identificazione personale (PII), utilizzando una chiave predeterminata o generata in modo casuale, ove applicabile e conforme.
• Se hai già carichi di lavoro Hadoop o Spark, ti consigliamo di eseguire la migrazione dei job in Dataproc e di eseguire la migrazione dei dati HDFS esistenti in Cloud Storage.

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

• Se il trasferimento o lo scambio di dati tra Google Cloud e altri cloud per un volume di traffico elevato a lungo termine, occorre valutare utilizzando Google Cloud Cross-Cloud Interconnect per stabilire una connettività dedicata a elevata larghezza di banda Google Cloud e altri provider di servizi cloud (disponibili in alcuni località).

• Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni disponibili 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 procedure 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 a livello di bordo

L'esecuzione di carichi di lavoro nel cloud richiede che i client in alcuni scenari dispongano di una connettività a internet rapida e affidabile. Date le reti di oggi, questo requisito raramente rappresenta un problema per l'adozione del cloud. Ci sono, tuttavia, in cui non è possibile fare affidamento sulla connettività continua, come ad esempio:

• Le navi marittime e altri veicoli possono essere collegati solo a intermittenza o avere accesso solo a collegamenti satellitari ad alta latenza.
• Le fabbriche o le centrali elettriche potrebbero essere connesse a internet. Questi potrebbero avere requisiti di affidabilità superiori alla disponibilità dichiarazioni del proprio provider internet.
• I negozi di vendita al dettaglio e i supermercati potrebbero essere collegati solo occasionalmente o utilizzare link che non forniscono l'affidabilità o il throughput necessari per gestire le transazioni fondamentali per l'attività.

Il pattern di architettura ibrida edge risolve questi problemi eseguendo i carichi di lavoro critici per il tempo e per l'attività localmente, all'edge della rete, e utilizzando il cloud per tutti gli altri tipi di carichi di lavoro. In un ibrido perimetrale , il link Internet è un componente non critico che viene utilizzato nonché di sincronizzare o caricare i dati, spesso in modo asincrono, non è coinvolta in tempi o transazioni importanti per l'attività.

Vantaggi

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

• Il traffico in entrata, ovvero il trasferimento dei dati dall'edge a Google Cloud, potrebbe essere gratuito.
• L'esecuzione di carichi di lavoro critici per l'attività e il tempo a livello perimetrale aiuta garantire bassa latenza e autosufficienza. Se la connessione a internet non funziona o non è al momento disponibile, puoi comunque eseguire tutte le transazioni importanti. Allo stesso tempo, puoi trarre vantaggio dall'utilizzo del cloud per del carico di lavoro complessivo.
• Puoi riutilizzare gli investimenti esistenti in apparecchiature di elaborazione e archiviazione.
• Nel tempo, puoi ridurre in modo incrementale la frazione dei carichi di lavoro che vengono eseguite a livello perimetrale e li spostiamo nel cloud, rielaborando o dotando alcune località perimetrali di link internet sono più affidabili.
• I progetti relativi all'Internet of Things (IoT) possono diventare più convenienti eseguendo i calcoli dei dati localmente. Ciò consente alle aziende di eseguire alcuni servizi vengono elaborati localmente a livello perimetrale, più vicini alle origini dati. Consente inoltre alle aziende di inviare i dati in modo selettivo 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. Questo consente alle applicazioni e ai sistemi legacy di integrarsi come le soluzioni IoT.

Best practice

Prendi in considerazione i seguenti consigli quando implementi il pattern di architettura ibrida di confine:

• Se la comunicazione è unidirezionale, utilizza il pattern di ingresso con limitazioni.
• Se la comunicazione è bidirezionale, valuta la possibilità di utilizzare il pattern di traffico in entrata e in uscita con limiti.
• Se la soluzione consiste in molti siti perimetrali remoti che si connettono a a Google Cloud sulla rete internet pubblica, puoi utilizzare soluzione WAN (SD-WAN). Puoi anche utilizzare Centro connettività di rete con un router SD-WAN di terze parti supportato da un Partner Google Cloud per semplificare il provisioning e la gestione di una connettività sicura su larga scala.
• Riduci al minimo le dipendenze tra i sistemi in esecuzione sull'edge e quelli in esecuzione nell'ambiente cloud. Ogni dipendenza può compromettere i vantaggi di affidabilità e latenza di una configurazione ibrida perimetrale.
• Per gestire e utilizzare in modo efficiente più località edge, devi avere un piano di gestione e una soluzione di monitoraggio centralizzati nel cloud.
• Garantisci che le pipeline CI/CD e gli strumenti per il deployment il monitoraggio è coerente in ambienti cloud e perimetrali.
• Valuta la possibilità di utilizzare container e Kubernetes, ove applicabile e fattibile, per astrarre le differenze tra le varie località sul perimetro e anche tra perimetrali e nel cloud. Poiché Kubernetes offre un runtime comune puoi sviluppare, eseguire e gestire i carichi di lavoro in modo coerente ambienti di computing. Puoi anche spostare i carichi di lavoro tra l'edge e il cloud.
  • Per semplificare la configurazione e il funzionamento dell'ibrido, puoi utilizzare GKE Enterprise per questa architettura (se i container vengono utilizzati in tutti gli ambienti). Valuta le possibili opzioni di connettività a tua disposizione per collegare un cluster GKE Enterprise in esecuzione nel tuo ambiente on-premise o edge a Google Cloud.
• Nell'ambito di questo pattern, anche se alcuni potrebbero sussistere durante un'interruzione temporanea della connettività Google Cloud, non usare GKE Enterprises quando disconnessa da Google Cloud come modalità di lavoro nominale. Per ulteriori informazioni, consulta Impatto della disconnessione temporanea da Google Cloud.
• Per superare incoerenze nei protocolli, nelle API e nell'autenticazione in diversi servizi di backend e perimetrali, consigliamo, dove applicabile, per eseguire il deployment di un gateway API o di un proxy come facade (facade). Questo gateway o proxy funge da punto di controllo centralizzato ed esegue le seguenti misure:
  • Implementa misure di sicurezza aggiuntive.
  • Protegge le app client e altri servizi dalle modifiche al codice del backend.
  • Facilita le procedure di controllo per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
  • Agisce come livello di comunicazione intermedio tra servizi legacy e modernizzati.
    • Apigee e Apigee Hybrid ti consentono di ospitare e gestire gateway ibridi e di livello enterprise in ambienti on-premise, edge, altri cloud e Google Cloud.
• Stabilisci un'identità comune tra gli ambienti in modo che i sistemi possano eseguire l'autenticazione sicura confini ambientali.
• Poiché i dati scambiati tra gli ambienti potrebbero essere sensibili, assicurati che tutte le comunicazioni siano criptate in transito utilizzando i tunnel VPN, TLS o entrambi.

Pattern ibrido dell'ambiente

Con il pattern di architettura ibrida dell'ambiente, mantieni la produzione di un carico di lavoro nel data center esistente. Quindi utilizzi il pubblico cloud per i tuoi ambienti di sviluppo e test o altri ambienti. Questo pattern si basa sul deployment ridondante delle stesse applicazioni in diversi ambienti di elaborazione. L'obiettivo del deployment è contribuire ad aumentare capacità, agilità e resilienza.

Durante la valutazione dei carichi di lavoro di cui eseguire la migrazione, potresti notare alcuni casi durante l'esecuzione a un'applicazione specifica nel cloud pubblico presenta alcune sfide:

• Limitazioni di giurisdizione o normative 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 anche gli ambienti coinvolti nel ciclo di vita di un'applicazione, di sviluppo, test e gestione temporanea. Queste restrizioni spesso si applicano dell'ambiente di produzione e dei suoi dati. Potrebbero non essere applicabili ad altri ambienti che non utilizzano i dati effettivi. Verifica la conformità reparto della tua organizzazione o dal team equivalente.

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

Esecuzione di sistemi di sviluppo e test in ambienti diversi da quelli del tuo che potrebbero sembrare rischiosi e potrebbero discostarsi dalle best practice esistenti per ridurre al minimo le differenze ambienti cloud-native. Se da un lato questi dubbi sono giustificati, non si applicano se distinguere tra le fasi del processo di sviluppo e di test:

Sebbene i processi di sviluppo, test e deployment siano diversi applicazione, di solito prevedono variazioni delle seguenti fasi:

• Sviluppo: creazione di una release candidata alla release.
• Test funzionali o test di accettazione dell'utente: verifica che l'elemento il candidato di release soddisfa i requisiti funzionali.
• Test di prestazioni e affidabilità. Verificare che la release del candidato soddisfa i requisiti non funzionali. È anche noto come test di carico.
• Test di gestione temporanea o deployment: verifica della procedura di deployment funziona.
• Produzione: rilascio di applicazioni nuove o aggiornate.

L'esecuzione di più di una di queste fasi in un singolo ambiente raramente quindi ogni fase richiede di solito uno o più ambienti dedicati.

Nota: il termine ambiente di gestione temporanea viene spesso confuso con ambiente di test dell'ambiente di rete.

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 una fase temporanea dell'ambiente di lavoro, i test funzionali dovrebbero essere completi. L'implementazione è 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 alla produzione il deployment, l'insieme di ambienti che usi durante del ciclo di vita deve soddisfare, per quanto possibile, le seguenti regole:

• Tutti gli ambienti sono equivalenti dal punto di vista funzionale. Vale a dire che architettura, API e versioni di sistemi operativi e librerie sono equivalenti e i sistemi si comportano allo stesso modo in tutti gli ambienti. Questo l'equivalenza evita situazioni in cui le applicazioni funzionano in un ambiente ma non in un'altra o dove i difetti non sono riproducibili.
• Ambienti utilizzati per i test delle prestazioni e dell'affidabilità staging e produzione sono non funzionalmente equivalente. ovvero le prestazioni, la scalabilità, la configurazione e il modo gestiti e gestiti, sono uguali o differiscono solo in modo insignificante. In caso contrario, i test del rendimento e della gestione temporanea diventano privi di significato.

In generale, va bene se gli ambienti utilizzati per lo sviluppo funzionali differiscono in modo non funzionale dagli altri ambienti.

Come illustrato nel seguente diagramma, gli ambienti di test e sviluppo vengono creati su Google Cloud. Un database gestito, come Cloud SQL, può essere utilizzata come opzione per lo sviluppo e i test in Google Cloud. Sviluppo e i test possono utilizzare lo stesso motore del database e la stessa versione dell'ambiente di produzione, una versione equivalente dal punto di vista funzionale o una nuova versione nell'ambiente di produzione dopo la fase di test. Tuttavia, poiché l'infrastruttura sottostante dei due ambienti non sono identiche, ai test di carico delle prestazioni non è valido.

I seguenti scenari possono adattarsi 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 Google Kubernetes Engine (GKE) Enterprise può essere una tecnologia chiave abilitante per questo l'importanza di un approccio umile.
  • Garantire la portabilità dei carichi di lavoro e scorporare le differenze tra gli ambienti di calcolo. Con un mesh di servizi Zero Trust, puoi controllare e mantenere la separazione delle comunicazioni 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 di produzione, di staging e di prestazioni (test di carico) e di affidabilità nell'ambiente di calcolo privato, garantendo l'equivalenza funzionale e non funzionale.

Considerazioni sul design

• Esigenze aziendali: ogni strategia di deployment e rilascio per le applicazioni ha i suoi vantaggi e svantaggi. Per garantire che l'approccio scelto è in linea con i tuoi requisiti specifici, le tue selezioni su una valutazione approfondita delle esigenze e dei vincoli aziendali.
• Differenze di ambiente: nell'ambito di questo pattern, l'obiettivo principale dell'utilizzo di questo ambiente cloud è lo sviluppo e i test. Il finale è ospitare l'applicazione testata in ambienti on-premise privati (produzione). Per evitare di sviluppare e testare una funzionalità che potrebbero funzionare come previsto nell'ambiente cloud e non ambiente di produzione (on-premise), il team tecnico deve conoscere comprendere le architetture e le capacità di entrambi gli ambienti. Sono incluse 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 alla tua azienda sviluppare nel cloud e quali dati può utilizzare per i test, utilizza una procedura di approvazione e governance. Questa procedura può anche aiutare la tua azienda a garantire che non utilizza funzionalità cloud nelle fasi di sviluppo e test esistenti nel tuo ambiente di produzione on-premise.
• Criteri di successo: devono essere presenti criteri di successo dei test chiari, predefiniti e misurabili in linea con gli standard di controllo qualità del software per la tua organizzazione. Applica questi standard a qualsiasi applicazione che sviluppi e test.
• Redundanza: anche se gli ambienti di sviluppo e test potrebbero non richiedere un'affidabilità pari a quella dell'ambiente di produzione, hanno comunque bisogno di funzionalità ridondanti e della possibilità di testare diversi scenari di errore. I requisiti relativi agli scenari di errore potrebbero portare il design a includere la ridondanza nell'ambiente di sviluppo e test.

Vantaggi

L'esecuzione di carichi di lavoro di sviluppo e test funzionali nel cloud pubblico offre 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 inoltre i seguenti vantaggi:
  • Puoi ridurre i costi arrestando le istanze di macchine virtuali (VM) quando non sono attive o eseguendo il provisioning degli ambienti solo su richiesta.
  • Per velocizzare lo sviluppo e i test, inizia ambienti temporanei per ogni richiesta di pull. In questo modo si riducono anche le spese generali di manutenzione e le incoerenze nell'ambiente di compilazione.
• L'esecuzione di questi ambienti nel cloud pubblico aiuta a creare familiarità e la fiducia nel cloud e nei relativi strumenti, il che può aiutare 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 più ambienti.

Best practice

Per implementare correttamente il pattern di architettura ibrida, tieni in considerazione i seguenti consigli:

• Definisci i requisiti di comunicazione dell'applicazione, incluso il design ottimale della rete e della sicurezza. Quindi, utilizza il pattern di rete speculare per aiutarti a progettare l'architettura di rete in modo da impedire le comunicazioni dirette tra sistemi di ambienti diversi. Se la comunicazione è necessaria tra gli ambienti, deve avvenire in un ambiente controllato in modo adeguato.

• La strategia di test e deployment dell'applicazione che scegli deve essere in linea con gli scopi e i requisiti della tua attività. Ciò potrebbe comportare le modifiche senza tempi di inattività o l'implementazione graduale di funzionalità un ambiente o un gruppo di utenti specifico prima di un rilascio più ampio.

• Per rendere i carichi di lavoro portabili e per astrarre le differenze tra gli ambienti, puoi utilizzare i container con Kubernetes. Per maggiori informazioni le informazioni, vedi Architettura di riferimento dell'ambiente ibrido di GKE Enterprise.

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

• Assicurati che le pipeline CI/CD siano coerenti tra il computing ambienti e che lo stesso esatto insieme di file binari, pacchetti viene eseguito il deployment dei container 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 diversi ambienti. Per ulteriori informazioni, vedi Soluzioni DevOps su Google Cloud.

• Per aiutarti con il rilascio continuo di soluzioni sicure e affidabili incorporano la sicurezza come parte integrante di DevOps (DevSecOps). Per ulteriori informazioni, consulta Pubblica e metti al sicuro 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 ulteriori informazioni, vedi Pattern di logging e monitoraggio ibridi e multi-cloud

• Se team diversi gestiscono carichi di lavoro di test e produzione, utilizzando strumenti potrebbero essere accettabili. Tuttavia, l'utilizzo degli stessi strumenti con autorizzazioni di visualizzazione diverse può aiutarti a ridurre lo sforzo e la complessità dell'addestramento.

• Quando scegli i servizi di database, archiviazione e messaggistica per un funzionamento i test, utilizza prodotti che hanno un equivalente gestito su Google Cloud. L'utilizzo di servizi gestiti consente di ridurre l'impegno amministrativo necessario per mantenere gli ambienti di sviluppo e test.

• Per proteggere le informazioni sensibili, ti consigliamo di crittografare tutti le comunicazioni in transito. Se è richiesta la crittografia a livello di connettività sono disponibili varie opzioni basate sul modello di connettività standard. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

La tabella seguente mostra i prodotti Google Cloud compatibili con i prodotti OSS più comuni.

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

Modelli di business continuity ibridi e multi-cloud

Il motivo principale per cui è importante prendere in considerazione la continuità aziendale 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. Di di replicare sistemi e dati su più regioni geografiche ed evitare i single point of failure, è possibile ridurre al minimo i rischi di una calamità naturale che influisce sull'infrastruttura locale. Altri scenari di errore includono un grave guasto del sistema, un attacco di cybersicurezza 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à del tempo di attività, sicurezza ed esperienza utente. Per ulteriori informazioni su come progettare e gestire servizi affidabili su Google Cloud, consulta il pilastro dell'affidabilità del Framework dell'architettura di Google Cloud e i componenti di base dell'affidabilità in Google Cloud.

Questo pattern di architettura si basa su un deployment ridondante delle applicazioni su più ambienti di calcolo. In questo pattern, esegui il deployment delle stesse applicazioni in più ambienti di calcolo allo scopo 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 che ha interrotto le attività.

Ripristino RE emergenza è considerata un sottoinsieme della business continuity, concentrandosi esplicitamente sui assicurando che i sistemi IT a supporto di funzioni aziendali critiche operativo il prima possibile dopo un'interruzione. In generale, le strategie di RE e piani spesso aiutano a formare una strategia di continuità aziendale più ampia. Dal punto di vista della tecnologia, 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 indicazioni sull'utilizzo di Google Cloud per il ripristino di emergenza, consulta la Guida alla pianificazione del ripristino di emergenza.

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

La decisione di selezionare Strategia RE o dovrebbe essere determinato da un'analisi dell'impatto aziendale. Ad esempio, le perdite finanziarie derivanti anche da pochi minuti di tempo di riposo per un'organizzazione di servizi finanziari potrebbero superare di gran lunga il costo di implementazione di un sistema di RP. Tuttavia, le attività di altri settori potrebbero subire ore di inattività senza effetti significativi sull'attività.

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

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

Una variante meno comune (e raramente richiesta) di questo pattern è il pattern multicloud per la continuità aziendale. In questo modello, l'ambiente di produzione utilizza un fornitore cloud e l'ambiente di ripristino dei dati dopo un disastro un altro fornitore cloud. Se esegui il deployment di copie dei carichi di lavoro su più cloud provider, potresti aumentare la disponibilità oltre a quanto offre un deployment multi-regione.

Valutazione di un RE su più cloud rispetto all’utilizzo di un solo provider cloud regioni diverse richiede un'analisi approfondita di varie considerazioni, tra cui:

• Gestibilità
• Sicurezza
• La fattibilità complessiva.
• Costo
  • I potenziali costi di trasferimento dei dati in uscita da più di un fornitore cloud potrebbero essere elevati con la comunicazione inter-cloud continua.
  • Quando si esegue la replica dei database, può verificarsi un volume elevato di traffico.
  • TCO e costo di gestione dell'infrastruttura di rete inter-cloud.

Nota: per ulteriori informazioni su come Cross-Cloud Interconnect potrebbe aiutarti a ridurre il TCO e la complessità, consulta Annuncio di Cross-Cloud Interconnect: connettività senza interruzioni a tutti i tuoi cloud.

Se i tuoi dati devono rimanere nel tuo paese per soddisfare i requisiti normativi, utilizzare un secondo cloud provider presente nel vostro paese, come RE, può essere . L'uso di un secondo cloud provider presuppone l'assenza di un'opzione usa 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 in-region.

Note sul layout

• Aspettativa RE: l'RPO e l'RTO target che l'azienda vuole raggiungere dovrebbe guidare l'architettura di RE e costruire la pianificazione.
• Architettura della soluzione: con questo pattern, devi replicare le funzioni e le capacità esistenti dell'ambiente on-premise per soddisfare le tue aspettative di RE. È quindi necessario valutare la fattibilità possibilità di rehosting, refactoring o riprogettazione delle applicazioni Offrire le stesse (o più ottimizzate) funzioni e prestazioni nel cloud completamente gestito di Google Cloud.
• Progettazione e creazione: la creazione di una landing zone è quasi sempre un prerequisito per il deployment dei carichi di lavoro aziendali in un ambiente cloud. Per maggiori informazioni, consulta Design delle zone di destinazione in Google Cloud.

• Chiamata RE: è importante che la progettazione e il processo di RE rispondi alle seguenti domande:

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

  Convalida le risposte a queste domande tramite test.

• Test: testa e valuta attentamente il failover al DR. Assicurati che sia in linea con le tue aspettative di RPO e RTO. In questo modo, avrai più fiducia nell'eseguire il ripristino dei dati quando necessario. Ogni volta che viene apportata una nuova modifica o un nuovo aggiornamento al processo o alla soluzione tecnologica, esegui nuovamente i test.

• Competenze di gruppo: uno o più team tecnici devono avere le competenze e Competenza per la creazione, il funzionamento e la risoluzione dei 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à aziendale offre diversi vantaggi:

• Poiché Google Cloud offre molte regioni in tutto il mondo tra cui scegliere, puoi utilizzarlo per eseguire il backup o la replica dei dati su un altro sito all'interno dello stesso continente. Puoi anche eseguire il backup di replicare i dati in un sito in un altro continente.
• Google Cloud offre la possibilità di archiviare i dati in Cloud Storage in un due o più regioni di sincronizzare la directory di una VM con un bucket. I dati vengono archiviati in modo ridondante in almeno due regioni geografiche separate. I dati archiviati in bucket a due e più regioni vengono replicati in più regioni usando la replica predefinita.
  • I bucket a doppia regione forniscono ridondanza geografica per supportare la continuità aziendale e i piani di RE. Inoltre, per eseguire la replica più velocemente, con un RPO più basso, gli oggetti archiviati in regioni con due o più regioni possono facoltativamente utilizzare la replica turbo in queste regioni.
  • Analogamente, 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 piano di RE:
  • Le istanze VM arrestate comportano solo costi di archiviazione e sono molto più economico rispetto all'esecuzione di istanze VM. Ciò significa che puoi ridurre al minimo il costo di manutenzione dei sistemi cold standby.
  • Il modello di pagamento per utilizzo di Google Cloud ti consente di pagare solo per la capacità di archiviazione e di calcolo effettivamente utilizzata.
  • Le funzionalità di elasticità, come la scalabilità automatica, ti consentono di eseguire lo scale up o lo scale down dell'ambiente di DR in base alle esigenze.

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

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

Per velocizzare e automatizzare il provisioning dell'infrastruttura, valuta la possibilità e la gestione dell'Infrastructure as Code. Puoi utilizzare Cloud Build, uno strumento di integrazione continua, per applicare automaticamente i manifest Terraform del tuo ambiente. Per saperne di più, consulta Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps.

Best practice

Quando utilizzi il pattern di continuità aziendale, tieni in considerazione le seguenti best practice:

• Crea un piano di ripristino di emergenza che documenti l'infrastruttura insieme alle procedure di failover e di recupero.
• Prendi in considerazione le seguenti azioni in base all'analisi dell'impatto sulla tua attività e i target RPO e RTO richiesti 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, tiepido o caldo).
  • Definisci i servizi e i prodotti che puoi utilizzare come componenti di base per il tuo piano di RE.
  • Delinea gli scenari di DR applicabili per le tue applicazioni e per i tuoi dati nell'ambito della strategia di DR selezionata.
• Valuta l'uso della classe modello passo quando esegui solo il backup dei dati. In caso contrario, il pattern a maglia 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 sdoppiato. Se replichi i dati in modo bidirezionale ambienti, potresti dover esposto al problema dello "split-cervello". Il problema di split-brain si verifica quando due ambienti che replicano i dati in modo bidirezionale perdono la comunicazione tra loro. Questa suddivisione può causare la conclusione da parte dei sistemi in entrambi gli ambienti che l'altro ambiente non è disponibile e che hanno accesso esclusivo ai dati. Questo può portare a modifiche dei dati in conflitto. Esistono due modi comuni per evitare il problema di split-brain:

  • Utilizza un terzo ambiente di calcolo. Questo ambiente consente ai sistemi verificare il quorum prima di modificare i dati.

  • Consenti la riconciliazione delle modifiche ai dati in conflitto dopo la connettività viene ripristinato.

    Con i database SQL, puoi evitare il problema dello "split-brain" rendendo l'istanza principale originale inaccessibile prima dell'avvio dei client utilizzando la nuova istanza principale. Per ulteriori informazioni, vedi Ripristino di emergenza del database Cloud SQL.

• Assicurati che i sistemi CI/CD e i repository di artefatti non diventino un il single point of failure. Quando un ambiente non è disponibile, devi essere ancora in grado di eseguire il deployment di nuove release o applicare modifiche alla configurazione.

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

• Integra il deployment dei sistemi di riserva nella tua pipeline CI/CD. Questa integrazione contribuisce a garantire che le versioni e le configurazioni delle applicazioni siano coerenti in tutti gli ambienti.

• Assicurati che le modifiche al DNS vengano propagate rapidamente configurando il DNS con un numero ragionevolmente breve valore della durata per consentirti di reindirizzare gli utenti ai sistemi in standby in caso di emergenza.

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

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

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

  • Semplificare il deployment o la migrazione di applicazioni ibride hanno dipendenze in ambienti cloud e on-premise configurazione DNS multi-provider.

    Google Cloud offre una soluzione open source basata su octoDNS per aiutarti a configurare e gestire un ambiente con più fornitori DNS. Per ulteriori informazioni, vedi DNS pubblico multifornitore tramite Cloud DNS.

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

• Utilizza le funzionalità di Cloud Load Balancing anziché i bilanciatori del carico hardware per supportare alcuni scenari quando si utilizza questo pattern di architettura. Richieste interne dei clienti o richieste di client esterne può essere reindirizzato all'ambiente principale o all'ambiente di RE in base a diverse metriche, suddivisione del traffico basata sulle ponderazioni. Per ulteriori informazioni, consulta la Panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.

• Valuta la possibilità di utilizzare 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ò aiutare a ottimizzare le prestazioni di connettività e ridurre i costi per il trasferimento di dati in uscita per il traffico che soddisfa determinati le condizioni di traffico. Per maggiori informazioni, consulta i prezzi di Cloud Interconnect.

• Valuta la possibilità di utilizzare la soluzione del partner che preferisci su Google Cloud Marketplace per semplificare i backup, le repliche e altre attività dei dati che soddisfano i tuoi requisiti, inclusi i target RPO e RTO.

• Testa e valuta gli scenari di chiamata RE per capire con quanta facilità l'applicazione può eseguire il ripristino da un evento di emergenza rispetto alla Valore RTO.

• Crittografare le comunicazioni in transito. Per proteggere le informazioni sensibili, consigliamo di criptare tutte le comunicazioni in transito. Se è richiesta la crittografia a livello di connettività, sono disponibili varie opzioni in base la 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 riscontrare estreme fluttuazioni nell'utilizzo. Sebbene la maggior parte le applicazioni aziendali non affrontano questa sfida, molte aziende devono con un diverso tipo di carico di lavoro bursty: job batch o CI/CD.

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

Sebbene tu possa gestire carichi di lavoro intermittenti in un ambiente di calcolo basato su data center tramite il provisioning eccessivo delle risorse, questo approccio potrebbe non essere economicamente conveniente. Con i job batch, puoi ottimizzare l'utilizzo allungando 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 di cloud bursting è quella di utilizzare un servizio di computing privato dell'ambiente per il carico di base ed eseguire temporaneamente il burst nel cloud quando richiedono capacità extra.

Nel diagramma precedente, quando la capacità dei dati è al limite in un ambiente on-premise in un ambiente privato, il sistema può acquisire capacità aggiuntiva dell'ambiente Google Cloud quando necessario.

I fattori chiave di questo modello sono il risparmio e la riduzione del tempo e dell'impegno necessari per rispondere alle variazioni dei requisiti di scalabilità. Con questo approccio, paghi solo le risorse utilizzate per gestire i carichi aggiuntivi. Ciò significa che l'overprovisioning della tua infrastruttura. In alternativa, puoi sfruttare le risorse cloud on demand e scalarle in base alla domanda e a eventuali metriche predefinite. 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 eliminare le differenze tra gli ambienti. Ad esempio, Kubernetes consente di ottenere coerenza a livello di carico di lavoro ambienti diversi che usano infrastrutture diverse. Per maggiori informazioni le informazioni, vedi Architettura di riferimento dell'ambiente ibrido di GKE Enterprise.

Note sul layout

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

• Puoi instradare le richieste utente in entrata a un bilanciatore del carico in esecuzione nel data center esistente e poi fare in modo che il bilanciatore del carico distribuisca delle richieste alle risorse locali e cloud.

  Questo approccio richiede che il bilanciatore del carico o un altro sistema in esecuzione nel data center esistente monitori anche le risorse allocate nel cloud. Anche il bilanciatore del carico o un altro sistema deve avviano automaticamente l'upscaling o il downscaling delle risorse. Utilizzo di questo è possibile ritirare tutte le risorse cloud nei periodi di attività. Tuttavia, l'implementazione di meccanismi per monitorare le risorse potrebbe superare le capacità delle soluzioni dei bilanciatori del carico e, di conseguenza, aumentano e la complessità generale.

• Invece di implementare meccanismi per monitorare le risorse, puoi utilizzare il bilanciamento del carico Cloud con un backend gruppo di endpoint di rete (NEG) con connettività ibrida. Puoi utilizzare questo bilanciatore del carico per il routing richieste del client interne o richieste di client esterne ai backend situati sia on-premise che in Google Cloud e che si basano su diverse metriche, suddivisione del traffico basata sulle ponderazioni. Puoi anche scalare i backend in base capacità di gestione del bilanciamento del carico per i carichi di lavoro in Google Cloud. Per ulteriori informazioni, 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, il 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à dei carichi di lavoro, un'applicazione potrebbe essere trasportabile in un ambiente diverso con modifiche minime per ottenere la coerenza del carico di lavoro, ma ciò non significa che l'applicazione funzioni allo stesso modo in entrambi gli ambienti. In genere, le differenze nelle funzionalità di sicurezza dell'infrastruttura, nelle risorse di calcolo sottostanti o nell'infrastruttura di rete, nonché la vicinanza ai servizi dipendenti, determinano le prestazioni. Grazie ai test, puoi avere una visibilità più accurata e comprendere le aspettative relative al 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 carichi di lavoro e che le origini dati sono attuali.
  • Potresti dover aggiungere l'automazione per eseguire il provisioning del cloud dell'ambiente e reindirizzano il traffico quando la domanda aumenta e il cloud deve accettare richieste del client per la tua applicazione.

• Se intendi arrestare tutte le risorse Google Cloud durante 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ò accade principalmente perché:

  • L'inizializzazione delle risorse può richiedere del tempo prima che possano essere messe a disposizione degli utenti.
  • Gli aggiornamenti DNS tendono a propagarsi lentamente su internet.

  Di conseguenza:

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

Con Cloud DNS, puoi scegliere i criteri DNS e di routing in linea con l'architettura e il comportamento della tua soluzione, ad esempio i criteri di routing DNS per la geolocalizzazione. Cloud DNS supporta anche i controlli di integrità per il bilanciatore del carico di rete passthrough interno e per il bilanciatore del carico delle applicazioni interno. In questo caso, puoi incorporarlo nella configurazione DNS ibrida complessiva basata su questo pattern.

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

Puoi anche utilizzare l'orizzonte diviso di Cloud DNS. L'orizzonte diviso di Cloud DNS è un approccio per configurare le risposte o i record DNS per la posizione o la rete specifica dell'autore 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 sia un'esperienza privata sia una pubblica, ciascuna con funzionalità uniche. L'approccio aiuta anche a distribuire il carico del traffico tra gli ambienti.

Date queste considerazioni, l'esplosione cloud si presta in genere meglio ai carichi di lavoro batch rispetto a quelli interattivi.

Vantaggi

I principali vantaggi del pattern di architettura di cloud bursting includono:

• L'esplosione cloud ti consente di riutilizzare gli investimenti esistenti in data center e ambienti di calcolo privati. Questo riutilizzo può essere permanente o essere in vigore fino alla data di sostituzione dell'apparecchiatura esistente, a quel punto potresti prendere in considerazione una migrazione completa.
• Perché non è più necessario mantenere la capacità in eccesso per soddisfare i picchi richieste, potresti essere in grado di aumentare l'uso e la convenienza dei nei tuoi ambienti di computing privati.
• Il cloud bursting consente di eseguire job batch in modo tempestivo senza necessarie per l'overprovisioning delle risorse di computing.

Best practice

Quando implementi l'esplosione cloud, considera le seguenti best practice:

• Per garantire che i carichi di lavoro in esecuzione nel cloud possano accedere alle risorse in come i carichi di lavoro eseguiti in un ambiente on-premise, il motivo mesh con il principio di accesso di sicurezza con privilegi minimi. Se il design del carico di lavoro lo consente, puoi consentire l'accesso solo dal cloud all'ambiente di calcolo on-premise e non viceversa.
• Per ridurre al minimo la latenza per la comunicazione tra gli ambienti, scegli una regione Google Cloud vicina geograficamente al tuo ambiente di calcolo privato. Per maggiori informazioni, consulta Best practice per la scelta delle regioni Compute Engine.
• Se utilizzi il cloud bursting solo per carichi di lavoro batch, riduci la sicurezza superficie di attacco 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 di Google Cloud per fornire il punto di contatto al carico di lavoro.

• Seleziona i criteri DNS e di routing in linea con il pattern di architettura e il comportamento della soluzione di destinazione.

  • Nell'ambito di questo pattern, puoi applicare la progettazione del tuo DNS in modo permanente o quando hai bisogno di ulteriore capacità utilizzando un altro dell'ambiente nei periodi di picco della domanda.
  • Puoi utilizzare i criteri di routing del DNS di geolocalizzazione per avere un Endpoint DNS per i bilanciatori del carico a livello di regione. Questa tattica ha molte casi d'uso per i criteri di routing DNS di geolocalizzazione, incluse applicazioni ibride che utilizzano Google Cloud insieme il deployment on-premise dove esiste la regione Google Cloud.

  • Se devi fornire record diversi per le stesse query DNS, puoi utilizzare il DNS con orizzonte diviso, ad esempio per le query provenienti da client interni ed esterni.

    Per ulteriori informazioni, consulta le architetture di riferimento per il DNS ibrido

• Per assicurarti che le modifiche DNS vengano propagate rapidamente, configura il DNS con un valore TTL ragionevolmente breve in modo da poter reindirizzare gli utenti a sistemi di riserva quando hai bisogno di una maggiore capacità utilizzando ambienti cloud.

• Per i job che non sono molto critici in termini di tempo e non memorizzano dati localmente, valuta la possibilità di utilizzare istanze VM spot, che sono notevolmente più economiche delle normali istanze VM. Prerequisito se il job VM viene prerilasciato, il sistema deve essere in grado di riavvia automaticamente il job.

• Utilizza i container per ottenere la portabilità dei carichi di lavoro, se applicabile. Inoltre, GKE Enterprise può essere una tecnologia chiave che abilita questo la progettazione. Per ulteriori informazioni, consulta Architettura di riferimento dell'ambiente ibrido GKE Enterprise.

• Monitora il traffico inviato da Google Cloud a un'altra nell'ambiente di computing. Questo traffico è soggetto a addebiti per trasferimento di dati in uscita.

• Se prevedi di utilizzare questa architettura a lungo termine con un elevato volume di dati in uscita per il volume di trasferimento, considera l'uso 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 maggiori informazioni, consulta i prezzi di Cloud Interconnect.

• Quando utilizzi Cloud Load Balancing, devi utilizzare le sue funzionalità di ottimizzazione della capacità dell'applicazione, ove applicabili. In questo modo, puoi risolvere alcune delle problematiche relative alla 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 modo sicuro nei confini degli ambienti.

• Per proteggere le informazioni sensibili, crittografando tutte le comunicazioni in il trasporto pubblico è vivamente consigliato. Se è richiesta la crittografia di connettività, sono disponibili varie opzioni in base soluzione di connettività ibrida. 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 approcciarti all'architettura ibrida e multicloud e come scegliere i carichi di lavoro adatti.
• Scopri di più sui modelli di architettura di rete adatti ai modelli di architettura ibrida e multi-cloud selezionati.
• Scopri di più su Deployment di archetipi per applicazioni cloud.
• Scopri come progettare e implementare un'applicazione web di e-commerce utilizzando diverse architetture, tra cui applicazione web di ecommerce basata su microservizi usando GKE e un'applicazione web dinamica Basata su API serverless.