Il pattern di architettura multi-cloud partizionato combina più ambienti cloud pubblici gestiti da diversi fornitori di servizi cloud. Questa architettura offre la flessibilità di eseguire il deployment di un'applicazione in un ambiente di computing ottimale che tiene conto dei fattori e delle considerazioni multicloud discussi nella prima parte di questa serie.
Il seguente diagramma mostra un pattern di architettura multicloud partizionata.
Questo pattern di architettura può essere creato in due modi diversi. Il primo approccio si basa sul deployment dei componenti dell'applicazione in diversi ambienticloud pubblicoi. Questo approccio è anche noto come architettura composita ed è lo stesso dell'pattern di architettura ibrida a più livelli. Anziché utilizzare un ambiente on-premise con un cloud pubblico, utilizza almeno due ambienti cloud. In un'architettura composita, un singolo carico di lavoro o applicazione utilizza componenti di più cloud. Il secondo approccio esegue il deployment di applicazioni diverse in ambienti cloud pubblico diversi. Il seguente elenco non esaustivo descrive alcuni dei fattori aziendali del secondo approccio:
- Per integrare completamente le applicazioni ospitate in ambienti cloud diversi durante uno scenario di fusione e acquisizione tra due aziende.
- Per promuovere la flessibilità e soddisfare le diverse preferenze cloud all'interno della tua organizzazione. Adotta questo approccio per incoraggiare le unità organizzative a scegliere il cloud provider più adatto alle loro esigenze e preferenze specifiche.
- Per operare in un deployment multi-regionale o globale del cloud. Se un'impresa è tenuta a rispettare le normative sulla residenza dei dati in regioni o paesi specifici, deve scegliere tra i fornitori di servizi cloud disponibili in quella località se il suo fornitore di servizi cloud principale non dispone di una regione cloud in quella località.
Con il pattern di architettura multi-cloud partizionata, puoi, se vuoi, mantenere la possibilità di spostare i carichi di lavoro in base alle esigenze da un ambiente cloud pubblico a un altro. In questo caso, la portabilità dei carichi di lavoro diventa un requisito fondamentale. Quando esegui il deployment dei carichi di lavoro in più ambienti di computing e vuoi mantenere la possibilità di spostarli tra gli ambienti, devi astrarre le differenze tra gli ambienti. Utilizzando Google Kubernetes Engine (GKE), puoi progettare e creare una soluzione per risolvere la complessità multicloud con governance, operazioni e sicurezza coerenti. Per maggiori informazioni, consulta GKE Multi-Cloud.
Come accennato in precedenza, in alcune situazioni potrebbero esserci motivi aziendali e tecnici per combinare Google Cloud con un altro provider cloud e per partizionare i carichi di lavoro in questi ambienti cloud. Le soluzioni multi-cloud ti offrono la flessibilità necessaria per eseguire la migrazione, creare e ottimizzare la portabilità delle applicazioni in ambienti multi-cloud, riducendo al minimo i vincoli e aiutandoti a soddisfare i requisiti normativi. Ad esempio, potresti connetterti Google Cloud a Oracle Cloud Infrastructure (OCI) per creare una soluzione multi-cloud che sfrutti le funzionalità di ogni piattaforma utilizzando un'Cloud Interconnect privata per combinare i componenti in esecuzione in OCI con le risorse in esecuzione su Google Cloud. Per saperne di più, consulta Google Cloud e Oracle Cloud Infrastructure: sfruttare al meglio il multicloud. 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 multicloud per gestire volumi elevati di traffico inter-cloud.
Vantaggi
L'utilizzo di un'architettura multicloud offre diversi vantaggi aziendali e tecnici, come illustrato in Fattori, considerazioni, strategia e approcci. È essenziale eseguire una valutazione dettagliata della fattibilità di ogni potenziale vantaggio. La tua valutazione deve prendere in considerazione attentamente eventuali sfide dirette o indirette associate o potenziali ostacoli e la tua capacità di superarli in modo efficace. Inoltre, tieni presente che la crescita a lungo termine delle tue applicazioni o dei tuoi servizi può introdurre complessità che potrebbero superare i vantaggi iniziali.
Ecco alcuni vantaggi chiave del pattern di architettura multicloud partizionata:
Negli scenari in cui potresti dover ridurre al minimo l'impegno con un singolo provider cloud, puoi distribuire le applicazioni su più provider cloud. Di conseguenza, potresti ridurre relativamente il vendor lock-in con la possibilità di cambiare piano (in una certa misura) tra i tuoi provider cloud. Open Cloud consente di portare le funzionalità di Google Cloud , come GKE, in diverse posizioni fisiche. Estendendo Google Cloud le funzionalità on-premise, in più cloud pubblici e nell'edge, offre flessibilità, agilità e favorisce la trasformazione.
Per motivi normativi, puoi pubblicare un determinato segmento della tua base di utenti e dei tuoi dati da un paese in cui Google Cloud non dispone di una regione cloud.
Il pattern di architettura multi-cloud partizionato può contribuire a ridurre la latenza e migliorare la qualità complessiva dell'esperienza utente nelle località in cui il fornitore di servizi cloud principale non dispone di una regione cloud o di un point of presence. Questo pattern è particolarmente utile quando si utilizza la connettività multicloud a bassa latenza e ad alta capacità, ad esempio Cross-Cloud Interconnect e CDN Interconnect con una CDN distribuita.
Puoi eseguire il deployment delle applicazioni su più cloud provider in modo da scegliere tra i migliori servizi offerti dagli altri cloud provider.
Il pattern di architettura multicloud partizionato può contribuire a facilitare e accelerare gli scenari di fusione e acquisizione, in cui le applicazioni e i servizi delle due aziende potrebbero essere ospitati in ambienti cloud pubblico diversi.
Best practice
- Inizia eseguendo il deployment di un workload non mission critical. Questo deployment iniziale nel cloud secondario può quindi fungere da modello per deployment o migrazioni futuri. Tuttavia, questo approccio probabilmente non è applicabile in situazioni in cui è richiesto per legge o per regolamento che il workload specifico risieda in una regione cloud specifica e il provider cloud principale non disponga di una regione nel territorio richiesto.
- Riduci al minimo le dipendenze tra i sistemi in esecuzione in ambienti cloud pubblico diversi, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni, ridurre la disponibilità complessiva e potenzialmente comportare costi aggiuntivi per il trasferimento di dati in uscita.
- Per astrarre le differenze tra gli ambienti, valuta la possibilità di utilizzare container e Kubernetes, se supportati dalle applicazioni e fattibili.
- Assicurati che le pipeline CI/CD e gli strumenti per il deployment e il monitoraggio siano coerenti in tutti gli ambienti cloud.
- Seleziona il pattern di architettura di rete ottimale che fornisca la soluzione di comunicazione più efficiente ed efficace per le applicazioni che utilizzi.
- La comunicazione deve essere granulare e controllata. Utilizza API sicure per esporre i componenti dell'applicazione.
- Prendi in considerazione l'utilizzo del pattern di architettura a rete o di uno dei pattern di rete controllata, in base ai tuoi requisiti aziendali e tecnici specifici.
- Per soddisfare le tue aspettative di disponibilità e prestazioni, progetta un'alta disponibilità (HA) end-to-end, una bassa latenza e livelli di throughput appropriati.
Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito.
- Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cross-Cloud Interconnect.
Se utilizzi più CDN nell'ambito del pattern di architettura partizionata multicloud e stai compilando l'altra CDN con file di dati di grandi dimensioni da Google Cloud, valuta la possibilità di utilizzare i link CDN Interconnect tra Google Cloud e i provider supportati per ottimizzare questo traffico e, potenzialmente, il 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 dell'ambiente.
Per bilanciare in modo efficace le richieste tra Google Cloud e un'altra piattaforma cloud, puoi utilizzare Cloud Load Balancing. Per saperne di più, vedi Routing del traffico a una posizione on-premise o a un altro cloud.
- Se il volume di trasferimento dei dati in uscita da Google Cloud verso altri ambienti è elevato, valuta la possibilità di utilizzare Cross-Cloud Interconnect.
Per superare le incoerenze nei protocolli, nelle API e nei meccanismi di autenticazione nei 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 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 i servizi legacy e quelli modernizzati.
- Apigee e Apigee hybrid ti consentono di ospitare e gestire gateway ibridi e di livello aziendale in ambienti on-premise, edge, altri cloud e ambientiGoogle Cloud .
In alcuni dei seguenti casi, l'utilizzo di Cloud Load Balancing con un gateway API può fornire una soluzione solida e sicura per gestire, proteggere e distribuire il traffico API su larga scala in più regioni:
- Deployment del failover multiregionale per i runtime API Apigee in regioni diverse.
Aumentare le prestazioni con Cloud CDN.
Fornisce WAF e protezione DDoS tramite Google Cloud Armor.
Se possibile, utilizza strumenti coerenti per il logging e il monitoraggio in tutti gli ambienti cloud. Potresti prendere in considerazione l'utilizzo di sistemi di monitoraggio open source. Per saperne di più, consulta la pagina Pattern di logging e monitoraggio per cloud ibrido e multi-cloud.
Se esegui il deployment dei componenti dell'applicazione in modo distribuito, ovvero se i componenti di una singola applicazione vengono implementati in più di un ambiente cloud, consulta le best practice per il pattern di architettura ibrida a livelli.