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 multiregionale o cloud 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 i vincoli 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 nei confronti di un singolo fornitore cloud, puoi distribuire le applicazioni su più fornitori cloud. Di conseguenza, potresti ridurre relativamente il vincolo del fornitore con la possibilità di cambiare i piani (in una certa misura) 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 una 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 regolamentato è necessario che si trovi 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.