Modelli di architettura ibrida e multi-cloud

Last reviewed 2024-11-27 UTC

Questa pagina fornisce una visualizzazione in un'unica pagina di tutte le pagine di Creare architetture ibride e multi-cloud utilizzando 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 documento è il secondo di tre documenti in un insieme. Vengono descritti i modelli di architettura ibrida e multi-cloud più comuni. Descrive inoltre gli scenari per i quali questi pattern sono 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: discute la pianificazione di una strategia per l'architettura di una configurazione ibrida e multi-cloud 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 reti sicure ibride e multi-cloud: discute i modelli di architettura di reti ibride e multi-cloud dal punto di vista della rete.

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

Un pattern 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 un componente funzionale 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 le funzioni frontend per fornire un'interfaccia utente grafica o le funzioni di backend per fornire l'accesso ai dati.
• Come i componenti comunicano tra loro e con sistemi o utenti esterni. 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:

• Pattern di architettura distribuita: Questi pattern si basano su un deployment distribuito di carichi di lavoro o componenti dell'applicazione. 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ò sfruttare le diverse proprietà e caratteristiche degli ambienti di calcolo distribuiti e interconnessi.
• Pattern di architettura ridondante: Questi pattern si basano su deployment ridondanti dei workload. In questi pattern, esegui il deployment delle stesse applicazioni e dei relativi componenti in più ambienti di calcolo. L'obiettivo è aumentare la capacità o la resilienza delle prestazioni di un'applicazione oppure replicare un ambiente esistente per lo sviluppo e i 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 ambiti di errore all'interno dei quali un'applicazione può operare. Questi domini in errore possono includere una o più Google Cloud zone o regioni e possono essere espansi per includere i tuoi data center on-premise o i domini in errore in altri provider cloud.

Questa serie contiene le seguenti pagine:

• Modelli di architettura distribuita

  • Modello ibrido multilivello

  • Modello multicloud partizionato

  • Modello di analisi ibrida e multi-cloud

  • Modello ibrido perimetrale

• Modelli di architettura ridondanti

  • Modello 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 | Engineering Fellow
• Marco Ferrari | Cloud Solutions Architect
• Victor Moreno | Product Manager, Cloud Networking
• Johannes Passing | Cloud Solutions Architect
• Mark Schlagenhauf | Technical Writer, Networking
• Daniel Strebel | 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 aver preso in considerazione 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 distribuiti. A seconda della soluzione target e degli scopi commerciali, la priorità e l'effetto di ogni considerazione possono variare.

Latenza

In qualsiasi modello di architettura che distribuisce i componenti dell'applicazione (frontend, backend o microservizi) in diversi ambienti di calcolo, può verificarsi la 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à ai ritardi della rete. Le applicazioni che possono tollerare la latenza sono candidate più adatte per il deployment distribuito iniziale in un ambiente ibrido o multicloud.

Architettura dello stato temporaneo e finale

Per specificare le aspettative e le potenziali implicazioni per costi, scalabilità e rendimento, è importante analizzare il tipo di architettura 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 molto tempo o in modo permanente, ti consigliamo di utilizzare Cloud Interconnect. Per ridurre i costi di trasferimento dei dati in uscita e ottimizzare le prestazioni della rete di connettività ibrida, Cloud Interconnect sconta gli addebiti per il trasferimento dei dati in uscita che soddisfano le condizioni di tariffa scontata per il trasferimento dei 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 i componenti ridondanti di quella stessa applicazione in più zone di una singola regione¹ o in più regioni, con funzionalità di passaggio. La ridondanza è uno degli elementi chiave per migliorare la disponibilità complessiva di un'applicazione. Per le applicazioni con una configurazione distribuita in ambienti ibridi e multi-cloud, è importante mantenere un livello di disponibilità coerente.

