Il modello di architettura multi-cloud partizionato combina più ambienti cloud pubblici gestiti da diversi provider di servizi cloud. Questa architettura offre la flessibilità necessaria per eseguire il deployment di un'applicazione in un ambiente di computing ottimale che tiene conto dei driver multi-cloud e delle considerazioni discusse nella prima parte di questa serie.
Il seguente diagramma mostra un pattern di architettura multi-cloud partizionata.
Questo modello 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 è anche definito architettura composita ed è lo stesso dell'architettura ibrida a più livelli. Anziché utilizzare un ambiente on-premise con un cloud pubblico, utilizza almeno due ambienti cloud. In un'architettura composita, un singolo carico di lavoro o applicazione utilizza componenti di più cloud. Il secondo approccio esegue il deployment di diverse applicazioni in diversi ambienticloud pubblicoi. Il seguente elenco non esaustivo descrive alcuni dei fattori che influiscono sul secondo approccio:
- Integrare completamente le applicazioni ospitate in ambienti cloud disparati durante uno scenario di fusione e acquisizione tra due aziende.
- Per promuovere la flessibilità e soddisfare le diverse preferenze del 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.
- Operare in un deployment multiregionale o globale. Se un'azienda è tenuta a ottemperare alle normative sulla residenza dei dati in regioni o paesi specifici, deve scegliere tra i cloud provider disponibili in quella località se il suo cloud provider principale non dispone di una regione cloud in quella località.
Con il pattern di architettura multi-cloud partizionata, puoi facoltativamente mantenere la capacità di spostare i carichi di lavoro in base alle esigenze da un ambiente cloud pubblico a un altro. In questo caso, la portabilità dei carichi di lavoro diventa un requisito chiave. Quando esegui il deployment dei carichi di lavoro in più ambienti di computing e vuoi mantenere la capacità di spostare i carichi di lavoro 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à multi-cloud con governance, operazioni e posizioni di sicurezza coerenti. Per ulteriori informazioni, consulta GKE Multi-Cloud.
Come accennato in precedenza, in alcune situazioni potrebbero esserci motivi sia aziendali che tecnici per combinare Google Cloud con un altro cloud provider e per partizionare i carichi di lavoro tra questi ambienti cloud. Le soluzioni multi-cloud ti offrono la flessibilità necessaria per eseguire la migrazione, creare e ottimizzare la portabilità delle applicazioni in ambienti multi-cloud, riducendo al minimo i vincoli e aiutandoti a soddisfare i requisiti normativi. Ad esempio, potresti connettere Google Cloud a Oracle Cloud Infrastructure (OCI) per creare una soluzione multi-cloud che sfrutti le funzionalità di ogni piattaforma utilizzando una connessione Cloud Interconnect privata per combinare componenti in esecuzione in OCI con risorse in esecuzione su Google Cloud. Per ulteriori informazioni, consulta Google Cloud e Oracle Cloud Infrastructure: sfruttare al meglio il multi-cloud. Inoltre, Cross-Cloud Interconnect facilita la connettività dedicata a elevata larghezza di banda tra Google Cloud e altri provider di servizi cloud supportati, consentendoti di progettare e creare soluzioni multi-cloud per gestire volumi di traffico inter-cloud elevati.
Vantaggi
Sebbene l'utilizzo di un'architettura multi-cloud offra numerosi vantaggi aziendali e tecnici, come discusso in Driver, considerazioni, strategia e approcci, è essenziale eseguire una valutazione dettagliata di fattibilità di ciascun potenziale vantaggio. La valutazione deve considerare attentamente eventuali sfide o potenziali ostacoli, diretti o indiretti, e la tua capacità di gestirli in modo efficace. Inoltre, considera 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 multi-cloud partizionata:
Negli scenari in cui potresti dover ridurre al minimo l'impegno con un singolo cloud provider, puoi distribuire le applicazioni su più cloud provider. Di conseguenza, potresti ridurre relativamente i vincoli al fornitore con la possibilità di cambiare i piani (in una certa misura) tra i tuoi cloud provider. Cloud aperto aiuta a portare le funzionalità di Google Cloud, come GKE Enterprise, in diversi luoghi fisici. Estendendo le funzionalità di Google Cloud on-premise, in più cloud pubblici e a livello perimetrale, offre flessibilità, agilità e favorisce la trasformazione.
Per motivi normativi, puoi gestire un determinato segmento della tua base utenti e dei dati di un paese in cui Google Cloud non ha una regione cloud.
Il pattern di architettura multi-cloud partizionato può aiutare a ridurre la latenza e a migliorare la qualità complessiva dell'esperienza utente in località in cui il cloud provider principale non dispone di una regione cloud o di un punto di presenza. Questo pattern è particolarmente utile quando si utilizza una connettività multi-cloud ad alta capacità e a bassa latenza, come Cross-Cloud Interconnect e CDN Interconnect con una rete 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 modello di architettura multi-cloud partizionato può aiutare a facilitare e accelerare scenari di fusione e acquisizione, in cui le applicazioni e i servizi delle due aziende potrebbero essere ospitati in diversi ambienti cloud pubblico.
Best practice
- Per iniziare, esegui il deployment di un carico di lavoro non mission critical. Questo deployment iniziale nel cloud secondario può quindi fungere da pattern per i deployment o le migrazioni futuri. Tuttavia, questo approccio probabilmente non è applicabile in situazioni in cui il carico di lavoro specifico è legalmente o regolamentato richiesto di risiedere in una specifica regione cloud e il cloud provider 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 è gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni, diminuire la disponibilità complessiva e comportare costi aggiuntivi per il trasferimento di dati in uscita.
- Per astrarre le differenze tra gli ambienti, valuta l'uso dei container e di Kubernetes, laddove supportato dalle applicazioni.
- Assicurati che le pipeline CI/CD e gli strumenti per il deployment e il monitoraggio siano coerenti in tutti gli ambienti cloud.
- Seleziona il pattern di architettura di rete ottimale che fornisca la soluzione di comunicazione più efficiente ed efficace per le applicazioni in uso.
- La comunicazione deve essere capillare e controllata. Usa API sicure per esporre i componenti dell'applicazione.
- Potresti utilizzare il pattern di architettura mesh o uno dei pattern di networking gated, in base ai tuoi requisiti aziendali e tecnici specifici.
- Per soddisfare le tue aspettative di disponibilità e prestazioni, progetta per l'alta disponibilità end-to-end, la bassa latenza e i livelli di velocità effettiva appropriati.
Per proteggere le informazioni sensibili, consigliamo di criptare tutte le comunicazioni in transito.
- Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni a seconda della 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 come parte del tuo pattern di architettura partizionata multi-cloud e stai compilando l'altra rete CDN con file di dati di grandi dimensioni di Google Cloud, valuta la possibilità di utilizzare i collegamenti CDN Interconnect tra Google Cloud e i provider supportati per ottimizzare il traffico e, potenzialmente, i relativi costi.
Estendi la tua soluzione di gestione delle identità tra gli ambienti in modo che i sistemi possano eseguire l'autenticazione in modo sicuro oltre i confini degli ambienti.
Per bilanciare efficacemente le richieste tra Google Cloud e un'altra piattaforma cloud, puoi utilizzare Cloud Load Balancing. Per ulteriori informazioni, consulta Routing del 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 risolvere incoerenze nei protocolli, nelle API e nei meccanismi di autenticazione tra backend diversi, consigliamo, ove applicabile, di eseguire il deployment di un gateway API o di un proxy come facciata unificata. Questo gateway o proxy agisce come punto di controllo centralizzato ed esegue le seguenti misure:
- Implementa misure di sicurezza aggiuntive.
- Protegge le app client e altri servizi dalle modifiche al codice del backend.
- Facilita gli audit trail per la comunicazione tra tutte le applicazioni cross-environment e i relativi componenti disaccoppiati.
- Funge da livello di comunicazione intermedio tra servizi legacy e modernizzati.
- Apigee e Apigee ibridi consentono di ospitare e gestire gateway di livello enterprise e ibridi in ambienti on-premise, in ambienti perimetrali, in altri cloud e in ambienti Google Cloud.
In alcuni dei casi seguenti, l'utilizzo di Cloud Load Balancing con un gateway API può fornire una soluzione solida e sicura per la gestione, la protezione e la distribuzione del traffico API su larga scala in più regioni:
- Il deployment del failover in più regioni per i runtime dell'API Apigee in regioni diverse.
Aumento delle prestazioni con Cloud CDN.
Protezione WAF e DDoS tramite Google Cloud Armor.
Se possibile, utilizza strumenti coerenti per il logging e il monitoraggio in diversi ambienti cloud. Potresti usare sistemi di monitoraggio open source. Per ulteriori informazioni, consulta Pattern di monitoraggio e logging ibridi e multi-cloud.
Se esegui il deployment dei componenti dell'applicazione in modo distribuito, in cui i componenti di una singola applicazione vengono distribuiti in più ambienti cloud, consulta le best practice per il modello di architettura ibrida a livelli.