Le modèle d'architecture multicloud partitionné combine 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 de calcul optimal qui tient compte des facteurs 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ée.
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 de cloud public. Cette approche est également appelée architecture composite et est identique à celle du modèle d'architecture hybride à plusieurs niveaux. Toutefois, 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 provenant de plusieurs clouds. La deuxième approche consiste à déployer différentes applications dans différents environnements de cloud public. La liste non exhaustive suivante décrit certains des moteurs commerciaux de la deuxième approche :
- Intégrer complètement les applications hébergées dans des environnements cloud distincts lors d'un scénario de fusion et acquisition entre deux entreprises.
- Pour favoriser la flexibilité et répondre aux diverses préférences cloud 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 du cloud. Si une entreprise est tenue de 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 cet emplacement si son fournisseur de services cloud principal ne dispose pas d'une région cloud dans cet emplacement.
Avec le modèle d'architecture multicloud partitionné, vous pouvez, si vous le souhaitez, 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 Google Kubernetes Engine (GKE), vous pouvez concevoir et créer une solution pour résoudre la complexité multicloud avec des postures de gouvernance, d'opérations et de sécurité cohérentes. Pour en savoir plus, consultez GKE Multi-Cloud.
Comme mentionné précédemment, il peut y avoir des raisons commerciales et techniques de combiner Google Cloud avec un autre fournisseur de cloud et de partitionner les charges de travail dans ces environnements de cloud. Les solutions multicloud vous offrent la flexibilité nécessaire pour migrer, créer et optimiser la portabilité des applications dans des environnements multicloud, tout en minimisant la dépendance vis-à-vis d'un fournisseur et en vous aidant à répondre aux exigences réglementaires. Par exemple, vous pouvez connecter Google Cloud Oracle Cloud Infrastructure (OCI) pour créer une solution multicloud qui exploite les capacité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 à bande passante élevée entre Google Cloud et d'autres fournisseurs de services cloud compatibles. Vous pouvez ainsi concevoir et créer des solutions multicloud pour gérer un volume de trafic inter-cloud élevé.
Avantages
L'utilisation d'une architecture multicloud offre plusieurs avantages commerciaux et techniques, comme indiqué dans Facteurs, considérations, stratégie et approches. Il est toutefois essentiel de réaliser une évaluation détaillée de la faisabilité de chaque avantage potentiel. Votre évaluation doit tenir compte de tous les défis directs ou indirects associés, ou des éventuels obstacles, et de votre capacité à les surmonter efficacement. De plus, gardez à l'esprit que la croissance à long terme de vos applications ou services peut entraîner des complexités qui pourraient l'emporter sur les avantages initiaux.
Voici quelques avantages clés du modèle d'architecture multicloud partitionné :
Dans les scénarios où vous devez minimiser l'engagement auprès d'un seul fournisseur de services cloud, vous pouvez distribuer les applications sur plusieurs fournisseurs de services cloud. Par conséquent, vous pouvez réduire relativement le verrouillage fournisseur en ayant la possibilité de changer de forfait (dans une certaine mesure) entre vos fournisseurs de services cloud. Le cloud ouvert permet d'importer des fonctionnalités Google Cloud , comme GKE, dans différents emplacements physiques. En étendant les capacités Google Cloud sur site, dans plusieurs clouds publics et en périphérie, il offre flexibilité, 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 d'une 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 régions où le fournisseur de 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, dans lesquels les applications et les services des deux entreprises peuvent être hébergés dans différents environnements de 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 situations où la charge de travail spécifique est légalement ou réglementairement requise pour résider dans une région cloud spécifique, et où le fournisseur de 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 potentiellement 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 cela est possible et pris en charge par les applications.
- 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 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.
- En fonction de vos exigences commerciales et techniques spécifiques, envisagez d'utiliser le modèle d'architecture en maillage ou l'un des modèles de mise en réseau avec passerelle.
- Pour répondre à vos attentes en termes de disponibilité et de performances, concevez des systèmes offrant une haute disponibilité (HA) de bout en bout, une faible latence et des débits 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 connectivité, différentes options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, 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, pensez à utiliser les liaisons CDN Interconnect entre Google Cloud et les fournisseurs compatibles pour optimiser ce trafic et, potentiellement, son coût.
É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 Router le trafic vers un emplacement sur site ou un autre cloud.
- Si le volume de transfert de données sortantes de Google Cloudvers d'autres environnements est élevé, envisagez d'utiliser Cross-Cloud Interconnect.
Pour surmonter les incohérences dans les protocoles, les API et les mécanismes d'authentification entre différents backends, nous vous recommandons, le cas échéant, de déployer une passerelle ou un proxy API en tant que façade unifiée. 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 de 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 de niveau entreprise dans des environnements sur site, en périphérie, dans d'autres clouds et dans des environnementsGoogle Cloud .
Dans certains des cas suivants, l'utilisation de Cloud Load Balancing avec une passerelle API 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éployer un basculement multirégional pour les runtimes d'API Apigee dans différentes régions.
Améliorer les performances avec Cloud CDN
Protection WAF et DDoS via Google Cloud Armor.
Utilisez des outils cohérents pour la journalisation et la surveillance dans les environnements cloud, dans la mesure du possible. Vous pouvez envisager d'utiliser des systèmes de surveillance Open Source. Pour en savoir plus, consultez Modèles de surveillance et de journalisation hybrides et multicloud.
Si vous déployez des composants d'application de manière distribuée, où les composants d'une même application sont déployés dans plusieurs environnements cloud, consultez les bonnes pratiques pour le modèle d'architecture hybride par tranche.