Le modèle d'architecture multicloud partitionné associe plusieurs environnements de cloud public exploités par différents fournisseurs de services cloud. Cette architecture offre la flexibilité nécessaire pour déployer une application dans un environnement IT optimal qui tient compte des moteurs et des considérations multicloud abordés dans la première partie de cette série.
Le diagramme suivant illustre un modèle d'architecture multicloud partitionné.
Ce modèle d'architecture peut être créé de deux manières différentes. La première approche consiste à déployer les composants de l'application dans différents environnements cloud public. Cette approche est également appelée architecture composite. Il s'agit de la même approche que le schéma d'architecture hybride à niveaux. Cependant, au lieu d'utiliser un environnement sur site avec un cloud public, il utilise au moins deux environnements cloud. Dans une architecture composite, une seule charge de travail ou application utilise des composants de plusieurs clouds. La deuxième approche consiste à déployer différentes applications dans différents environnements cloud public. La liste suivante, non exhaustive, décrit certains des moteurs d'activité de la deuxième approche:
- Intégrer complètement les applications hébergées dans des environnements cloud distincts lors d'une fusion-acquisition entre deux entreprises.
- Pour promouvoir la flexibilité et répondre aux différentes préférences cloud au sein de votre organisation. Adoptez cette approche pour encourager les unités organisationnelles à choisir le fournisseur de services cloud qui répond le mieux à leurs besoins et préférences spécifiques.
- Pour fonctionner dans un déploiement multirégional ou mondial Si une entreprise doit respecter les réglementations sur la résidence des données dans des régions ou des pays spécifiques, elle doit choisir parmi les fournisseurs de services cloud disponibles dans ces régions si son fournisseur de services cloud principal ne dispose pas d'une région cloud dans ces pays.
Avec le modèle d'architecture multicloud partitionné, vous pouvez conserver la possibilité de déplacer les charges de travail d'un environnement cloud public à un autre selon les besoins. Dans ce cas, la portabilité de vos charges de travail devient une exigence clé. Lorsque vous déployez des charges de travail dans plusieurs environnements informatiques et que vous souhaitez conserver la possibilité de les déplacer, vous devez éliminer les différences entre les environnements. En utilisant GKE Enterprise, vous pouvez concevoir et créer une solution pour résoudre la complexité du multicloud avec des postures de gouvernance, d'opérations et de sécurité cohérentes. Pour en savoir plus, consultez la page Multicloud GKE.
Comme indiqué précédemment, il peut y avoir des raisons commerciales et techniques de combiner Google Cloud avec un autre fournisseur cloud et de partitionner les charges de travail dans ces environnements cloud. Les solutions multicloud vous permettent de migrer, de créer et d'optimiser la portabilité des applications dans des environnements multicloud tout en réduisant la dépendance vis-à-vis d'un fournisseur et en vous aidant à respecter vos exigences réglementaires. Par exemple, vous pouvez connecter Google Cloud à Oracle Cloud Infrastructure (OCI) pour créer une solution multicloud qui exploite les fonctionnalités de chaque plate-forme à l'aide d'un Cloud Interconnect privé afin de combiner les composants exécutés dans OCI avec les ressources exécutées sur Google Cloud. Pour en savoir plus, consultez Google Cloud et Oracle Cloud Infrastructure : exploiter tout le potentiel du multicloud. De plus, Cross-Cloud Interconnect facilite la connectivité dédiée à haut débit entre Google Cloud et d'autres fournisseurs de services cloud compatibles, ce qui vous permet de concevoir et de créer des solutions multicloud pour gérer un volume de trafic inter-cloud élevé.
Avantages
Bien que l'utilisation d'une architecture multicloud offre plusieurs avantages commerciaux et techniques, comme indiqué dans la section Facteurs, considérations, stratégie et approches, il est essentiel d'effectuer une évaluation détaillée de la faisabilité de chaque avantage potentiel. Votre évaluation doit tenir compte de tous les défis ou obstacles potentiels directs ou indirects associés, ainsi que de votre capacité à les gérer efficacement. N'oubliez pas non plus que la croissance à long terme de vos applications ou services peut entraîner des complexités qui peuvent l'emporter sur les avantages initiaux.
Voici quelques avantages clés du modèle d'architecture multicloud partitionné:
Dans les cas où vous devez minimiser l'engagement auprès d'un seul fournisseur cloud, vous pouvez distribuer des applications entre plusieurs fournisseurs cloud. Vous pouvez ainsi réduire relativement l'enfermement par le fournisseur en ayant la possibilité de modifier les forfaits (dans une certaine mesure) entre vos fournisseurs de services cloud. Le cloud ouvert permet d'importer les fonctionnalités Google Cloud, comme GKE Enterprise, dans différents emplacements physiques. En étendant les fonctionnalités de Google Cloud sur site, dans plusieurs clouds publics et en périphérie, il offre flexibilité et agilité, et favorise la transformation.
Pour des raisons réglementaires, vous pouvez fournir des services à un certain segment de votre base d'utilisateurs et diffuser des données depuis un pays où Google Cloud ne dispose pas de région cloud.
Le modèle d'architecture multicloud partitionné peut aider à réduire la latence et à améliorer la qualité globale de l'expérience utilisateur dans les zones où le fournisseur de services cloud principal ne dispose pas de région cloud ni de point de présence. Ce modèle est particulièrement utile lorsque vous utilisez une connectivité multicloud à haute capacité et à faible latence, comme Cross-Cloud Interconnect et CDN Interconnect avec un CDN distribué.
Vous pouvez déployer des applications auprès de plusieurs fournisseurs cloud, d'une manière qui vous permet de choisir parmi les meilleurs services offerts par les différents fournisseurs.
Le modèle d'architecture multicloud partitionné peut faciliter et accélérer les scénarios de fusion et d'acquisition, où les applications et les services des deux entreprises peuvent être hébergés dans différents environnements cloud public.
Bonnes pratiques
- Commencez par déployer une charge de travail non critique. Ce déploiement initial dans le cloud secondaire peut ensuite servir de modèle pour les futurs déploiements ou migrations. Toutefois, cette approche n'est probablement pas applicable dans les cas où la charge de travail spécifique doit légalement ou réglementairement résider dans une région cloud spécifique, et que le fournisseur cloud principal ne dispose pas d'une région dans le territoire requis.
- Minimisez les dépendances entre les systèmes exécutés dans différents environnements de cloud public, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances, réduire la disponibilité globale et entraîner des frais de transfert de données sortantes supplémentaires.
- Pour éliminer les différences entre les environnements, envisagez d'utiliser des conteneurs et Kubernetes lorsque les applications le permettent et que cela est possible.
- Assurez-vous que les pipelines CI/CD et les outils de déploiement et de surveillance sont cohérents dans l'ensemble des environnements cloud.
- Sélectionnez le modèle d'architecture réseau optimal qui fournit la solution de communication la plus efficace et la plus efficace pour les applications que vous utilisez.
- La communication doit être précise et contrôlée. Utilisez des API sécurisées pour exposer les composants de l'application.
- Envisagez d'utiliser le modèle d'architecture en réseau maillé ou l'un des modèles de réseau avec passerelle, en fonction de vos exigences commerciales et techniques spécifiques.
- Pour répondre à vos attentes en termes de disponibilité et de performances, concevez une solution offrant une haute disponibilité (HA) de bout en bout, une faible latence et des niveaux de débit appropriés.
Pour protéger les informations sensibles, nous vous recommandons de chiffrer toutes les communications en transit.
- Si le chiffrement est requis au niveau de la couche de connectivité, plusieurs options sont disponibles, en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, le VPN haute disponibilité sur Cloud Interconnect et MACsec pour Cross-Cloud Interconnect.
Si vous utilisez plusieurs CDN dans le cadre de votre modèle d'architecture partitionnée multicloud et que vous insérez des fichiers de données volumineux dans votre autre CDN à partir de Google Cloud, envisagez d'utiliser les liaisons CDN Interconnect entre Google Cloud et les fournisseurs compatibles pour optimiser ce trafic et, potentiellement, ses coûts.
Étendez votre solution de gestion des identités entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.
Pour équilibrer efficacement les requêtes entre Google Cloud et une autre plate-forme cloud, vous pouvez utiliser Cloud Load Balancing. Pour en savoir plus, consultez la section Router le trafic vers un emplacement sur site ou un autre cloud.
- Si le volume de transfert de données sortant de Google Cloud vers d'autres environnements est élevé, envisagez d'utiliser Cross-Cloud Interconnect.
Pour remédier aux incohérences entre les protocoles, les API et les mécanismes d'authentification dans les différents backends, nous vous recommandons, le cas échéant, de déployer une passerelle API ou un proxy en tant que façade unificatrice. Cette passerelle ou ce proxy sert de point de contrôle centralisé et effectue les mesures suivantes:
- Implémente des mesures de sécurité supplémentaires.
- Protège les applications clientes et les autres services contre les modifications du code backend.
- Facilite les journaux d'audit pour la communication entre toutes les applications multi-environnements et leurs composants découplés.
- Agit comme une couche de communication intermédiaire entre les services anciens et modernisés.
- Apigee et Apigee hybrid vous permettent d'héberger et de gérer des passerelles hybrides et pensées pour les entreprises dans des environnements sur site, Edge, d'autres clouds et des environnements Google Cloud.
Dans certains des cas suivants, l'utilisation de Cloud Load Balancing avec une API Gateway peut fournir une solution robuste et sécurisée pour gérer, sécuriser et distribuer le trafic API à grande échelle dans plusieurs régions:
- Déploiement d'un basculement multirégional pour les environnements d'exécution d'API Apigee dans différentes régions.
Améliorez les performances avec Cloud CDN.
Fournir une protection WAF et DDoS via Google Cloud Armor
Dans la mesure du possible, utilisez des outils cohérents pour la journalisation et la surveillance dans les environnements cloud. Vous pouvez envisager d'utiliser des systèmes de surveillance Open Source. Pour en savoir plus, consultez la section Modèles de surveillance et de journalisation hybrides et multicloud.
Si vous déployez des composants d'application de manière distribuée, c'est-à-dire que les composants d'une seule application sont déployés dans plusieurs environnements cloud, consultez les bonnes pratiques pour le modèle d'architecture hybride par tranche.