Per migliorare la disponibilità di un sistema in un ambiente on-premise o in altri ambienti cloud, valuta la ridondanza hardware o software, con meccanismi di failover, necessaria per le tue applicazioni e i relativi componenti. Idealmente, dovresti prendere in considerazione la disponibilità di un servizio o di un'applicazione tra i vari componenti e l'infrastruttura di supporto (inclusa la disponibilità della 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 che preferisci, definisci metriche di affidabilità chiare e progetta le applicazioni in modo che si riparino autonomamente e resistano alle interruzioni in modo efficace nei diversi ambienti. Per aiutarti a definire metodi appropriati per misurare l'esperienza dei clienti con i tuoi servizi, consulta Definire l'affidabilità in base agli obiettivi relativi all'esperienza utente.

Connettività ibrida e multi-cloud

I requisiti della comunicazione tra i componenti delle applicazioni distribuite devono influire sulla scelta di un'opzione di 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 la sezione Considerazioni sul design 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 gestione. Tecnicamente, più provider cloud utilizzi, più complessa diventa la gestione dei tuoi ambienti. La maggior parte dei fornitori di servizi cloud pubblici non solo dispone di funzionalità diverse, ma ha anche vari strumenti, SLA e API per la gestione dei servizi cloud. Pertanto, valuta i vantaggi strategici dell'architettura selezionata rispetto alla potenziale complessità a breve termine 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 si creano soluzioni cloud-first in più ambienti cloud, i prodotti, i prezzi, gli sconti e gli strumenti di gestione di ciascun fornitore possono creare incoerenze nei costi 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 dei fornitori di cloud che utilizzi e utilizzando il Google Cloud blocco di gestione dei costi cloud di Looker, puoi creare una visualizzazione centralizzata dei costi multicloud. Questa visualizzazione può aiutarti a fornire una visualizzazione consolidata dei report sulla spesa su più cloud. Per ulteriori informazioni, consulta la strategia per ottimizzare in modo efficace la gestione dei costi di fatturazione cloud.

Ti consigliamo inoltre di utilizzare le best practice FinOps per rendere visibili i costi. Nell'ambito di una solida pratica FinOps, un team centrale può delegare la presa di decisioni per l'ottimizzazione delle risorse a qualsiasi altro team coinvolto in un progetto per stimolare la responsabilità individuale. In questo modello, il team centrale deve standardizzare la procedura, i 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 Google Cloud Framework di architettura: 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 potrebbero influenzare l'applicazione e l'architettura della pipeline di dati. L'insieme completo diGoogle Cloudopzioni di spostamento dei dati consente alle aziende di soddisfare le proprie esigenze specifiche e di adottare architetture ibride e multicloud senza compromettere la semplicità, l'efficienza o le 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 provider di cloud pubblico ha il proprio approccio, le proprie best practice e le proprie funzionalità per la sicurezza. È importante analizzare e allineare queste funzionalità per creare un'architettura di sicurezza funzionale e standard. 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 creazione di una landing zone è quasi sempre un 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 della zona di destinazione in Google Cloud.

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

• Modello ibrido multilivello
• 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 da 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. 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. In alcune architetture, la logica di business potrebbe essere incorporata nel componente di backend. Le nuove release delle applicazioni di backend tendono a essere meno frequenti rispetto alle release per le applicazioni di frontend. Le applicazioni di backend devono gestire le seguenti sfide:

• Gestione di un elevato volume di richieste
• Gestione di un volume elevato 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 contiene i seguenti livelli. Ogni livello opera in modo indipendente, ma sono strettamente collegati e funzionano tutti insieme.

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

Inserire questi livelli in contenitori separa le relative esigenze tecniche, come i requisiti di scalabilità, e aiuta a eseguirne la migrazione in modo 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 cloud, come Cloud Run o Google Kubernetes Engine (GKE) Enterprise Edition. Inoltre, i database gestiti daGoogle Cloud come Cloud SQL contribuiscono a fornire il backend come livello del database.

Nota: l'implementazione di questa architettura e la definizione dei suoi componenti possono variare a seconda che tu separi i livelli in singoli sistemi e livelli o li combini.

Il pattern di architettura ibrida a più livelli si concentra sul deployment dei componenti dell'applicazione frontend esistenti nel cloud pubblico. In questo modello, mantieni tutti i componenti dell'applicazione di backend esistenti nel loro ambiente di calcolo privato. A seconda delle dimensioni e del design specifico dell'applicazione, puoi eseguire la migrazione dei componenti dell'applicazione frontend caso per caso. Per ulteriori informazioni, consulta la pagina 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 prendere in considerazione il costo, il tempo e il rischio di una simile 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 ospitato in 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 pattern di architettura ibrida a più livelli, puoi sfruttare Google Cloud l'infrastruttura e i servizi globali, come mostrato nell'architettura di esempio nel diagramma seguente. Il frontend dell'applicazione è accessibile tramite Google Cloud. Può anche aggiungere elasticità al frontend utilizzando la scalabilità automatica per rispondere in modo dinamico ed efficiente alla domanda in crescita senza sovraprovisioning dell'infrastruttura. Esistono diverse architetture che puoi utilizzare per creare ed eseguire app web scalabili su Google Cloud. Ogni architettura presenta vantaggi e svantaggi per requisiti diversi.

Per saperne di più, guarda 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 fornire un'esperienza utente ottimizzata a livello globale e su più regioni 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 potrebbe aumentare al punto da farti prendere in considerazione la possibilità di spostare i componenti dell'applicazione di backend nel 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 i dati quando necessario.

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

Vantaggi

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

• I componenti frontend dipendono dalle risorse di backend e occasionalmente da altri componenti frontend.
• I componenti di backend non dipendono dai componenti di 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 loro migrazione tende a essere meno complessa rispetto a quella dei backend.
  • I componenti frontend possono essere ottimizzati nell'ambito della migrazione per utilizzare un'architettura stateless. Per saperne di più, guarda Come eseguire il porting di app web con stato in Cloud Run su YouTube.

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

• Molte applicazioni frontend sono soggette a modifiche frequenti. L'esecuzione di queste applicazioni nel cloud pubblico semplifica la configurazione di un processo di integrazione/deployment continuo (CI/CD). Puoi utilizzare CI/CD per inviare aggiornamenti in modo efficiente e automatico. Per ulteriori informazioni, consulta CI/CD su Google Cloud.
• I frontend sensibili alle prestazioni con un carico di traffico variabile possono trarre sostanziali vantaggi dal bilanciamento del carico, dai deployment multiregionali, dal caching di Cloud CDN, dalle funzionalità serverless e di scalabilità automatica abilitati da un deployment basato su cloud (idealmente con un'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 è comunemente utilizzata con i frontend che coinvolgono diversi team che collaborano alla stessa applicazione. Questo tipo di struttura del team richiede un approccio iterativo e una manutenzione continua. Ecco alcuni dei vantaggi dell'utilizzo dei microfrontend:

  • Può essere trasformato in moduli di microservizi indipendenti per sviluppo, test e deployment.
  • Offre una separazione in cui i singoli team di sviluppo possono selezionare le tecnologie e il codice che preferiscono.
  • Può favorire cicli rapidi di sviluppo e deployment senza influire sul resto dei componenti frontend che potrebbero essere gestiti da altri team.

• Che si tratti di implementare interfacce utente o API o di gestire 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.

• I proxy API gestiti su Cloud aiutano a:

  • Disaccoppia l'API per le app dai tuoi servizi di backend, come i 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 in modo inverso, eseguendo il deployment dei backend nel cloud e mantenendo i frontend in ambienti di calcolo privati. Sebbene sia meno comune, questo approccio è preferibile quando si ha a che fare con un frontend pesante e monolitico. In questi casi, potrebbe essere più semplice estrarre la funzionalità di backend in modo iterativo e implementare questi nuovi backend nel cloud.

La terza parte di questa serie illustra possibili modelli di networking per abilitare una tale architettura. Apigee hybrid è una piattaforma per la creazione e la gestione di proxy API in un modello di deployment ibrido. Per ulteriori informazioni, consulta Architettura accoppiata in modo lasco, incluse le architetture monolitiche e dei 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 controllata. Idealmente, devi esporre i componenti dell'applicazione utilizzando API sicure. Per ulteriori informazioni, consulta la sezione Uscita controllata.

• Per ridurre al minimo la latenza di comunicazione tra gli ambienti, seleziona una Google Cloud regione geograficamente vicina all'ambiente di calcolo privato in cui sono ospitati i componenti di backend dell'applicazione. Per saperne di più, consulta Best practice per la scelta delle regioni Compute Engine.
• Riduci al minimo le dipendenze elevate tra sistemi in esecuzione in ambienti diversi, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni, ridurre la disponibilità complessiva e potenzialmente comportare costi aggiuntivi per il trasferimento di dati in uscita.
• Con il pattern di architettura ibrida a più livelli, potresti avere volumi maggiori di traffico in entrata proveniente da ambienti on-premise rispetto al traffico in uscita Google Cloud.Google Cloud Tuttavia, devi conoscere il volume previsto di trasferimento di dati in uscita in uscita 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 ulteriori informazioni, consulta i prezzi di Cloud Interconnect.
• Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito. Se è richiesta la crittografia a livello di connettività, puoi utilizzare i tunnel VPN, la VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

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

  • Implementa misure di sicurezza aggiuntive.
  • Protegge le app client e altri servizi dalle modifiche al codice di 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 hybrid ti consentono di ospitare e gestire gateway ibridi e di livello aziendale 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 cloud ai servizi ospitati nel tuo ambiente di calcolo on-premise. Questo approccio consente di eseguire migrazioni dei carichi di lavoro in più fasi a Google Cloud con interruzioni minime o nulle del servizio, garantendo una transizione fluida per i servizi distribuiti. Per maggiori informazioni, consulta la panoramica dei gruppi di endpoint di rete con connettività ibrida.

• A volte, l'utilizzo di un API Gateway o di un proxy e di un Application Load Balancer insieme può fornire una soluzione più solida per gestire, proteggere e distribuire il traffico 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 saperne di più, guarda Pubblicazione di API ad alte prestazioni con Apigee e Cloud CDN su YouTube.
  • Implementa la gestione avanzata del traffico.
  • Utilizza Google Cloud Armor come servizio di protezione DDoS e sicurezza della rete per proteggere le tue API.
  • Gestisci un bilanciamento del carico efficiente tra i 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 Cloud Service Mesh per consentire la comunicazione tra servizi, che mantiene la qualità del servizio in un sistema composto da servizi distribuiti in cui puoi gestire l'autenticazione, l'autorizzazione e la crittografia tra i servizi.
  • Utilizza una piattaforma di gestione delle API come Apigee che consente alla tua organizzazione e a entità esterne di utilizzare questi servizi esponendoli come API.

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

• Esegui il deployment di sistemi di gestione delle configurazioni e CI/CD nel cloud pubblico. Per ulteriori informazioni, consulta Modello di architettura di rete con mirroring.

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

Best practice per singoli carichi di lavoro e architetture di applicazioni

• Anche se in questo pattern l'attenzione è incentrata sulle applicazioni frontend, tieni conto della necessità di modernizzare le applicazioni di backend. Se il ritmo di sviluppo delle applicazioni di backend è notevolmente più lento rispetto a quello delle applicazioni di 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 l'approccio di rendering per la tua applicazione web frontend in base ai contenuti (statici o dinamici), al rendimento dell'ottimizzazione per i motori di ricerca e alle aspettative relative alle 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 l'architettura più adatta, valuta attentamente queste opzioni in base ai requisiti attuali e futuri dell'applicazione. Per aiutarti a prendere una decisione di architettura in linea con i tuoi scopi commerciali e tecnici, consulta Confronto di diverse architetture per i backend delle applicazioni web basate su contenuti e Considerazioni chiave per i backend web.

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

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

    • Quando utilizzi container e Kubernetes in diversi ambienti, hai la flessibilità di modernizzare i carichi di lavoro e poi eseguire la migrazione a Google Cloud in momenti diversi. 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 Google Cloud ambiente per i componenti dell'applicazione sottoposti a migrazione e modernizzazione.

    • 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.

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

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

Pattern multicloud 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 pattern di architettura può essere creato in due modi diversi. Il primo approccio si basa sul deployment dei componenti dell'applicazione in diversi ambienti cloud pubblico. Questo approccio è noto anche come architettura composita ed è lo stesso approccio del pattern di architettura ibrida a più livelli. Tuttavia, anziché utilizzare un ambiente on-premise con un cloud pubblico, utilizza almeno due ambienti cloud. In un'architettura composita, un singolo carico di lavoro o un'applicazione utilizza componenti di più 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 loro esigenze e preferenze specifiche.
• Per operare in un deployment cloud multiregionale o globale. Se un'azienda deve rispettare le normative sulla residenza dei dati in regioni o paesi specifici, deve scegliere tra i fornitori di cloud disponibili in quella località se il suo fornitore di cloud principale non ha una regione cloud in quella località.

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 fondamentale. 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 accennato in precedenza, in alcune situazioni potrebbero esserci motivi sia commerciali che tecnici per combinare Google Cloud un altro fornitore cloud e suddividere i carichi di lavoro tra questi ambienti cloud. Le soluzioni multi-cloud offrono la flessibilità necessaria per eseguire la migrazione, creare e ottimizzare la portabilità delle applicazioni in ambienti multi-cloud, riducendo al minimo il vincolo e aiutandoti a soddisfare i requisiti normativi. Ad esempio, potresti connetterti Google Cloud a Oracle Cloud Infrastructure (OCI) per creare una soluzione multicloud che sfrutta le funzionalità di ciascuna 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, consulta Google Cloud e Oracle Cloud Infrastructure: sfrutta al meglio il multi-cloud. Inoltre, Cross-Cloud Interconnect facilita la connettività dedicata a elevata larghezza di banda tra Google Cloud e altri fornitori di servizi cloud supportati, consentendoti di progettare e creare soluzioni multicloud per gestire un elevato volume di traffico inter-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 prendere in considerazione attentamente eventuali sfide dirette o indirette o potenziali ostacoli associati 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 del pattern di architettura multicloud suddivisa:

• In scenari in cui potresti dover ridurre al minimo l'impegno con un singolo provider cloud, puoi distribuire le applicazioni su più provider cloud. Di conseguenza, potresti ridurre relativamente il lock-in del fornitore con la possibilità di cambiare i piani (in misura limitata) tra i tuoi provider cloud. Il cloud aperto contribuisce a portare Google Cloud funzionalità, come GKE Enterprise, in località fisiche diverse. Con l' Google Cloud estensione delle funzionalità on-premise, in più cloud pubblici e on the edge, offre flessibilità, agilità e favorisce la trasformazione.

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

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

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

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

• Inizia con 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, ridurre la disponibilità complessiva e potenzialmente comportare addebiti aggiuntivi per il trasferimento dei 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 fornisce la soluzione di comunicazione più efficiente ed efficace per le applicazioni in uso.
  • La comunicazione deve essere granulare e controllata. Utilizza API sicure 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 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 è richiesta la crittografia a livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cross-Cloud Interconnect.

• Se utilizzi più CDN nell'ambito del tuo pattern di architettura partizionata multicloud e stai compilando l'altra CDN con file di dati di grandi dimensioni da Google Cloud, ti consigliamo di utilizzare i link CDN Interconnect tra Google Cloud e i fornitori supportati per ottimizzare questo traffico e, potenzialmente, il relativo 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 in modo efficace le richieste tra Google Cloud e un'altra piattaforma cloud, puoi utilizzare 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à di utilizzare Cross-Cloud Interconnect.

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

  • Implementa misure di sicurezza aggiuntive.
  • Protegge le app client e altri servizi dalle modifiche al codice di 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 hybrid ti consentono di ospitare e gestire gateway ibridi e di livello aziendale in ambienti on-premise, edge, altri cloud e 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 multi-regione per gli ambienti di runtime delle API Apigee in regioni diverse.

  • Aumento delle prestazioni con Cloud CDN.

  • Fornisce protezione WAF e DDoS tramite Google Cloud Armor.

• Se possibile, utilizza strumenti coerenti per il logging e il monitoraggio negli ambienti cloud. 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 un'unica 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 lo scopo del pattern di analisi ibrido e multicloud è sfruttare 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 workload transazionali includono applicazioni interattive come vendite, elaborazione finanziaria, pianificazione delle risorse aziendali o comunicazione.
• I carichi di lavoro di analisi includono applicazioni che trasformano, analizzano, perfezionano o visualizzano i dati per supportare 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 transazionali tendono a essere separati e accoppiati in modo lasco. Lo scopo del pattern analytics ibrido e multi-cloud è sfruttare questa suddivisione preesistente eseguendo carichi di lavoro transazionali e di analisi in due ambienti di calcolo diversi. I dati non elaborati vengono prima estratti dai carichi di lavoro in esecuzione nell'ambiente di calcolo privato e poi caricati inGoogle Cloud, dove vengono utilizzati per l'elaborazione analitica. Alcuni risultati potrebbero poi essere ritrasmessi ai sistemi transazionali.

Il seguente diagramma illustra 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 trasferire i tuoi dati in Google Cloud e sbloccarne il valore, utilizza i servizi di trasferimento dei dati, una suite completa di servizi di importazione, integrazione e replica dei dati.

Come mostrato nel diagramma precedente, la connessione Google Cloud con ambienti on-premise e altri ambienti cloud può abilitare vari casi d'uso di analisi dei dati, come lo streaming di dati e i backup del database. Per supportare il trasporto di base di un pattern di analisi ibrida e multicloud che richiede un elevato volume di trasferimento di dati, Cloud Interconnect e Cross-Cloud Interconnect forniscono connettività dedicata ai provider cloud on-premise e di altro tipo.

Vantaggi

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

• Il traffico in entrata, ovvero il trasferimento di dati dal tuo ambiente di calcolo privato o da altri cloud aGoogle Cloud, potrebbe essere gratuito.
• 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. Se esegui la scalabilità dinamica delle risorse di calcolo, puoi elaborare rapidamente set di dati di grandi dimensioni evitando investimenti iniziali o dover eseguire il provisioning eccessivo delle apparecchiature di calcolo.
• Google Cloud offre una vasta gamma di servizi per gestire i dati durante l'intero ciclo di vita, dall'acquisizione iniziale all'elaborazione e all'analisi fino alla visualizzazione finale.
  • I servizi di spostamento dei dati su Google Cloud 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ò offrire la flessibilità, la scalabilità e l'agilità necessarie per garantire che i dati generino valore per la tua attività, anziché inefficienze. Per ulteriori informazioni, consulta BigLake.

• BigQuery Omni offre 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 multicloud consente ai team di 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 di analisi devono essere reintegrati nei sistemi transazionali, puoi combinare il pattern di uscita controllata con il pattern di riassegnazione.
• Utilizza le code Pub/Sub o i bucket Cloud Storage per trasferire i dati da Google Cloud a sistemi transazionali Google Cloud in esecuzione nel tuo ambiente di calcolo privato. Queste code o questi bucket possono quindi fungere da origini per pipeline e workload 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 dati cloud-first completamente gestiti per creare e gestire pipeline di dati.
• Per scoprire, classificare e proteggere i tuoi preziosi asset di dati, valuta la possibilità di utilizzare le funzionalità di Google Cloud Sensitive Data Protection, come le tecniche di anonimizzazione. Queste tecniche 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 iniziale dei dati dal tuo ambiente di calcolo privato a Google Cloud, scegli l'approccio di trasferimento più adatto alle dimensioni del tuo set di dati e alla larghezza di banda disponibile. Per ulteriori informazioni, 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 è necessario per il lungo termine con un volume di traffico elevato, ti consigliamo di valutare l'utilizzo di Google Cloud Cross-Cloud Interconnect per aiutarti a stabilire una connettività dedicata ad alta larghezza di banda tra Google Cloud e altri provider di servizi cloud (disponibile in determinate località).

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

• Utilizza strumenti e 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 Edge

L'esecuzione di workload 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. Esistono tuttavia scenari in cui non puoi fare affidamento su una connettività continua, ad esempio:

• Le navi e altri veicoli potrebbero essere collegati solo intermittentemente o avere accesso solo a link satellitari ad alta latenza.
• Le fabbriche o le centrali elettriche potrebbero essere connesse a internet. Queste strutture potrebbero avere requisiti di affidabilità superiori alle dichiarazioni di disponibilità del proprio fornitore di servizi 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'architettura ibrida di edge, il link a internet è un componente non critico utilizzato per scopi di gestione e per sincronizzare o caricare dati, spesso in modo asincrono, ma non è coinvolto nelle transazioni in tempo reale o fondamentali per l'attività.

Vantaggi

L'esecuzione di determinati carichi di lavoro all'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 workload business-critical e in tempo reale a livello perimetrale contribuisce a garantire bassa latenza e autosufficienza. Se la connessione a internet non riesce o non è temporaneamente disponibile, puoi comunque eseguire tutte le transazioni importanti. Allo stesso tempo, puoi trarre vantaggio dall'utilizzo del cloud per una parte significativa del tuo carico di lavoro complessivo.
• Puoi riutilizzare gli investimenti esistenti in apparecchiature di calcolo e archiviazione.
• Nel tempo, puoi ridurre gradualmente la frazione di carichi di lavoro eseguiti sull'edge e spostarli nel cloud, modificando determinate applicazioni o dotando alcune località edge di link a internet più affidabili.
• I progetti relativi all'Internet of Things (IoT) possono diventare più convenienti eseguendo i calcoli dei dati localmente. In questo modo, le aziende possono eseguire e elaborare alcuni servizi localmente all'edge, più vicino 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 i servizi legacy e modernizzati. Ad esempio, servizi che potrebbero eseguire un gateway API containerizzato come Apigee hybrid. In questo modo, è possibile integrare le applicazioni e i sistemi legacy con i servizi modernizzati, 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 controllo.
• Se la soluzione è composta da molti siti edge remoti che si connettonoGoogle Cloud tramite internet pubblico, puoi utilizzare una soluzione SD-WAN (WAN software-defined). Puoi anche utilizzare Network Connectivity Center con un router SD-WAN di terze parti supportato da un Google Cloud partner per semplificare il provisioning e la gestione della connettività sicura su larga scala.
• 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 in termini di affidabilità e latenza di una configurazione ibrida edge.
• Per gestire e utilizzare in modo efficiente più località edge, devi avere un piano di gestione e una soluzione di monitoraggio centralizzati nel cloud.
• Assicurati che le pipeline CI/CD e gli strumenti per il deployment e il monitoraggio siano coerenti negli ambienti cloud ed edge.
• Valuta la possibilità di utilizzare contenitori e Kubernetes, se applicabili e possibili, per astrarre le differenze tra le varie località edge e anche tra le località edge e il cloud. Poiché Kubernetes fornisce un livello di runtime comune, puoi sviluppare, eseguire e gestire i carichi di lavoro in modo coerente in tutti gli ambienti di calcolo. Puoi anche spostare i carichi di lavoro tra l'edge e il cloud.
  • Per semplificare la configurazione e il funzionamento ibride, 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 connettere un cluster GKE Enterprise in esecuzione nel tuo ambiente on-premise o edge a Google Cloud.
• Nell'ambito di questo modello, anche se alcuni componenti di GKE Enterprise potrebbero essere danneggiati durante un'interruzione temporanea della connettività conGoogle Cloud, non utilizzare GKE Enterprise quando è disconnesso da Google Cloud come modalità di lavoro nominale. Per ulteriori informazioni, consulta Impatto della disconnessione temporanea da Google Cloud.
• Per superare le incoerenze in protocolli, API e meccanismi di autenticazione tra diversi servizi di backend ed edge, consigliamo, ove applicabile, di implementare un proxy o un API Gateway come facade unificante. 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 di 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 Hybrid ti consentono di ospitare e gestire gateway ibridi e di livello aziendale in ambienti on-premise, edge, altri cloud e Google Cloud .
• Stabilisci un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro oltre i confini degli ambienti.
• 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 modello di architettura ambiente ibrido, mantieni l'ambiente di produzione di un carico di lavoro nel data center esistente. Poi utilizzi il cloud pubblico per gli ambienti di sviluppo e test o per altri ambienti. Questo pattern si basa sul deployment ridondante delle stesse applicazioni in più ambienti di calcolo. L'obiettivo del deployment è contribuire ad aumentare la capacità, l'agilità e la resilienza.

Quando valuti i carichi di lavoro di cui eseguire la migrazione, potresti notare casi in cui l'esecuzione di un'applicazione specifica nel cloud pubblico presenta delle 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, prendi in considerazione non solo l'ambiente di produzione, ma tutti gli ambienti coinvolti nel ciclo di vita di un'applicazione, inclusi i sistemi di sviluppo, test e gestione temporanea. Spesso queste limitazioni si applicano all'ambiente di produzione e ai relativi dati. Potrebbero non essere applicabili ad altri ambienti che non utilizzano i dati effettivi. Rivolgiti al reparto di conformità della tua organizzazione o al team equivalente.

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

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

Sebbene i processi di sviluppo, test e deployment siano diversi per ogni applicazione, in genere prevedono varianti delle seguenti fasi:

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

Eseguire più di una di queste fasi in un unico ambiente è raramente pratico, quindi ogni fase richiede in genere uno o più ambienti dedicati.

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

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

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

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

In generale, non è un problema se gli ambienti utilizzati per lo sviluppo e i test funzionali sono diversi da un punto di vista non funzionale rispetto agli 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 utilizzato come opzione per lo sviluppo e i test in Google Cloud. Per lo sviluppo e il test è possibile utilizzare lo stesso motore e la stessa versione del database nell'ambiente on-premise, un motore funzionalmente equivalente o una nuova versione implementata nell'ambiente di produzione dopo la fase di test. Tuttavia, poiché l'infrastruttura di base dei due ambienti non è identica, questo approccio ai test di carico del rendimento 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 Enterprise di Google Kubernetes Engine (GKE) può essere una tecnologia di base fondamentale per questo approccio.
  • Garantire la portabilità dei carichi di lavoro e scorporare le differenze tra gli ambienti di calcolo. Con una mesh di servizi zero trust, puoi controllare e mantenere la separazione delle comunicazioni necessaria 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 assicurarti che l'approccio selezionato sia in linea con i tuoi requisiti specifici, basa le tue scelte su una valutazione approfondita delle esigenze e dei vincoli della tua attività.
• Differenze di ambiente: nell'ambito di questo pattern, l'obiettivo principale dell'utilizzo di questo ambiente cloud è lo sviluppo e i test. Lo stato finale è l'hosting dell'applicazione testata nell'ambiente on-premise privato (produzione). Per evitare di sviluppare e testare una funzionalità che potrebbe funzionare come previsto nell'ambiente cloud e non funzionare nell'ambiente di produzione (on-premise), il team tecnico deve conoscere e comprendere le architetture e le funzionalità 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 ad assicurarsi di non utilizzare funzionalità cloud negli ambienti di sviluppo e test che non esistono nell'ambiente di produzione on-premise.
• Criteri di successo: devono essere presenti criteri di successo dei test chiari, predefiniti e misurabili in linea con gli standard di controllo qualità del software per la tua organizzazione. Applica questi standard a qualsiasi applicazione che sviluppi e testi.
• 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.
  • Puoi velocizzare lo sviluppo e i test avviando ambienti effimeri per ogni pull request. 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 familiarizzare con il cloud e gli strumenti correlati, il che potrebbe essere utile per 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 dell'ambiente, considera 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 è necessaria la comunicazione tra ambienti, deve avvenire in modo controllato.

• 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 l'implementazione graduale delle modifiche in un ambiente o gruppo di utenti specifico prima del rilascio su larga scala, senza tempi di inattività.

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

• Stabilire una catena di strumenti comune che funzioni in tutti gli ambienti di calcolo 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 gli ambienti di calcolo e che lo stesso insieme di binari, pacchetti o contenitori venga implementato in tutti 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, consulta Soluzioni DevOps su Google Cloud.

• Per aiutarti con il rilascio continuo di applicazioni sicure e affidabili, incorpora la sicurezza come parte integrante del processo 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 tutti gli ambienti cloud esistenti. Google Cloud Valuta 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 team diversi gestiscono i carichi di lavoro di test e produzione, l'utilizzo di strumenti distinti potrebbe essere accettabile. Tuttavia, l'utilizzo degli stessi strumenti con autorizzazioni di visualizzazione diverse può contribuire a ridurre la complessità e lo sforzo di addestramento.

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

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

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

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

Modelli di business continuity ibridi e multi-cloud

L'elemento principale che spinge a 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. Se repliche i sistemi e i dati in più regioni geografiche ed eviti i single point of failure, puoi ridurre al minimo i rischi di una calamità naturale che colpisce l'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 agli errori è fondamentale 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 saperne di più su come progettare e gestire servizi affidabili su Google Cloud, consulta il pilastro della affidabilità del Google Cloud Framework dell'architettura e gli elementi costitutivi 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à.

Il ripristino di emergenza (RE) è considerato un sottoinsieme della continuità aziendale, incentrato esplicitamente sull'assicurare che i sistemi IT che supportano le funzioni aziendali critiche tornino operativi il prima possibile dopo un'interruzione. In generale, le strategie e i piani di RP 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 un costo più elevato perché implica la creazione di sistemi ridondanti. I sistemi ridondanti in grado di eseguire la replica dei dati quasi in tempo reale e che operano alla stessa scala in seguito a un evento di errore aumentano la complessità, il sovraccarico amministrativo e i costi.

La decisione di selezionare un pattern o una strategia di RP deve essere basata su 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 dell'implementazione di un sistema di DR. 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 gestire sistemi di riserva in un secondo data center in un'altra regione. Un approccio più economico, tuttavia, è utilizzare un ambiente di calcolo basato su cloud pubblico per il 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 consente di disattivare parte dell'infrastruttura di RP 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'utilizzo del cloud come ambiente di failover o di recupero in caso di disastro per 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 DR 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.

La valutazione di un piano di ripristino dei dati su più cloud rispetto all'utilizzo di un fornitore di cloud con regioni diverse richiede un'analisi approfondita di diversi fattori, tra cui:

• Gestibilità
• Sicurezza
• Fattibilità complessiva.
• Costo
  • I potenziali costi di trasferimento di 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 il costo della 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, l'utilizzo di un secondo provider cloud che si trovi anche nel tuo paese come DR può essere un'opzione. L'utilizzo di un secondo provider cloud presuppone che non sia possibile utilizzare un ambiente on-premise per creare una configurazione ibrida. Per evitare di riprogettare la tua soluzione cloud, idealmente il secondo provider cloud dovrebbe offrire tutte le funzionalità e i servizi necessari in-region.

Note sul layout

• Aspettative relative al DR: gli obiettivi RPO e RTO che la tua attività vuole raggiungere devono guidare l'architettura di DR e la pianificazione della creazione.
• Architettura della soluzione: con questo pattern, devi replicare le funzioni e le funzionalità esistenti del tuo ambiente on-premise per soddisfare le tue aspettative di RP. Pertanto, devi valutare la fattibilità e la fattibilità del rehosting, del refactoring o della riprogettazione delle tue applicazioni per fornire le stesse funzioni e prestazioni (o più ottimizzate) nell'ambiente 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 Progettazione della zona di destinazione in Google Cloud.

• Richiesta di RE: per la progettazione e la procedura di RE, è importante rispondere alle seguenti domande:

  • Che cosa attiva 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 invocato il failover nell'ambiente di DR? 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?
  • Come viene reindirizzato il traffico all'ambiente di DR dopo il rilevamento dell'errore?

  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 aggiornamento alla procedura o alla soluzione tecnologica, esegui di nuovo i test.

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

Vantaggi

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

• Poiché Google Cloud ha molte regioni in tutto il mondo tra cui scegliere, puoi utilizzarlo per eseguire il backup o la replica dei dati su un altro sito all'interno dello stesso continente. Puoi anche eseguire il backup o la replica dei dati su un sito in un altro continente.
• Google Cloud offre la possibilità di archiviare i dati in Cloud Storage in un bucket a due o più regioni. I dati vengono archiviati in modo ridondante in almeno due regioni geografiche separate. I dati archiviati nei bucket dual-region e multi-region vengono replicati tra regioni geografiche utilizzando la replica predefinita.
  • I bucket a due regioni 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 multiregione 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ù economiche delle istanze VM in esecuzione. Ciò significa che puoi ridurre al minimo il costo della manutenzione dei sistemi in standby a freddo.
  • 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 ripristino dei dati 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 suGoogle 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 Google Cloud database gestito, come Cloud SQL, per un recupero più rapido con la replica continua dei dati. Puoi avviare VM Compute Engine da snapshot precreati per ridurre i costi durante le normali operazioni. Con questa configurazione e a seguito di un evento di errore, il DNS deve indicare l'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'intera procedura per invocare un piano di RE, eseguire il provisioning del carico di lavoro nel cloud e ripristinare il traffico può essere completata manualmente o automaticamente.

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

Best practice

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

• Crea un piano di ripristino di emergenza che documenti l'infrastruttura insieme alle procedure di failover e di recupero.
• Valuta le seguenti azioni in base all'analisi dell'impatto sull'attività e ai target RPO e RTO obbligatori identificati:
  • Decidi se eseguire il backup dei dati su Google Cloud è sufficiente o se devi prendere in considerazione un'altra strategia di RP (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 la possibilità di utilizzare il pattern di trasferimento quando esegui il backup solo 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 del cervello diviso. Se replichi i dati in modo bidirezionale tra ambienti, potresti essere esposto al problema di split-brain. Il problema di split-brain si verifica quando due ambienti che replicano i dati in modo bidirezionale perdono la comunicazione tra loro. Questa 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. Ciò può comportare modifiche in conflitto dei dati. Esistono due modi comuni per evitare il problema di split-brain:

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

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

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

• Assicurati che i sistemi CI/CD e i repository di artefatti non diventino un singolo punto di errore. 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 workload quando utilizzi sistemi di riserva. 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 DNS vengano propagate rapidamente configurando il DNS con un valore TTL ragionevolmente breve in modo da poter reindirizzare gli utenti ai sistemi di riserva in caso di emergenza.

• Seleziona i policy 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.

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

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

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

    Google Cloud offre una soluzione open source basata su octoDNS per aiutarti a configurare e gestire un ambiente con più provider DNS. Per ulteriori informazioni, consulta DNS pubblico multiprovider utilizzando 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ò guastarsi.

• Utilizza Cloud Load Balancing invece di bilanciatori del carico hardware per supportare alcuni scenari che si verificano quando si utilizza questo pattern di architettura. Le richieste dei client interni o le richieste dei client esterni possono essere reindirizzate all'ambiente principale o all'ambiente DR in base a metriche diverse, ad esempio la suddivisione del traffico in base al peso. 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ò contribuire a ottimizzare le prestazioni della connettività e potrebbe ridurre gli addebiti per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.

• Valuta la possibilità di utilizzare la 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 del piano di ripristino di emergenza per capire quanto facilmente l'applicazione può riprendersi da un evento di disastro rispetto al valore RTO target.

• 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 alla soluzione di connettività ibrida selezionata. Queste opzioni includono i tunnel VPN, la VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.

Modello di cloud bursting

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

Questo pattern di architettura si basa su un deployment ridondante delle applicazioni su più ambienti di calcolo. L'obiettivo è aumentare la capacità, la 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 esplosione del cloud è utilizzare un ambiente di computing privato per il carico di base ed eseguire esplosioni temporanee nel cloud quando hai bisogno di una capacità aggiuntiva.

Nel diagramma precedente, quando la capacità di dati è al limite in un ambiente privato on-premise, il sistema può acquisire capacità aggiuntiva da un ambienteGoogle Cloud se 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 non è necessario eseguire il provisioning eccessivo dell'infrastruttura. In alternativa, puoi utilizzare 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 in diversi ambienti che utilizzano infrastrutture diverse. Per maggiori informazioni, consulta la architettura di riferimento dell'ambiente ibrido GKE Enterprise.

Note sul layout

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

• Puoi instradare le richieste degli utenti in arrivo a un bilanciatore del carico in esecuzione nel data center esistente, in modo che distribuisca le richieste tra le risorse locali e cloud.

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

• Anziché 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. Utilizza questo bilanciatore del carico per instradare richieste dei client interni o richieste dei client esterni ai backend che si trovano sia on-premise sia in Google Cloud e che si basano su metriche diverse, come la suddivisione del traffico in base al peso. Inoltre, puoi scalare i backend in base alla capacità di gestione del bilanciamento del carico per i carichi di lavoro in Google Cloud. Per 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 prestazioni sono determinate dalle differenze nelle funzionalità di sicurezza dell'infrastruttura, nelle risorse di calcolo sottostanti o nell'infrastruttura di rete, nonché dalla vicinanza ai servizi dipendenti. 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.
  • Assicurati che le versioni dei carichi di lavoro siano coerenti e che le origini dati siano aggiornate.
  • Potresti dover aggiungere automazione per eseguire il provisioning dell'ambiente cloud e reindirizzare il traffico quando la domanda aumenta e il carico di lavoro cloud deve accettare le richieste dei client per la tua applicazione.

• Se intendi arrestare tutte le Google Cloud risorse durante periodi di domanda ridotta, 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 non sono disponibili risorse 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, come i criteri di routing DNS per la geolocalizzazione. Cloud DNS supporta anche i controlli di integrità per i bilanciatori del carico di rete passthrough interni e per i bilanciatori del carico delle applicazioni interni. In questo caso, puoi incorporarlo nella configurazione DNS ibrida complessiva basata su questo pattern.

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

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 che una pubblica, ciascuna con funzionalità uniche. L'approccio contribuisce inoltre a distribuire il carico del traffico tra gli ambienti.

Date queste considerazioni, l'esplosione del 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 del 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.
• Poiché non devi più mantenere una capacità in eccesso per soddisfare le richieste di picco, potresti essere in grado di aumentare l'utilizzo e la convenienza economica dei tuoi ambienti di calcolo privati.
• L'esplosione cloud ti consente di eseguire job batch in modo tempestivo senza dover eseguire il provisioning eccessivo delle risorse di calcolo.

Best practice

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

• Per assicurarti che i carichi di lavoro in esecuzione nel cloud possano accedere alle risorse nello stesso modo in cui i carichi di lavoro in esecuzione in un ambiente on-premise, utilizza il modello a maglia con il principio di accesso alla sicurezza con il privilegio minimo. 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 Google Cloud regione che si trovi geograficamente vicino al tuo ambiente di calcolo privato. Per maggiori informazioni, consulta Best practice per la scelta delle regioni di Compute Engine.
• Quando utilizzi l'esplosione del cloud solo per i carichi di lavoro batch, riduci la superficie di attacco per la sicurezza mantenendo tutte le risorse Google Cloud private. Non consentire l'accesso diretto da internet a queste risorse, anche se utilizzi il Google Cloud bilanciamento del carico esterno per fornire il punto di accesso 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 il design dei tuoi criteri DNS in modo permanente o quando hai bisogno di una capacità aggiuntiva utilizzando un altro ambiente durante i periodi di picco della domanda.
  • Puoi utilizzare i criteri di routing DNS per la geolocalizzazione per avere un endpoint DNS globale per i bilanciatori del carico regionali. Questa tattica ha molti casi d'uso per i criteri di routing DNS per la geolocalizzazione, incluse le applicazioni ibride che utilizzano Google Cloud insieme a un implementazione on-premise in cui 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 ai sistemi di riserva quando hai bisogno di una maggiore capacità utilizzando gli ambienti cloud.

• Per i job che non sono molto critici in termini di tempo e non archiviano i dati localmente, valuta la possibilità di utilizzare istanze VM spot, che sono notevolmente più economiche delle normali istanze VM. Un prerequisito, tuttavia, è che se il job della VM viene prelevato, il sistema deve essere in grado di riavviare automaticamente il job.

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

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

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

• 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 di capacità che possono verificarsi nelle applicazioni distribuite a livello globale.

• Autentica le persone che utilizzano i tuoi sistemi stabilendo un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro nei confini degli ambienti.

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

Modelli di architettura ibrida e multi-cloud: cosa succederà dopo

• 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ù sugli archetipi di deployment per le applicazioni cloud.
• Scopri come progettare ed eseguire il deployment di un'applicazione web di e-commerce utilizzando architetture diverse, tra cui un'applicazione web di e-commerce basata su microservizi che utilizza GKE e un'applicazione web dinamica basata su API serverless.

---

1. Per ulteriori informazioni sulle considerazioni specifiche per regione, consulta Geografia e regioni.  ↩