Modèles d'architecture hybride et multicloud

Last reviewed 2023-12-14 UTC

Cette page offre une vue d'une seule page de toutes les pages dans le cadre de Créer des architectures hybrides et multicloud à l'aide de Google Cloud. Vous pouvez imprimer cette page ou l'enregistrer au format PDF à l'aide de la fonction d'impression de votre navigateur et en sélectionnant l'option Enregistrer en tant que PDF. Cette page ne comporte pas de volet de table des matières sur le côté droit.

Il s'agit du deuxième d'une série de trois documents. Il présente les modèles courants d'architecture hybride et multicloud. Il décrit également les scénarios auxquels ces modèles sont les plus adaptés. Enfin, il fournit les bonnes pratiques que vous pouvez suivre lors du déploiement de telles architectures dans Google Cloud.

L'ensemble de documents sur les modèles d'architecture hybride et multicloud se compose des éléments suivants:

• Créez des architectures hybrides et multicloud: traite de la planification d'une stratégie de conception d'une configuration hybride et multicloud avec Google Cloud.
• Modèles d'architecture hybride et multicloud: présente les modèles d'architecture courants à adopter dans le cadre d'une stratégie hybride et multicloud (ce document).
• Modèles d'architecture réseau sécurisée hybride et multicloud : présente les modèles d'architecture réseau sécurisée hybride et multicloud du point de vue de la mise en réseau.

Chaque entreprise dispose d'un portefeuille unique de charges de travail d'application qui imposent des exigences et des contraintes à l'architecture d'une configuration hybride ou multicloud. Bien que vous deviez concevoir et adapter votre architecture pour répondre à ces contraintes et exigences, vous pouvez aussi vous appuyer sur certains modèles courants pour définir l'architecture de base.

Un modèle d'architecture est un moyen reproductible de structurer plusieurs composants fonctionnels d'une solution technologique, d'une application ou d'un service afin de créer une solution réutilisable répondant à certaines exigences ou cas d'utilisation. Une solution technologique basée sur le cloud est souvent composée de plusieurs services cloud distincts et distribués. Ces services collaborent pour fournir les fonctionnalités requises. Dans ce contexte, chaque service est considéré comme un composant fonctionnel de la solution technologique. De même, une application peut être composée de plusieurs niveaux, modules ou services fonctionnels, et chacun peut représenter un composant fonctionnel de l'architecture de l'application. Une telle architecture peut être standardisée pour répondre à des cas d'utilisation métier spécifiques et servir de modèle de base réutilisable.

Pour définir généralement un modèle d'architecture pour une application ou une solution, identifiez et définissez les éléments suivants:

• Composants de la solution ou de l'application
• Les fonctions attendues pour chaque composant (par exemple, les fonctions de frontend pour fournir une interface utilisateur graphique ou les fonctions de backend pour fournir un accès aux données).
• Comment les composants communiquent entre eux et avec des systèmes ou des utilisateurs externes Dans les applications modernes, ces composants interagissent via des interfaces ou des API bien définies. Il existe un large éventail de modèles de communication, tels que les modèles asynchrones et synchrones, les modèles de requête-réponse ou les modèles basés sur des files d'attente.

Voici les deux principales catégories de modèles d'architecture hybride et multicloud:

• Modèles d'architecture distribuée : ces modèles reposent sur un déploiement distribué de charges de travail ou de composants d'application. Cela signifie qu'ils exécutent une application (ou des composants spécifiques de cette application) dans l'environnement informatique qui convient le mieux au modèle. Cela permet au modèle de tirer parti des différentes propriétés et caractéristiques des environnements informatiques distribués et interconnectés.
• Modèles d'architecture redondants : ces modèles sont basés sur des déploiements redondants de charges de travail. Dans ces modèles, vous déployez les mêmes applications et leurs composants dans plusieurs environnements informatiques. L'objectif est d'augmenter la capacité de performances ou la résilience d'une application, ou de répliquer un environnement existant à des fins de développement et de test.

Lorsque vous implémentez le modèle d'architecture que vous avez sélectionné, vous devez utiliser un archétype de déploiement approprié. Les archétypes de déploiement sont zonaux, régionaux, multirégionaux ou mondiaux. Cette sélection constitue la base de la création d'architectures de déploiement spécifiques à l'application. Chaque archétype de déploiement définit une combinaison de domaines de défaillance dans lesquels une application peut fonctionner. Ces domaines de défaillance peuvent englober une ou plusieurs zones ou régions Google Cloud, et peuvent être étendus pour inclure vos centres de données sur site ou vos domaines de défaillance dans d'autres fournisseurs de services cloud.

Cette série comprend les pages suivantes:

• Modèles d'architecture distribuée

  • Modèle hybride par tranche

  • Modèle multicloud partitionné

  • Modèle analytique hybride et multicloud.

  • Modèle hybride de périphérie

• Modèles d'architecture redondants

  • Modèle d'environnement hybride
  • Modèles de continuité des opérations hybride et multicloud
  • Modèle d'utilisation temporaire du cloud

Contributeurs

Auteur : Marwan Al Shawi | Partner Customer Engineer

Autres contributeurs :

• Saud Albazei | Ingénieur client, modernisation des applications
• Anna Berenberg | Engineering Fellow
• Marco Ferrari | Architecte de solutions cloud
• Victor Moreno | Responsable produit, Mise en réseau cloud
• Johannes Passing | Architecte de solutions cloud
• Mark Schlagenhauf | Rédacteur technique, Mise en réseau
• Daniel Strebel | Responsable de la solution EMEA, modernisation des applications
• Ammett Williams | Ingénieur relations avec les développeurs

Modèles d'architecture distribuée

Lorsque vous passez d'un environnement IT non hybride ou non multicloud à une architecture hybride ou multicloud, commencez par examiner les contraintes de vos applications existantes et la manière dont elles peuvent entraîner une défaillance de l'application. Cette considération devient plus importante lorsque vos applications ou composants d'application fonctionnent de manière distribuée dans différents environnements. Après avoir pris en compte vos contraintes, élaborez un plan pour les éviter ou les surmonter. Veillez à prendre en compte les fonctionnalités uniques de chaque environnement informatique dans une architecture distribuée.

Remarque :Vous pouvez appliquer différents modèles d'architecture à différentes applications, en fonction de leurs cas d'utilisation et de leurs exigences. Cela signifie que vous pouvez avoir plusieurs applications fonctionnant simultanément avec différents modèles d'architecture hybride et multicloud.

Considérations de conception

Les considérations de conception suivantes s'appliquent aux modèles de déploiement distribués. En fonction de la solution cible et des objectifs métier, la priorité et l'impact de chaque considération peuvent varier.

Latence

Dans n'importe quel modèle d'architecture qui distribue des composants d'application (frontends, backends ou microservices) dans différents environnements informatiques, une latence de communication peut se produire. Cette latence est influencée par la connectivité réseau hybride (Cloud VPN et Cloud Interconnect) et la distance géographique entre le site sur site et les régions cloud, ou entre les régions cloud dans une configuration multicloud. Il est donc essentiel d'évaluer les exigences de latence de vos applications et leur sensibilité aux retards réseau. Les applications pouvant tolérer la latence sont plus adaptées au déploiement distribué initial dans un environnement hybride ou multicloud.

Architecture d'état temporaire par rapport à l'architecture d'état final

Pour spécifier les attentes et les implications potentielles en termes de coût, d'échelle et de performances, il est important d'analyser le type d'architecture dont vous avez besoin et la durée prévue lors de la phase de planification. Par exemple, si vous prévoyez d'utiliser une architecture hybride ou multicloud pendant une longue période ou de manière permanente, vous pouvez envisager d'utiliser Cloud Interconnect. Pour réduire les coûts de transfert de données sortants et optimiser les performances du réseau de connectivité hybride, Cloud Interconnect propose des remises sur les frais de transfert de données sortants qui répondent aux conditions de remise sur le débit de transfert de données.

Fiabilité

La fiabilité est un facteur important à prendre en compte lors de la conception de systèmes IT. La disponibilité de l'uptime est un aspect essentiel de la fiabilité du système. Dans Google Cloud, vous pouvez renforcer la résilience d'une application en déployant des composants redondants de cette application dans plusieurs zones d'une même région ou dans plusieurs régions, avec des fonctionnalités de basculement. La redondance est l'un des éléments clés pour améliorer la disponibilité globale d'une application. Pour les applications dont la configuration est distribuée dans des environnements hybrides et multicloud, il est important de maintenir un niveau de disponibilité cohérent.

Pour améliorer la disponibilité d'un système dans un environnement sur site ou dans d'autres environnements cloud, réfléchissez à la redondance matérielle ou logicielle (avec des mécanismes de basculement) dont vous avez besoin pour vos applications et leurs composants. Dans l'idéal, vous devez tenir compte de la disponibilité d'un service ou d'une application dans les différents composants et l'infrastructure de soutien (y compris la disponibilité de la connectivité hybride) dans tous les environnements. Ce concept est également appelé disponibilité composite d'une application ou d'un service.

En fonction des dépendances entre les composants ou les services, la disponibilité composite d'une application peut être supérieure ou inférieure à celle d'un service ou d'un composant individuel. Pour en savoir plus, consultez la section Disponibilité composite: calcul de la disponibilité globale de l'infrastructure cloud.

Pour atteindre le niveau de fiabilité système souhaité, définissez des métriques de fiabilité claires et concevez des applications capables de s'autoréparer et de résister efficacement aux perturbations dans les différents environnements. Pour vous aider à définir des méthodes appropriées pour mesurer l'expérience client de vos services, consultez Définir vos objectifs de fiabilité.

Connectivité hybride et multicloud

Les exigences de la communication entre les composants d'applications distribuées doivent influencer votre choix d'une option de connectivité réseau hybride. Chaque option de connectivité présente ses avantages et ses inconvénients, ainsi que des facteurs spécifiques à prendre en compte, tels que le coût, le volume de trafic, la sécurité, etc. Pour en savoir plus, consultez la section Considérations concernant la conception de la connectivité.

Gestion

Des outils de gestion et de surveillance cohérents et unifiés sont essentiels pour réussir les configurations hybrides et multicloud (avec ou sans portabilité des charges de travail). À court terme, ces outils peuvent ajouter des coûts de développement, de test et d'exploitation. Techniquement, plus vous utilisez de fournisseurs de services cloud, plus la gestion de vos environnements devient complexe. La plupart des fournisseurs de cloud public proposent non seulement des fonctionnalités différentes, mais aussi des outils, des contrats de niveau de service et des API variés pour gérer les services cloud. Par conséquent, comparez les avantages stratégiques de l'architecture que vous avez sélectionnée à la complexité potentielle à court terme et aux avantages à long terme.

Coût

Chaque fournisseur de services cloud dans un environnement multicloud dispose de ses propres métriques et outils de facturation. Pour améliorer la visibilité et obtenir des tableaux de bord unifiés, envisagez d'utiliser des outils de gestion et d'optimisation des coûts multicloud. Par exemple, lorsque vous créez des solutions cloud first dans plusieurs environnements cloud, les produits, les tarifs, les remises et les outils de gestion de chaque fournisseur peuvent créer des incohérences de coûts entre ces environnements.

Nous vous recommandons d'utiliser une méthode unique et bien définie pour calculer le coût total des ressources cloud et pour assurer la visibilité des coûts. La visibilité des coûts est essentielle pour l'optimisation des coûts. Par exemple, en combinant les données de facturation des fournisseurs de services cloud que vous utilisez et en utilisant le bloc de gestion des coûts cloud Looker de Google Cloud, vous pouvez créer une vue centralisée de vos coûts multicloud. Cette vue peut vous aider à obtenir une vue consolidée de vos dépenses dans plusieurs clouds. Pour en savoir plus, consultez la section Stratégie pour optimiser efficacement la gestion des coûts de facturation cloud.

Nous vous recommandons également d'utiliser les pratiques FinOps pour rendre les coûts visibles. Dans le cadre d'une pratique FinOps efficace, une équipe centrale peut déléguer la prise de décisions en matière d'optimisation des ressources à toutes les autres équipes impliquées dans un projet afin de favoriser la responsabilisation individuelle. Dans ce modèle, l'équipe centrale doit standardiser le processus, la génération des rapports et les outils d'optimisation des coûts. Pour en savoir plus sur les différents aspects et recommandations d'optimisation des coûts à prendre en compte, consultez le framework d'architecture Google Cloud: optimisation des coûts.

Transfert de données

Le transfert de données est un élément important à prendre en compte pour la stratégie et la planification de l'architecture hybride et multicloud, en particulier pour les systèmes distribués. Les entreprises doivent identifier leurs différents cas d'utilisation métier, les données qui les alimentent et la façon dont elles sont classées (pour les secteurs réglementés). Ils doivent également tenir compte de l'impact du stockage, du partage et de l'accès aux données pour les systèmes distribués dans les différents environnements sur les performances des applications et la cohérence des données. Ces facteurs peuvent influencer l'application et l'architecture du pipeline de données. L'ensemble complet d'options de transfert de données de Google Cloud permet aux entreprises de répondre à leurs besoins spécifiques et d'adopter des architectures hybrides et multicloud sans compromettre la simplicité, l'efficacité ni les performances.

Sécurité

Lorsque vous migrez des applications vers le cloud, il est important de prendre en compte les fonctionnalités de sécurité cloud first, telles que la cohérence, l'observabilité et la visibilité de la sécurité unifiée. Chaque fournisseur de cloud public a sa propre approche, ses bonnes pratiques et ses fonctionnalités de sécurité. Il est important d'analyser et d'aligner ces fonctionnalités pour créer une architecture de sécurité fonctionnelle et standard. Des contrôles IAM stricts, le chiffrement des données, l'analyse des failles et la conformité aux réglementations du secteur sont également des aspects importants de la sécurité cloud.

Lorsque vous planifiez une stratégie de migration, nous vous recommandons d'analyser les considérations mentionnées précédemment. Ils peuvent vous aider à réduire les risques d'introduire des complexités dans l'architecture à mesure que vos applications ou volumes de trafic augmentent. De plus, la conception et la création d'une zone de destination sont presque toujours une condition préalable au déploiement de charges de travail d'entreprise dans un environnement cloud. Une zone de destination aide votre entreprise à déployer, utiliser et faire évoluer des services cloud de manière plus sécurisée dans plusieurs domaines. Elle comprend différents éléments, tels que les identités, la gestion des ressources, la sécurité et la mise en réseau. Pour en savoir plus, consultez la section Conception de zone de destination dans Google Cloud.

Les documents suivants de cette série décrivent d'autres modèles d'architecture distribuée:

• Modèle hybride par tranche
• Modèle multicloud partitionné
• Modèle analytique hybride et multicloud
• Modèle hybride de périphérie

Modèle hybride par tranche

Les composants de l'architecture d'une application peuvent être classés en tant que frontend ou backend. Dans certains cas, ces composants peuvent être hébergés pour fonctionner à partir de différents environnements informatiques. Dans le modèle d'architecture hybride par tranche, les environnements informatiques sont situés dans un environnement informatique privé sur site et dans Google Cloud.

Les composants de l'application d'interface sont directement exposés aux utilisateurs finaux ou aux appareils. Par conséquent, ces applications sont souvent sensibles aux performances. Pour développer de nouvelles fonctionnalités et des améliorations, les mises à jour logicielles peuvent être fréquentes. Comme les applications frontales reposent généralement sur des applications backend pour stocker et gérer les données (et éventuellement la logique métier et le traitement des entrées utilisateur), elles sont souvent sans état ou ne gèrent que des volumes limités de données.

Pour qu'elles soient accessibles et utilisables, vous pouvez créer vos applications d'interface avec différents frameworks et technologies. Les performances de l'application, la vitesse de réponse et la compatibilité avec les navigateurs sont quelques-uns des facteurs clés d'une application d'interface réussie.

Les composants d'application backend sont généralement axés sur le stockage et la gestion des données. Dans certaines architectures, la logique métier peut être intégrée au composant backend. Les applications backend ont tendance à être mises à jour moins souvent que les applications d'interface. Les applications backend doivent gérer les défis suivants:

• Gérer un grand volume de requêtes
• Gérer un grand volume de données
• Sécuriser les données
• Gérer les données à jour sur tous les réplicas du système

L'architecture d'application à trois niveaux est l'une des implémentations les plus populaires pour créer des applications Web d'entreprise, comme des sites Web d'e-commerce contenant différents composants d'application. Cette architecture comprend les niveaux suivants. Chaque niveau fonctionne de manière indépendante, mais ils sont étroitement liés et fonctionnent tous ensemble.

• Interface Web et niveau de présentation
• Niveau d'application
• Niveau d'accès aux données ou niveau backend

Placer ces couches dans des conteneurs sépare leurs besoins techniques, comme les exigences de mise à l'échelle, et permet de les migrer de manière progressive. Cela permet également de les déployer sur des services cloud indépendants de la plate-forme, pouvant être portables entre différents environnements, d'utiliser la gestion automatisée et d'évoluer avec des plates-formes gérées dans le cloud telles que Cloud Run ou Google Kubernetes Engine (GKE) édition Enterprise De plus, les bases de données gérées par Google Cloud comme Cloud SQL permettent de fournir le backend en tant que couche de base de données.

Remarque : L'implémentation de cette architecture et la définition de ses composants peuvent varier selon que les niveaux sont séparés ou non en systèmes et en couches individuels ou combinés.

Le modèle d'architecture hybride par tranche consiste à déployer des composants d'application d'interface existants dans le cloud public. Dans ce modèle, vous conservez tous les composants d'application backend existants dans leur environnement informatique privé. En fonction de l'échelle et de la conception spécifique de l'application, vous pouvez migrer les composants d'application de premier plan au cas par cas. Pour en savoir plus, consultez la page Migrer vers Google Cloud.

Si vous disposez déjà d'une application avec des composants backend et d'interface hébergés dans votre environnement sur site, tenez compte des limites de votre architecture actuelle. Par exemple, à mesure que votre application évolue et que les exigences de ses performances et de sa fiabilité augmentent, vous devez commencer à évaluer si certaines parties de votre application doivent être refactorisées ou déplacées vers une autre architecture plus optimale. Le modèle d'architecture hybride par tranche vous permet de transférer certaines charges de travail et certains composants de votre application vers le cloud avant d'effectuer une transition complète. Il est également essentiel de tenir compte des coûts, du temps et des risques associés à une telle migration.

Le schéma suivant montre un modèle d'architecture hybride par tranche.

Dans le schéma précédent, les requêtes client sont envoyées à l'interface de l'application hébergée dans Google Cloud. À son tour, l'interface utilisateur de l'application renvoie les données à l'environnement sur site où le backend de l'application est hébergé (idéalement via une passerelle API).

Avec le modèle d'architecture hybride par tranche, vous pouvez exploiter l'infrastructure et les services mondiaux de Google Cloud, comme illustré dans l'exemple d'architecture du schéma suivant. L'interface de l'application est accessible via Google Cloud. Elle eut également ajouter de l'élasticité à l'interface en utilisant l'autoscaling pour répondre de manière dynamique et efficace à la demande de scaling sans provisionner l'infrastructure de manière excessive. Vous pouvez utiliser différentes architectures pour créer et exécuter des applications Web évolutives sur Google Cloud. Chaque architecture présente des avantages et des inconvénients pour différentes exigences.

Pour en savoir plus, regardez la vidéo Trois façons d'exécuter des applications Web évolutives sur Google Cloud sur YouTube. Pour en savoir plus sur les différentes façons de moderniser votre plate-forme d'e-commerce sur Google Cloud, consultez Créer une plate-forme de commerce numérique sur Google Cloud.

Dans le schéma précédent, l'interface de l'application est hébergée sur Google Cloud pour offrir une expérience utilisateur multirégionale et optimisée à l'échelle mondiale, qui utilise l'équilibrage de charge global, l'auto-scaling et la protection contre les attaques par déni de service via Google Cloud Armor.

Au fil du temps, le nombre d'applications que vous déployez dans le cloud public peut augmenter au point que vous pourriez envisager de transférer les composants d'application backend vers le cloud public. Si vous prévoyez de gérer un trafic important, opter pour des services gérés dans le cloud peut vous aider à économiser des efforts d'ingénierie lorsque vous gérez votre propre infrastructure. Envisagez cette option, sauf si des contraintes ou des exigences exigent l'hébergement des composants d'application backend sur site. Par exemple, si vos données backend sont soumises à des restrictions réglementaires, vous devrez probablement les conserver sur site. Toutefois, le cas échéant et conformément aux exigences de conformité, vous pouvez déplacer ces données à l'aide des fonctionnalités de protection des données sensibles telles que les techniques d'anonymisation lorsque cela est nécessaire.

Dans le modèle d'architecture hybride par tranche, vous pouvez également utiliser Google Distributed Cloud dans certains scénarios. Distributed Cloud vous permet d'exécuter des clusters Google Kubernetes Engine sur du matériel dédié fourni et géré par Google, indépendamment du centre de données Google Cloud. Pour vous assurer que le service Distributed Cloud répond à vos besoins actuels et futurs, soyez conscient des limites de ce service par rapport à une zone GKE traditionnelle dans le cloud.

Avantages

Le fait de se concentrer d'abord sur les applications d'interface présente plusieurs avantages, y compris les suivants:

• Les composants frontend dépendent des ressources backend et parfois d'autres composants frontend.
• Les composants backend ne dépendent pas des composants frontend. Par conséquent, l'isolement et la migration d'applications d'interface ont tendance à être moins complexes que la migration d'applications backend.
• Étant donné que les applications d'interface sont souvent sans état ou qu'elles ne gèrent pas les données elles-mêmes, elles ont tendance à être plus faciles à migrer que les backends.
  • Les composants d'interface peuvent être optimisés lors de la migration pour utiliser une architecture sans état. Pour en savoir plus, regardez la vidéo How to port stateful web apps to Cloud Run (Comment porter des applications Web stateful vers Cloud Run) sur YouTube.

Le déploiement d'applications d'interface existantes ou nouvellement développées dans le cloud public présente plusieurs avantages :

• De nombreuses applications d'interface sont soumises à des modifications fréquentes. Lorsque ces applications sont exécutées dans le cloud public, la configuration d'un processus d'intégration continue/de déploiement continu (CI/CD) est simplifiée. Vous pouvez utiliser l'intégration continue et le déploiement continu pour envoyer des mises à jour de manière efficace et automatisée. Pour en savoir plus, consultez la section CI/CD sur Google Cloud.
• Les interfaces sensibles aux performances avec une charge de trafic variable peuvent grandement bénéficier des fonctionnalités d'équilibrage de charge, de déploiement multirégional, de mise en cache Cloud CDN, de sans serveur et d'autoscaling offertes par un déploiement dans le cloud (idéalement avec une architecture sans état).

• L'adoption de microservices avec des conteneurs à l'aide d'une plate-forme gérée dans le cloud, comme GKE, vous permet d'utiliser des architectures modernes telles que le microfrontend, qui étendent les microservices aux composants de frontend.

  L'extension des microservices est couramment utilisée avec les interfaces frontales impliquant plusieurs équipes collaborant sur la même application. Ce type de structure d'équipe nécessite une approche itérative et une maintenance continue. Voici quelques-uns des avantages de l'utilisation de microfrontends:

  • Elle peut être transformée en modules de microservices indépendants pour le développement, les tests et le déploiement.
  • Elle permet aux équipes de développement individuelles de sélectionner leurs technologies et leur code préférés.
  • Il peut favoriser des cycles de développement et de déploiement rapides sans affecter le reste des composants de front-end pouvant être gérés par d'autres équipes.

• Qu'elles mettent en œuvre des interfaces utilisateur ou des API, ou qu'elles gèrent l'ingestion de données IoT (Internet des objets), les applications d'interface peuvent bénéficier des fonctionnalités de services cloud tels que Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine ou Cloud Run.

• Les proxys d'API gérés dans le cloud permettent de:

  • Dissocier l'API associée aux applications de vos services de backend, tels que les microservices.
  • Protéger les applications contre les modifications du code backend.
  • Compatibilité avec vos architectures de frontend basées sur des API existantes, comme le backend pour les interface (BFF), le microfrontend et d'autres.
  • Exposer vos API sur Google Cloud ou dans d'autres environnements en implémentant des proxys d'API sur Apigee.

Vous pouvez également appliquer le modèle hybride par tranche dans l'ordre inverse, en déployant des backends dans le cloud tout en conservant les interfaces dans des environnements informatiques privés. Bien qu'elle soit moins courante, cette approche est particulièrement adaptée à une interface lourde et monolithique. Dans ce cas, il pourrait être plus facile d'extraire les fonctionnalités de backend par itération et de déployer ces nouveaux backends dans le cloud.

La troisième partie de cette série présente les modèles de mise en réseau possibles pour permettre une telle architecture. Apigee hybrid est une plate-forme qui permet de créer et de gérer des proxys d'API dans un modèle de déploiement hybride. Pour en savoir plus, consultez la section Architecture à faible couplage, y compris les architectures monolithiques et de microservices à plusieurs niveaux.

Bonnes pratiques

Utilisez les informations de cette section pour planifier votre architecture hybride par tranche.

Bonnes pratiques pour réduire la complexité

Lorsque vous appliquez le modèle d'architecture hybride par tranche, tenez compte des bonnes pratiques suivantes qui peuvent vous aider à réduire son déploiement global et sa complexité opérationnelle:

• Sur la base de l'évaluation des modèles de communication des applications identifiées, sélectionnez la solution de communication la plus efficace et la plus efficace pour ces applications.

Comme la plupart des interactions utilisateur impliquent des systèmes connectés à travers plusieurs environnements informatiques, une connectivité rapide et à faible latence entre ces systèmes est importante. Pour répondre aux attentes en termes de disponibilité et de performances, vous devez concevoir des systèmes offrant une haute disponibilité, une faible latence et des débits appropriés. Du point de vue de la sécurité, la communication doit être précise et contrôlée. Idéalement, vous devez exposer les composants de l'application à l'aide d'API sécurisées. Pour en savoir plus, consultez la section Sortie contrôlée.

• Pour minimiser la latence de communication entre les environnements, sélectionnez une région Google Cloud géographiquement proche de l'environnement d'informatique privé où sont hébergés les composants backend de votre application. Pour plus d'informations, consultez la section Bonnes pratiques pour la sélection des régions Compute Engine.
• Réduisez les dépendances élevées entre les systèmes exécutés dans des environnements différents, 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.
• Avec le modèle d'architecture hybride par tranche, vous pouvez avoir des volumes de trafic entrants plus importants depuis des environnements sur site vers Google Cloud par rapport au trafic sortant de Google Cloud. Toutefois, vous devez connaître le volume de transfert de données sortant prévu quittant Google Cloud. Si vous prévoyez d'utiliser cette architecture à long terme avec des volumes de transfert de données sortants élevés, envisagez d'utiliser Cloud Interconnect. Cloud Interconnect peut contribuer à optimiser les performances de connectivité et peut réduire les frais de transfert de données sortants pour le trafic qui répond à certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.
• 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é, vous pouvez utiliser des tunnels VPN, un VPN haute disponibilité sur Cloud Interconnect et MACsec pour 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.

• Pour faciliter la mise en place de configurations hybrides, utilisez Cloud Load Balancing avec une connectivité hybride. Vous pouvez ainsi étendre les avantages de l'équilibrage de charge cloud aux services hébergés dans votre environnement de calcul sur site. Cette approche permet de migrer les charges de travail par étapes vers Google Cloud avec une interruption de service minimale ou nulle, ce qui garantit une transition fluide pour les services distribués. Pour en savoir plus, consultez la section Présentation des groupes de points de terminaison du réseau de connectivité hybride.

• Parfois, l'utilisation d'un API Gateway, ou d'un proxy et d'un équilibreur de charge d'application ensemble, peut fournir une solution plus robuste pour gérer, sécuriser et distribuer le trafic des API à grande échelle. L'utilisation de Cloud Load Balancing avec des passerelles API vous permet de:

  • Fournissez des API hautes performances avec Apigee et Cloud CDN pour réduire la latence, héberger des API dans le monde entier et augmenter la disponibilité pendant les périodes de forte affluence. Pour en savoir plus, regardez la vidéo Fournir des API hautes performances avec Apigee et Cloud CDN sur YouTube.
  • Implémenter une gestion avancée du trafic.
  • Utiliser Google Cloud Armor comme service de protection contre les attaques DDoS et de sécurité réseau afin de protéger vos API.
  • Gérer un équilibrage de charge efficace sur les passerelles de plusieurs régions. Pour en savoir plus, regardez la vidéo Sécuriser les API et mettre en œuvre le basculement multirégional avec Private Service Connect et Apigee sur YouTube.

• Utilisez la gestion des API et le service mesh pour sécuriser et contrôler la communication et l'exposition des services avec l'architecture de microservices.

  • Utilisez Cloud Service Mesh pour permettre la communication de service à service qui maintient la qualité de service dans un système composé de services distribués où vous pouvez gérer l'authentification, l'autorisation et le chiffrement entre les services.
  • Utilisez une plate-forme de gestion des API telle qu'Apigee, qui permet à votre organisation et à des entités externes de consommer ces services en les exposant en tant qu'API.

• Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.

• Déployez des systèmes CI/CD et de gestion de la configuration dans le cloud public. Pour en savoir plus, consultez la section Modèle d'architecture réseau en miroir.

• Pour accroître l'efficacité opérationnelle, utilisez des outils et des pipelines CI/CD cohérents dans tous les environnements.

Bonnes pratiques pour les architectures de charge de travail et d'application individuelles

• Bien que l'accent soit mis sur les applications d'interface dans ce modèle, n'oubliez pas pour autant la nécessité de moderniser les applications backend. Si le rythme de développement des applications backend est nettement plus lent que celui des applications d'interface, cette différence peut entraîner une complexité supplémentaire.
• Traiter les API comme des interfaces backend simplifie les intégrations, le développement du frontend, les interactions de service et masque la complexité du système backend. Pour relever ces défis, Apigee facilite le développement et la gestion de passerelles/proxys d'API pour les déploiements hybrides et multicloud.
• Choisissez l'approche de rendu de votre application Web d'interface en fonction du contenu (statique ou dynamique), des performances de référencement et des attentes concernant la vitesse de chargement des pages.
• Lorsque vous sélectionnez une architecture pour des applications Web basées sur le contenu, plusieurs options s'offrent à vous, y compris les architectures monolithiques, sans serveur, basées sur les événements et de microservices. Pour sélectionner l'architecture la plus adaptée, évaluez minutieusement ces options par rapport à vos exigences actuelles et futures en matière d'application. Pour vous aider à prendre une décision architecturale en adéquation avec vos objectifs commerciaux et techniques, consultez Comparaison des différentes architectures pour les backends d'applications Web axées sur le contenu et Principaux éléments à prendre en compte pour les backends Web.

• Avec une architecture de microservices, vous pouvez utiliser des applications conteneurisées avec Kubernetes comme couche d'exécution commune. Avec le modèle d'architecture hybride par tranche, vous pouvez l'exécuter dans l'un des scénarios suivants :

  • Dans les deux environnements (Google Cloud et vos environnements sur site).

    • Lorsque vous utilisez des conteneurs et Kubernetes dans différents environnements, vous avez la flexibilité nécessaire pour moderniser vos charges de travail, puis migrer vers Google Cloud à différents moments. Cela est utile lorsqu'une charge de travail dépend fortement d'une autre et ne peut pas être migrée individuellement, ou pour utiliser la portabilité des charges de travail hybrides afin d'exploiter les meilleures ressources disponibles dans chaque environnement. Dans tous les cas, GKE Enterprise peut être une technologie clé. Pour en savoir plus, consultez la section Environnement hybride GKE Enterprise.

  • Dans un environnement Google Cloud pour les composants d'application migrés et modernisés.

    • Utilisez cette approche lorsque vous disposez de backends sur site obsolètes qui ne sont pas compatibles avec la conteneurisation ou qui nécessitent beaucoup de temps et de ressources pour être modernisés à court terme.

    Pour en savoir plus sur la conception et la refactorisation d'une application monolithique en architecture de microservices afin de moderniser votre architecture d'application Web, consultez la section Présentation des microservices.

• Vous pouvez combiner des technologies de stockage de données en fonction des besoins de vos applications Web. L'utilisation de Cloud SQL pour les données structurées et de Cloud Storage pour les fichiers multimédias est une approche courante pour répondre aux divers besoins de stockage de données. Toutefois, le choix dépend fortement de votre cas d'utilisation. Pour en savoir plus sur les options de stockage de données pour les backends d'applications basées sur le contenu et les modalités efficaces, consultez la section Options de stockage de données pour les applications Web basées sur le contenu. Consultez également Présentation des options de votre base de données Google Cloud.

Modèle multicloud partitionné

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 non exhaustive suivante 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 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 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 mise en 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 des 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.

Modèle analytique hybride et multicloud

Ce document explique que l'objectif du modèle analytique hybride et multicloud est de tirer parti de la répartition entre les charges de travail transactionnelles et analytiques.

Dans les systèmes d'entreprise, la plupart des charges de travail appartiennent aux catégories suivantes :

• Les charges de travail transactionnelles incluent des applications interactives telles que des applications de vente, de traitement financier, de planification des ressources d'entreprise ou de communication.
• Les charges de travail analytiques incluent des applications qui transforment, analysent, affinent ou visualisent des données pour faciliter les processus de prise de décision.

Les systèmes d'analyse obtiennent leurs données à partir de systèmes transactionnels en interrogeant des API ou en accédant à des bases de données. Dans la plupart des entreprises, les systèmes analytiques et transactionnels ont tendance à être séparés et faiblement couplés. L'objectif du modèle analytique hybride et multicloud est de tirer parti de cette division préexistante en exécutant des charges de travail transactionnelles et analytiques dans deux environnements informatiques différents. Les données brutes sont d'abord extraites des charges de travail exécutées dans l'environnement informatique privé, puis chargées dans Google Cloud, où elles sont utilisées à des fins de traitement analytique. Certains résultats peuvent ensuite être renvoyés aux systèmes transactionnels.

Le schéma suivant illustre les architectures conceptuellement possibles en affichant les pipelines de données potentiels. Chaque chemin/flèche représente une option de pipeline de transformation et de transfert de données possible pouvant être basée sur l'ETL ou l'ELT, en fonction de la qualité des données disponible et du cas d'utilisation ciblé.

Pour déplacer vos données vers Google Cloud et en tirer parti, utilisez les services de transfert de données, une suite complète de services d'ingestion, d'intégration et de réplication de données.

Comme illustré dans le diagramme précédent, connecter Google Cloud à des environnements sur site et à d'autres environnements cloud peut permettre de mettre en œuvre divers cas d'utilisation d'analyse de données, tels que le streaming de données et les sauvegardes de bases de données. Pour alimenter le transport de base d'un modèle d'analyse hybride et multicloud qui nécessite un volume élevé de transfert de données, Cloud Interconnect et Cross-Cloud Interconnect fournissent une connectivité dédiée aux fournisseurs cloud sur site et autres.

Avantages

L'exécution de charges de travail analytiques dans le cloud présente plusieurs avantages essentiels :

• Le trafic entrant (transfert de données de votre environnement informatique privé ou d'autres clouds vers Google Cloud) peut être gratuit.
• Les charges de travail analytiques doivent souvent traiter des quantités importantes de données et peuvent être exécutées en rafale. Elles sont donc particulièrement bien adaptées au déploiement dans un environnement de cloud public. En procédant au scaling des ressources de calcul de manière dynamique, vous pouvez traiter rapidement des ensembles de données volumineux tout en évitant les investissements initiaux et tout surprovisionnement de matériel informatique.
• Google Cloud fournit un ensemble complet de services permettant de gérer les données tout au long de leur cycle de vie, de l'acquisition initiale à la visualisation finale, en passant par le traitement et l'analyse.
  • Les services de transfert de données sur Google Cloud fournissent une suite complète de produits pour déplacer, intégrer et transformer des données de manière transparente de différentes manières.
  • Cloud Storage est parfaitement adapté à la construction d'un lac de données.

• Google Cloud vous aide à moderniser et à optimiser votre plate-forme de données pour briser les silos de données. L'utilisation d'un ata lakehouse permet de standardiser les différents formats de stockage. Elle peut également offrir la flexibilité, l'évolutivité et l'agilité nécessaires pour que vos données génèrent de la valeur pour votre entreprise plutôt que des sources d'inefficacité. Pour en savoir plus, consultez BigLake.

• BigQuery Omni fournit une puissance de calcul qui s'exécute localement sur le stockage AWS ou Azure. Il vous aide également à interroger vos propres données stockées dans Amazon Simple Storage Service (Amazon S3) ou Azure Blob Storage. Cette fonctionnalité d'analyse multicloud permet aux équipes chargées des données de décloisonner les données. Pour en savoir plus sur l'interrogation des données stockées en dehors de BigQuery, consultez la section Présentation des sources de données externes.

Bonnes pratiques

Pour mettre en œuvre le modèle d'architecture hybride et multicloud pour l'analyse, tenez compte des bonnes pratiques générales suivantes:

• Utilisez le schéma de mise en réseau de transfert pour permettre l'ingestion de données. Si les résultats analytiques doivent être renvoyés aux systèmes transactionnels, vous pouvez combiner le transfert et le modèle de sortie contrôlée.
• Servez-vous des files d'attente Pub/Sub ou des buckets Cloud Storage pour transférer des données à Google Cloud à partir de systèmes transactionnels exécutés dans votre environnement informatique privé. Ces files d'attente ou buckets peuvent ensuite servir de sources pour les pipelines de traitement de données et les charges de travail.
• Pour déployer des pipelines de données ETL et ELT, envisagez d'utiliser Cloud Data Fusion ou Dataflow, en fonction des exigences spécifiques de votre cas d'utilisation. Il s'agit de services de traitement de données cloud first entièrement gérés qui permettent de créer et de gérer des pipelines de données.
• Pour découvrir, classer et protéger vos éléments de données importants, envisagez d'utiliser les fonctionnalités de protection des données sensibles de Google Cloud, telles que les techniques d'anonymisation. Ces techniques vous permettent de masquer, de chiffrer et de remplacer les données sensibles, telles que les informations permettant d'identifier personnellement l'utilisateur, à l'aide d'une clé générée de manière aléatoire ou prédéterminée, le cas échéant et conformément à la réglementation.
• Lorsque vous avez des charges de travail Hadoop ou Spark existantes, il peut être utile de migrer les tâches vers Dataproc et de migrer les données HDFS existantes vers Cloud Storage.

• Lorsque vous effectuez un premier transfert de données de votre environnement informatique privé vers Google Cloud, choisissez la méthode de transfert la mieux adaptée à la taille de votre ensemble de données et à la bande passante disponible. Pour en savoir plus, consultez la page Migration vers Google Cloud : transférer des ensembles de données volumineux.

• Si le transfert ou l'échange de données entre Google Cloud et d'autres clouds est nécessaire à long terme avec un volume de trafic élevé, nous vous recommandons d'évaluer l'utilisation de Google Cloud Cross-Cloud Interconnect pour vous aider à établir une connectivité dédiée à haut débit entre Google Cloud et d'autres fournisseurs de services cloud (disponible dans certains emplacements).

• Si le chiffrement est requis au niveau de la couche de connectivité, différentes 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.

• Utilisez des outils et des processus cohérents dans tous les environnements. Dans un scénario d'analyse hybride, cette pratique peut contribuer à accroître l'efficacité opérationnelle, bien qu'elle ne constitue pas une condition préalable.

Modèle hybride de périphérie

Dans certains cas, pour exécuter des charges de travail dans le cloud, les clients doivent disposer d'une connectivité Internet rapide et fiable. Compte tenu des réseaux actuels, cette exigence pose rarement un défi pour les projets d'adoption du cloud. Il existe cependant des scénarios dans lesquels vous ne pouvez pas compter sur une connectivité continue, par exemple:

• Les navires et autres véhicules peuvent n'être connectés que de manière intermittente ou n'avoir accès qu'aux liaisons satellite à latence élevée.
• Les usines ou les centrales peuvent être connectées à Internet. Ces installations peuvent cependant avoir des exigences de fiabilité dépassant les affirmations de disponibilité de leur fournisseur d'accès à Internet.
• Les magasins et les supermarchés peuvent n'être connectés que de manière occasionnelle ou utiliser des liens n'offrant pas la fiabilité ou le débit nécessaires pour traiter des transactions critiques.

Le modèle d'architecture hybride de périphérie résout ces problèmes en exécutant localement des charges de travail urgentes et stratégiques, à la périphérie du réseau, tout en utilisant le cloud pour toutes les autres charges de travail. Dans une architecture hybride de périphérie, le lien Internet est un composant non critique utilisé à des fins de gestion et de synchronisation ou de chargement de données, souvent de manière asynchrone, mais n'intervenant pas dans des transactions urgentes ou critiques.

Avantages

L'exécution de certaines charges de travail à la périphérie et d'autres dans le cloud présente plusieurs avantages:

• Le trafic entrant (transfert de données de la périphérie vers Google Cloud) peut être gratuit.
• L'exécution de charges de travail urgentes et stratégiques à la périphérie permet de garantir une faible latence et une autosuffisance. Si la connexion Internet échoue ou est temporairement indisponible, vous pouvez toujours exécuter toutes les transactions importantes. Dans le même temps, vous pouvez tirer parti de l'utilisation du cloud pour une part importante de votre charge de travail globale.
• Vous pouvez réutiliser des investissements informatiques et de stockage existants.
• Au fil du temps, vous pouvez réduire progressivement la fraction de charges de travail exécutées en périphérie et les déplacer vers le cloud, soit en retravaillant certaines applications, soit en dotant certains emplacements de périphérie de liens Internet plus fiables.
• Les projets liés à l'Internet des objets (IoT) peuvent devenir plus rentables en effectuant des calculs de données localement. Cela permet aux entreprises d'exécuter et de traiter certains services localement en périphérie, plus près des sources de données. Il permet également aux entreprises d'envoyer des données de manière sélective vers le cloud, ce qui peut contribuer à réduire la capacité, le transfert de données, le traitement et les coûts globaux de la solution IoT.
• L'edge computing peut agir comme une couche de communication intermédiaire entre les services anciens et modernisés. (par exemple, les services qui peuvent exécuter une passerelle API conteneurisée telle qu'Apigee hybrid). Cela permet aux applications et systèmes anciens de s'intégrer à des services modernisés, tels que les solutions IoT.

Bonnes pratiques

Tenez compte des recommandations suivantes lorsque vous mettez en œuvre le modèle d'architecture hybride de périphérie:

• Si la communication est unidirectionnelle, utilisez le modèle d'entrée contrôlée.
• Si la communication est bidirectionnelle, tenez compte du modèle d'entrée et de sortie contrôlées.
• Si la solution se compose de nombreux sites distants de périphérie se connectant à Google Cloud via Internet public, vous pouvez utiliser une solution SD-WAN (Software-Defined WAN). Vous pouvez également utiliser Network Connectivity Center avec un routeur SD-WAN tiers compatible avec un partenaire Google Cloud pour simplifier le provisionnement et la gestion de la connectivité sécurisée à grande échelle.
• Minimisez les dépendances entre les systèmes exécutés en périphérie et ceux exécutés dans l'environnement cloud. Chaque dépendance peut compromettre les avantages en termes de fiabilité et de latence d'une configuration hybride en périphérie.
• Pour gérer et exploiter efficacement plusieurs emplacements périphériques, vous devez disposer d'un plan de gestion et d'une solution de surveillance centralisés dans le cloud.
• Assurez-vous que les pipelines CI/CD ainsi que les outils de déploiement et de surveillance sont cohérents dans les environnements cloud et périphériques.
• Envisagez d'utiliser des conteneurs et Kubernetes lorsque cela est possible et approprié, afin d'éliminer les différences entre les différents emplacements périphériques, ainsi qu'entre les emplacements périphériques et le cloud. Étant donné que Kubernetes fournit une couche d'exécution commune, vous pouvez développer, exécuter et utiliser des charges de travail de manière cohérente dans tous les environnements informatiques. Vous pouvez également déplacer des charges de travail entre le cloud et le réseau de périphérie.
  • Pour simplifier la configuration et le fonctionnement hybrides, vous pouvez utiliser GKE Enterprise pour cette architecture (si des conteneurs sont utilisés dans les environnements). Examinez les options de connectivité possibles pour connecter un cluster GKE Enterprise exécuté dans votre environnement sur site ou de périphérie à Google Cloud.
• Dans le cadre de ce modèle, bien que certains composants GKE Enterprise puissent être maintenus en cas d'interruption temporaire de la connectivité avec Google Cloud, n'utilisez pas GKE Enterprise lorsqu'il est déconnecté de Google Cloud en tant que mode de fonctionnement nominal. Pour en savoir plus, consultez la section Impact de la déconnexion temporaire de Google Cloud.
• Pour surmonter les incohérences entre les protocoles, les API et les mécanismes d'authentification dans les différents services backend et edge, 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.
• Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.
• Les données échangées entre environnements pouvant être sensibles, assurez-vous que toutes les communications sont chiffrées en transit à l'aide de tunnels VPN, du protocole TLS ou des deux.

Modèle d'environnement hybride

Avec le modèle d'architecture environnement hybride, vous conservez l'environnement de production d'une charge de travail dans le centre de données existant. Vous utilisez ensuite le cloud public pour vos environnements de développement et de test, ou d'autres environnements. Ce modèle repose sur le déploiement redondant des mêmes applications dans plusieurs environnements informatiques. L'objectif du déploiement est d'améliorer la capacité, l'agilité et la résilience.

En évaluant les charges de travail à migrer, vous remarquerez peut-être des cas où l'exécution d'une application spécifique dans le cloud public pose certains défis :

• Des contraintes juridictionnelles ou réglementaires peuvent nécessiter que vous conserviez des données dans un pays spécifique.
• Des conditions de licence tierces peuvent vous empêcher d'utiliser certains logiciels dans un environnement cloud.
• Une application peut nécessiter un accès à des périphériques matériels disponibles seulement en local.

Dans de tels cas, vous devez tenir compte non seulement de l'environnement de production, mais également de tous les environnements impliqués dans le cycle de vie d'une application, y compris les systèmes de développement, de test et de préproduction. Ces restrictions s'appliquent souvent à l'environnement de production et à ses données. Elles ne s'appliquent peut-être pas à d'autres environnements qui n'utilisent pas les données réelles. Contactez le service de conformité de votre organisation ou l'équipe équivalente.

Le schéma suivant illustre un modèle d'environnement hybride typique.

Le fait de faire fonctionner des systèmes de développement et de test dans des environnements différents de ceux de vos systèmes de production peut sembler risqué et s'écarter de vos bonnes pratiques existantes ou de vos tentatives visant à minimiser les différences entre vos environnements. Bien que ces préoccupations soient justifiées, elles ne s'appliquent pas si vous faites une distinction entre les étapes des processus de développement et de test :

Même si les processus de développement, de test et de déploiement diffèrent d'une application à l'autre, ils impliquent généralement des variantes des étapes suivantes :

• Développement : créer une version finale
• Tests fonctionnels ou tests d'acceptation utilisateur : vérifier que la version finale répond aux exigences fonctionnelles
• Tests de performance et de fiabilité : vérifier que la version finale répond aux exigences non fonctionnelles Il est également appelé test de charge.
• Tests de préproduction ou de déploiement : vérifier que la procédure de déploiement fonctionne
• Production: publication de nouvelles applications ou de mises à jour d'applications.

L'exécution de plusieurs de ces étapes dans un seul environnement est rarement pratique. Chaque étape nécessite donc généralement un ou plusieurs environnements dédiés.

Remarque :Le terme environnement de préproduction est souvent confondu avec le terme environnement de test.

L'objectif principal d'un environnement de test est d'exécuter des tests fonctionnels. L'objectif principal d'un environnement de préproduction est de vérifier si vos procédures de déploiement d'applications fonctionnent comme prévu. Dès lors qu'une version atteint un environnement de préproduction, vos tests fonctionnels doivent être terminés. Le prédéploiement est la dernière étape avant de déployer un logiciel dans votre déploiement de production.

Pour que les résultats de test soient significatifs et s'appliquent au déploiement de production, les environnements que vous utilisez tout au long du cycle de vie d'une application doivent tous respecter les règles suivantes, dans la mesure du possible :

• Tous les environnements sont équivalents du point de vue fonctionnel. En d'autres termes, l'architecture, les API ainsi que les versions des systèmes d'exploitation et des bibliothèques sont équivalentes, et les systèmes se comportent de la même manière dans tous les environnements. Cette équivalence permet d'éviter des situations où les applications fonctionneraient dans un environnement, mais échoueraient dans un autre, ou dans lesquelles les défaillances ne seraient pas reproductibles.
• Les environnements utilisés pour les tests de performance et de fiabilité, la préproduction et la production sont équivalents d'un point de vue non fonctionnel. Autrement dit, leurs performances, leur échelle et leur configuration, ainsi que la manière dont ils sont utilisés et gérés, sont identiques ou ne diffèrent que de manière peu significative. Les tests de performance et de préproduction deviendraient autrement dénués de sens.

En général, ce n'est pas un problème si les environnements utilisés pour le développement et les tests fonctionnels diffèrent des autres environnements du point de vue non fonctionnel.

Comme illustré dans le diagramme suivant, les environnements de test et de développement sont créés sur Google Cloud. Une base de données gérée, comme Cloud SQL, peut être utilisée comme option de développement et de test dans Google Cloud. Le développement et les tests peuvent utiliser le même moteur de base de données et la même version dans l'environnement sur site, un moteur fonctionnellement équivalent ou une nouvelle version déployée dans l'environnement de production après la phase de test. Toutefois, comme l'infrastructure sous-jacente des deux environnements n'est pas identique, cette approche des tests de charge de performances n'est pas valide.

Les scénarios suivants peuvent s'adapter au modèle d'environnement hybride:

• Parvenez à une équivalence fonctionnelle entre tous les environnements en utilisant Kubernetes en tant que couche d'exécution commune, le cas échéant et dans la mesure du possible. L'édition Enterprise de Google Kubernetes Engine (GKE) peut être une technologie clé pour cette approche.
  • Assurez la portabilité des charges de travail et éliminez les différences entre les environnements informatiques. Avec un maillage de services de confiance zéro, vous pouvez contrôler et maintenir la séparation de communication requise entre les différents environnements.
• Exécutez les environnements de développement et de tests fonctionnels dans le cloud public. Ces environnements sont équivalents aux environnements restants du point de vue fonctionnel, mais peuvent différer les uns des autres sur certains aspects non fonctionnels, tels que les performances. Ce concept est illustré dans le schéma précédent.
• Exécutez les environnements des tests de production, préproduction, performance (test de charge) et fiabilité dans l'environnement informatique privé, en veillant à avoir une équivalence des points de vue fonctionnel et non fonctionnel.

Considérations de conception

• Besoins de l'entreprise: chaque stratégie de déploiement et de lancement pour les applications a ses propres avantages et inconvénients. Pour vous assurer que l'approche que vous sélectionnez est conforme à vos exigences spécifiques, basez vos choix sur une évaluation approfondie de vos besoins et contraintes métier.
• Différences d'environnement: dans le cadre de ce modèle, l'objectif principal de l'utilisation de cet environnement cloud est le développement et les tests. L'état final consiste à héberger l'application testée dans l'environnement privé sur site (production). Pour éviter de développer et de tester une fonctionnalité susceptible d'opérer comme prévu dans l'environnement cloud et d'échouer dans l'environnement de production (sur site), l'équipe technique doit connaître et comprendre les architectures et les fonctionnalités des deux environnements. Cela inclut les dépendances vis-à-vis d'autres applications et de l'infrastructure matérielle (par exemple, les systèmes de sécurité qui effectuent une inspection du trafic).
• Gestion: pour contrôler ce que votre entreprise est autorisée à développer dans le cloud et les données qu'elle peut utiliser pour les tests, utilisez un processus d'approbation et de gouvernance. Ce processus peut également aider votre entreprise à s'assurer qu'elle n'utilise aucune fonctionnalité cloud dans ses environnements de développement et de test qui n'existent pas dans son environnement de production sur site.
• Critères de réussite: des critères de réussite des tests clairs, prédéfinis et mesurables doivent être définis, en accord avec les normes d'assurance qualité logicielle de votre organisation. Appliquez ces normes à toute application que vous développez et testez.
• Redondance: même si les environnements de développement et de test ne nécessitent pas autant de fiabilité que l'environnement de production, ils ont tout de même besoin de fonctionnalités redondantes et de la possibilité de tester différents scénarios de défaillance. Vos exigences concernant les scénarios de défaillance peuvent amener la conception à inclure une redondance dans votre environnement de développement et de test.

Avantages

L'exécution de charges de travail de développement et de tests fonctionnels dans le cloud public présente plusieurs avantages :

• Vous pouvez démarrer et arrêter automatiquement des environnements selon vos besoins. Par exemple, vous pouvez configurer un environnement complet pour chaque requête commit ou pull, autoriser l'exécution des tests, puis le détruire. Cette approche offre également les avantages suivants :
  • Vous pouvez réduire les coûts en arrêtant les instances de machine virtuelle (VM) lorsqu'elles sont inactives ou en ne provisionnant des environnements qu'à la demande.
  • Vous pouvez accélérer le développement et les tests en démarrant des environnements éphémères pour chaque requête pull. Cela permet également de réduire les coûts de maintenance et les incohérences dans l'environnement de compilation.
• En exécutant ces environnements dans le cloud public, vous pourrez vous familiariser avec le cloud et les outils associés, et les utiliser avec une confiance accrue, ce qui pourrait faciliter la migration d'autres charges de travail. Cette approche est particulièrement utile si vous décidez d'explorer la portabilité de charge de travail à l'aide de conteneurs et de Kubernetes (par exemple, en utilisant GKE Enterprise dans les environnements).

Bonnes pratiques

Pour mettre correctement en œuvre le modèle d'architecture hybride d'environnement, tenez compte des recommandations suivantes:

• Définissez les exigences de communication de votre application, y compris la conception optimale du réseau et de la sécurité. Ensuite, utilisez le modèle de réseau en miroir pour vous aider à concevoir votre architecture réseau afin d'empêcher les communications directes entre les systèmes de différents environnements. Si une communication est requise entre les environnements, elle doit être contrôlée.

• La stratégie de déploiement et de test de l'application que vous choisissez doit être en adéquation avec vos objectifs et exigences commerciaux. Cela peut impliquer de déployer des modifications sans temps d'arrêt ou d'implémenter progressivement des fonctionnalités dans un environnement ou un groupe d'utilisateurs spécifiques avant une diffusion plus large.

• Pour rendre les charges de travail portables et éliminer les différences entre les environnements, vous pouvez utiliser des conteneurs avec Kubernetes. Pour en savoir plus, consultez l'architecture de référence de l'environnement hybride GKE Enterprise.

• Définissez une chaîne d'outils commune qui fonctionne dans plusieurs environnements informatiques pour déployer, configurer et exploiter des charges de travail. L'utilisation de Kubernetes vous donnera cette cohérence.

• Assurez-vous que les processus CI/CD sont cohérents dans tous les environnements informatiques et que le même ensemble de fichiers binaires, de paquets ou de conteneurs est déployé dans ces environnements.

• Avec Kubernetes, utilisez un système de CI tel que Tekton pour mettre en œuvre un pipeline de déploiement qui se déploie sur des clusters et fonctionne dans différents environnements. Pour en savoir plus, consultez la section Solutions DevOps sur Google Cloud.

• Pour vous aider à publier en continu des applications sécurisées et fiables, incorporez la sécurité en tant que partie intégrante du ptocessus DevOps (DevSecOps). Pour en savoir plus, consultez Livrer et sécuriser votre application exposée sur Internet en moins d'une heure à l'aide du kit Dev(Sec)Ops.

• Utilisez les mêmes outils pour la journalisation et la surveillance dans les environnements Google Cloud et cloud existants. Envisagez 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 différentes équipes gèrent les charges de travail de test et de production, il peut être acceptable d'utiliser des outils distincts. Toutefois, l'utilisation des mêmes outils avec des autorisations de vue différentes peut vous aider à réduire l'effort et la complexité de la formation.

• Lorsque vous choisissez des services de base de données, de stockage et de messagerie pour les tests fonctionnels, utilisez des produits ayant un équivalent géré sur Google Cloud. Le recours à des services gérés permet de réduire les tâches administratives liées à la maintenance des environnements de développement et de test.

• 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é, différentes options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, HA VPN via Cloud Interconnect et MACsec pour Cloud Interconnect.

Le tableau suivant présente les produits Google Cloud compatibles avec les produits OSS courants.

Produit OSS	Compatible avec les produits Google Cloud
Apache HBase	Bigtable
Apache Beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL, PostgreSQL	Cloud SQL
Redis Cluster, Redis et Memcached	Memorystore
Système de fichiers réseau (NFS)	Filestore
JMS, Kafka	Pub/Sub
Kubernetes	GKE Enterprise

Modèles de continuité des opérations hybride et multicloud

L'objectif principal de la continuité des activités pour les systèmes critiques est d'aider une entreprise à être résiliente et à poursuivre ses activités pendant et après un incident. En répliquant les systèmes et les données sur plusieurs régions géographiques et en évitant les points de défaillance uniques, vous pouvez minimiser les risques de catastrophe naturelle affectant les infrastructures locales. D'autres scénarios de défaillance incluent une défaillance système grave, une attaque de cybersécurité ou même une erreur de configuration système.

L'optimisation d'un système pour qu'il résiste aux défaillances est essentielle pour établir une continuité d'activité efficace. La fiabilité du système peut être influencée par plusieurs facteurs, y compris, mais sans s'y limiter, les performances, la résilience, la disponibilité de l'application en ligne, la sécurité et l'expérience utilisateur. Pour en savoir plus sur la conception et l'exploitation de services fiables sur Google Cloud, consultez le pilier Fiabilité du framework d'architecture Google Cloud et les composants fondamentaux de la fiabilité dans Google Cloud.

Ce modèle d'architecture repose sur un déploiement redondant d'applications dans plusieurs environnements informatiques. Dans ce modèle, vous déployez les mêmes applications dans plusieurs environnements informatiques dans le but d'accroître la fiabilité. La continuité d'activité peut être définie comme la capacité d'une organisation à poursuivre ses principales fonctions ou services métier à des niveaux acceptables prédéfinis après un événement perturbateur.

La reprise après sinistre est considérée comme un sous-domaine de la continuité des activités. Elle vise explicitement à garantir que les systèmes IT assurant des fonctions métier critiques sont opérationnels dès que possible après une perturbation. En général, les stratégies et plans de reprise après sinistre contribuent souvent à l'élaboration d'une stratégie plus globale de continuité des activités. D'un point de vue technologique, lorsque vous commencez à créer des stratégies de reprise après sinistre, votre analyse de l'impact sur l'entreprise doit définir deux métriques clés: l'objectif de point de récupération (RPO, Recovery Point Objective) et l'objectif de temps de récupération (RTO, Recovery Time Objective). Pour plus de conseils sur l'utilisation de Google Cloud dans le cadre de la reprise après sinistre, consultez le guide de planification de reprise après sinistre.

Plus les valeurs cibles de RPO et de RTO sont faibles, plus les services peuvent récupérer rapidement d'une interruption avec une perte de données minimale. Toutefois, cela implique des coûts plus élevés, car cela implique de créer des systèmes redondants. Les systèmes redondants capables de répliquer des données en quasi temps réel et qui fonctionnent à la même échelle après un événement de défaillance augmentent la complexité, les frais administratifs et les coûts.

La décision de sélectionner une stratégie de reprise après sinistre ou un modèle doit être guidée par une analyse de l'impact commercial. Par exemple, les pertes financières subies par une entreprise de services financiers en cas de panne de quelques minutes peuvent largement dépasser le coût de l'implémentation d'un système de DR. Toutefois, les entreprises d'autres secteurs peuvent subir des heures d'indisponibilité sans que cela ait un impact significatif sur leur activité.

Lorsque vous exécutez des systèmes critiques dans un centre de données sur site, une approche de reprise après sinistre consiste à gérer les systèmes de secours dans un deuxième centre de données situé dans une autre région. Toutefois, une approche plus économique consiste à utiliser un environnement informatique basé sur un cloud public à des fins de basculement. Cette approche est le principal moteur du modèle de continuité d'activité hybride. Le cloud peut être particulièrement intéressant d'un point de vue coûteux, car il vous permet de désactiver une partie de votre infrastructure de reprise après sinistre lorsqu'elle n'est pas utilisée. Pour obtenir une solution de reprise après sinistre moins coûteuse, une solution cloud permet à une entreprise d'accepter l'augmentation potentielle des valeurs RPO et RTO.

Le schéma précédent illustre l'utilisation du cloud comme environnement de basculement ou de reprise après sinistre pour un environnement sur site.

Une variante moins courante (et rarement requise) de ce modèle est le modèle de continuité d'activité multicloud. Dans ce modèle, l'environnement de production utilise un fournisseur cloud et l'environnement de reprise après sinistre utilise un autre fournisseur cloud. En déployant des copies de charges de travail auprès de plusieurs fournisseurs cloud, vous pouvez obtenir une disponibilité supérieure à celle proposée par un déploiement multirégion.

Évaluer une reprise après sinistre dans plusieurs clouds par rapport à l'utilisation d'un fournisseur de services cloud avec différentes régions nécessite une analyse approfondie de plusieurs éléments, y compris les suivants:

• Gestion
• Sécurité
• Faisabilité globale
• Coût
  • Les frais potentiels de transfert de données sortantes de plusieurs fournisseurs de services cloud peuvent être élevés en cas de communication inter-cloud continue.
  • Le volume de trafic peut être élevé lors de la réplication de bases de données.
  • Le TCO et le coût de gestion de l'infrastructure réseau inter-cloud

Remarque :Pour en savoir plus sur la façon dont interconnexion cross-cloud peut vous aider à réduire le TCO et la complexité, consultez Annonce de interconnexion cross-cloud: connectivité fluide à tous vos clouds.

Si vos données doivent rester dans votre pays pour répondre aux exigences réglementaires, vous pouvez envisager d'utiliser un deuxième fournisseur cloud situé également dans votre pays comme solution de DR. L'utilisation d'un deuxième fournisseur de services cloud suppose qu'il n'est pas possible d'utiliser un environnement sur site pour créer une configuration hybride. Pour éviter de repenser votre solution cloud, dans l'idéal, votre deuxième fournisseur cloud doit proposer toutes les fonctionnalités et tous les services dont vous avez besoin dans la région.

Considérations de conception

• Attentes concernant la DR: les objectifs de RPO et de RTO que votre entreprise souhaite atteindre doivent guider votre architecture de DR et la planification de la création.
• Architecture de la solution: avec ce modèle, vous devez répliquer les fonctions et fonctionnalités existantes de votre environnement sur site pour répondre à vos attentes en matière de reprise après sinistre. Vous devez donc évaluer la faisabilité et la viabilité du rehosting, du refactoring ou de la refonte de vos applications pour fournir les mêmes fonctions et performances (ou plus optimisées) dans l'environnement cloud.
• Concevoir et créer: la création d'une zone de destination est presque toujours une condition préalable au déploiement de charges de travail d'entreprise dans un environnement cloud. Pour en savoir plus, consultez la section Conception de zone de destination dans Google Cloud.

• Appel de la reprise après sinistre: il est important que votre conception et votre processus de reprise après sinistre tiennent compte des questions suivantes:

  • Qu'est-ce qui déclenche un scénario de reprise après sinistre ? Par exemple, une DR peut être déclenchée par la défaillance de fonctions ou de systèmes spécifiques sur le site principal.
  • Comment le basculement vers l'environnement de reprise après sinistre est-il déclenché ? S'agit-il d'un processus d'approbation manuel ou peut-il être automatisé pour atteindre un objectif de RTO faible ?
  • Comment les mécanismes de détection et de notification des défaillances du système doivent-ils être conçus pour appeler le basculement conformément au RTO attendu ?
  • Comment le trafic est-il redirigé vers l'environnement de reprise après sinistre après la détection de la défaillance ?

  Validez vos réponses à ces questions par le biais de tests.

• Tests: testez et évaluez minutieusement le basculement vers la reprise après sinistre. Assurez-vous qu'il répond à vos attentes en termes de RPO et de RTO. Cela vous permettra d'invoquer la DR plus facilement si nécessaire. Chaque fois qu'une modification ou une mise à jour est apportée au processus ou à la solution technologique, effectuez à nouveau les tests.

• Compétences en équipe: une ou plusieurs équipes techniques doivent disposer des compétences et de l'expertise nécessaires pour créer, exploiter et résoudre les problèmes liés à la charge de travail de production dans l'environnement cloud, sauf si votre environnement est géré par un tiers.

Avantages

L'utilisation de Google Cloud pour la continuité des activités présente plusieurs avantages:

• Comme Google Cloud propose un choix de nombreuses régions à travers le monde, vous pouvez l'utiliser pour sauvegarder ou répliquer des données sur un site différent du même continent. Vous pouvez également sauvegarder ou répliquer des données sur un site d'un autre continent.
• Google Cloud vous permet de stocker des données dans Cloud Storage dans un bucket bi-régional ou multirégional. Les données sont stockées de manière redondante dans au moins deux régions géographiques distinctes. Les données stockées dans des buckets birégionaux et multirégionaux sont répliquées dans plusieurs régions géographiques à l'aide de la réplication par défaut.
  • Les buckets birégionaux offrent une géoredondance pour assurer la continuité des activités et les plans de reprise après sinistre. De plus, pour répliquer plus rapidement, avec un RPO plus faible, les objets stockés dans des régions duales peuvent éventuellement utiliser la réplication turbo dans ces régions.
  • De même, la réplication multirégionale offre une redondance dans plusieurs régions en stockant vos données dans les limites géographiques de la multirégion.
• Fournit une ou plusieurs des options suivantes pour réduire les dépenses en capital et les dépenses opérationnelles afin de créer une reprise après sinistre :
  • Les instances de VM arrêtées n'engendrent que des coûts de stockage et sont nettement moins chères que les instances de VM en cours d'exécution. Vous pouvez ainsi réduire les coûts liés à la maintenance des systèmes de secours manuels.
  • Le modèle de tarification à l'utilisation de Google Cloud vous permet de ne payer que pour l'espace de stockage et la capacité de calcul que vous utilisez réellement.
  • Les fonctionnalités d'élasticité, comme l'autoscaling, vous permettent d'augmenter ou de réduire automatiquement votre environnement de DR selon les besoins.

Par exemple, le diagramme suivant montre une application exécutée dans un environnement sur site (production) qui utilise des composants de récupération sur Google Cloud avec Compute Engine, Cloud SQL et Cloud Load Balancing. Dans ce scénario, la base de données est préprovisionnée à l'aide d'une base de données basée sur des VM ou d'une base de données gérée par Google Cloud, comme Cloud SQL, pour une récupération plus rapide avec une réplication de données continue. Vous pouvez lancer des VM Compute Engine à partir d'instantanés précréés pour réduire les coûts lors des opérations normales. Avec cette configuration, et après un événement de défaillance, le DNS doit pointer vers l'adresse IP externe de Cloud Load Balancing.

Pour que l'application soit opérationnelle dans le cloud, vous devez provisionner les VM Web et d'application. Selon le niveau de RTO ciblé et les règles de l'entreprise, l'ensemble du processus d'appel d'une reprise après sinistre, de provisionnement de la charge de travail dans le cloud et de réacheminement du trafic peut être effectué manuellement ou automatiquement.

Pour accélérer et automatiser le provisionnement de l'infrastructure, envisagez de la gérer en tant que code. Vous pouvez utiliser Cloud Build, un service d'intégration continue, pour appliquer automatiquement des fichiers manifestes Terraform à votre environnement. Pour en savoir plus, consultez la page Gérer une infrastructure en tant que code avec Terraform, Cloud Build et GitOps.

Bonnes pratiques

Lorsque vous utilisez le modèle de continuité d'activité, tenez compte des bonnes pratiques suivantes:

• Créez un plan de reprise après sinistre qui documente votre infrastructure, ainsi que les procédures de basculement et de récupération.
• Tenez compte des actions suivantes en fonction de votre analyse de l'impact commercial et des cibles RPO et RTO requises :
  • Déterminez si la sauvegarde des données sur Google Cloud est suffisante ou si vous devez envisager une autre stratégie de reprise après sinistre (systèmes de secours à froid, tièdes ou à chaud).
  • Définissez les services et les produits que vous pouvez utiliser comme éléments de base pour votre plan de reprise après sinistre.
  • Définissez les scénarios de reprise après sinistre applicables à vos applications et à vos données dans le cadre de la stratégie de reprise après sinistre que vous avez sélectionnée.
• Envisagez d'utiliser le modèle de transfert lorsque vous ne sauvegardez que des données. Sinon, le modèle en réseau maillé peut être une bonne option pour reproduire l'architecture réseau de l'environnement existant.
• Réduisez les dépendances entre les systèmes exécutés dans des environnements différents, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances et réduire la disponibilité globale.

• Évitez le problème de split-brain. Si vous répliquez des données de manière bidirectionnelle sur plusieurs environnements, vous pouvez être exposé au problème de Split-Brain. Le problème de split-brain se produit lorsque deux environnements qui répliquent des données de manière bidirectionnelle perdent la communication entre eux. Cette division peut amener les systèmes des deux environnements à conclure que l'autre environnement n'est pas disponible et qu'ils ont un accès exclusif aux données. Cela peut entraîner des modifications contradictoires des données. Il existe deux méthodes courantes pour éviter le problème de cerveau divisé:

  • Utiliser un troisième environnement IT Cet environnement permet aux systèmes de vérifier la présence d'un quorum avant de modifier les données.

  • Autorisez le rapprochement des modifications de données en conflit après la restauration de la connectivité.

    Avec les bases de données SQL, vous pouvez éviter le problème de split-brain en rendant l'instance principale d'origine inaccessible avant que les clients ne commencent à utiliser la nouvelle instance principale. Pour en savoir plus, consultez la page Reprise après sinistre de la base de données Cloud SQL.

• Assurez-vous que les systèmes CI/CD et les dépôts d'artefacts ne se transforment pas en point de défaillance unique. Lorsqu'un environnement est indisponible, vous devez toujours pouvoir déployer de nouvelles versions ou appliquer des modifications de configuration.

• Rendez toutes les charges de travail portables lorsque vous utilisez des systèmes de secours. Toutes les charges de travail doivent être portables (si elles sont prises en charge par les applications et si cela est possible) afin que les systèmes restent cohérents dans tous les environnements. Pour ce faire, vous pouvez envisager d'utiliser des conteneurs et Kubernetes. En utilisant l'édition Enterprise de Google Kubernetes Engine (GKE), vous pouvez simplifier la compilation et les opérations.

• Intégrez le déploiement de systèmes de secours dans votre pipeline CI/CD. Cette intégration permet de garantir la cohérence des versions et des configurations d'applications dans tous les environnements.

• Assurez-vous que les modifications DNS sont propagées rapidement en configurant votre DNS avec une valeur TTL relativement courte afin de pouvoir rediriger les utilisateurs vers des systèmes de secours en cas de sinistre.

• Sélectionnez les règles DNS et de routage qui correspondent à votre architecture et au comportement de votre solution. Vous pouvez également combiner plusieurs équilibreurs de charge régionaux avec des règles de routage DNS pour créer des architectures d'équilibrage de charge global pour différents cas d'utilisation, y compris la configuration hybride.

• Utilisez plusieurs fournisseurs DNS. Lorsque vous utilisez plusieurs fournisseurs DNS, vous pouvez:

  • Améliorez la disponibilité et la résilience de vos applications et services.

  • Simplifiez le déploiement ou la migration d'applications hybrides qui ont des dépendances dans les environnements sur site et cloud grâce à une configuration DNS multifournisseur.

    Google Cloud propose une solution Open Source basée sur octoDNS pour vous aider à configurer et à exploiter un environnement avec plusieurs fournisseurs DNS. Pour en savoir plus, consultez la section DNS public multifournisseur avec Cloud DNS.

• Utilisez des équilibreurs de charge lorsque vous utilisez des systèmes de secours pour créer un basculement automatique. N'oubliez pas que le matériel de l'équilibreur de charge peut tomber en panne.

• Utilisez Cloud Load Balancing au lieu d'équilibreurs de charge matériels pour alimenter certains scénarios qui se produisent lorsque vous utilisez ce modèle d'architecture. Les requêtes client internes ou les requêtes client externes peuvent être redirigées vers l'environnement principal ou l'environnement de reprise après sinistre en fonction de différentes métriques, telles que la division du trafic basée sur le poids. Pour en savoir plus, consultez la section Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes globaux.

• Envisagez d'utiliser Cloud Interconnect ou interconnexion cross-cloud si le volume de transfert de données sortant de Google Cloud vers l'autre environnement est élevé. Cloud Interconnect peut vous aider à optimiser les performances de connectivité et peut réduire les frais de transfert de données sortants pour le trafic qui répond à certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.

• Envisagez d'utiliser la solution partenaire de votre choix sur Google Cloud Marketplace pour faciliter les sauvegardes et les réplications de données, ainsi que les autres tâches qui répondent à vos exigences, y compris vos cibles de RPO et de RTO.

• Testez et évaluez les scénarios d'appel de DR pour comprendre dans quelle mesure l'application peut se remettre d'un sinistre par rapport à la valeur de RTO cible.

• Chiffrez les communications en transit. 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é, diverses options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, HA VPN via Cloud Interconnect et MACsec pour Cloud Interconnect.

Modèle d'utilisation temporaire du cloud

Les applications Internet peuvent connaître des fluctuations d'utilisation extrêmes. Bien que la plupart des applications d'entreprise ne soient pas confrontées à ce problème, de nombreuses entreprises doivent faire face à un type de charges de travail intensives différent: les tâches par lots ou CI/CD.

Ce modèle d'architecture repose sur un déploiement redondant d'applications dans plusieurs environnements informatiques. L'objectif est d'augmenter la capacité ou la résilience, ou les deux.

Bien que vous puissiez gérer des charges de travail intensives dans un environnement informatique basé sur un centre de données en approvisionnant des ressources en quantité excessive, cette approche n'est pas forcément rentable. Avec les tâches par lots, vous pouvez optimiser leur utilisation en différant leur exécution sur des périodes plus longues, bien qu'il ne soit pas pratique de retarder les tâches si elles sont urgentes.

Le concept de modèle d'utilisation temporaire du cloud consiste à utiliser un environnement informatique privé pour la charge de base et à se connecter temporairement au cloud en cas de besoins de capacité accrus.

Dans le diagramme précédent, lorsque la capacité de données est à sa limite dans un environnement privé sur site, le système peut gagner de la capacité supplémentaire à partir d'un environnement Google Cloud si nécessaire.

Les principaux moteurs de ce modèle sont l'économie d'argent et la réduction du temps et des efforts nécessaires pour répondre aux changements de besoins d'évolutivité. Avec cette approche, vous ne payez que les ressources utilisées lors du traitement des charges supplémentaires. Vous n'avez donc pas besoin de surprovisionner votre infrastructure. Vous pouvez plutôt profiter des ressources cloud à la demande et les faire évoluer en fonction de la demande et de toute métrique prédéfinie. Votre entreprise peut ainsi éviter les interruptions de service pendant les heures de pointe.

La portabilité des charges de travail est une exigence potentielle pour les scénarios d'utilisation temporaire du cloud. Lorsque vous autorisez le déploiement de charges de travail dans plusieurs environnements, vous devez supprimer les différences qui existent entre ces environnements. Par exemple, Kubernetes vous permet d'assurer la cohérence au niveau de la charge de travail dans divers environnements qui utilisent différentes infrastructures. Pour en savoir plus, consultez l'architecture de référence de l'environnement hybride GKE Enterprise.

Considérations de conception

Le modèle d'utilisation temporaire du cloud s'applique aussi bien aux charges de travail interactives et par lots. Toutefois, lorsque vous traitez des charges de travail interactives, vous devez déterminer comment répartir les requêtes entre les différents environnements:

• Vous pouvez acheminer les requêtes entrantes des utilisateurs vers un équilibreur de charge exécuté dans le centre de données existant, puis faire en sorte que l'équilibreur de charge répartisse les requêtes entre les ressources locales et cloud.

  Cette approche nécessite que l'équilibreur de charge ou un autre système en cours d'exécution dans le centre de données existant procède également au suivi des ressources allouées dans le cloud. L'équilibreur de charge ou un autre système doit également lancer l'ajustement automatique des ressources. Cette approche vous permet de mettre toutes les ressources cloud hors service en période de faible activité. Toutefois, la mise en place de mécanismes permettant de suivre les ressources peut aller au-delà des capacités de vos solutions d'équilibrage de charge et augmenter ainsi la complexité globale.

• Au lieu d'implémenter des mécanismes de suivi des ressources, vous pouvez utiliser l'Cloud Load Balancing avec un backend de groupe de points de terminaison du réseau (NEG) de connectivité hybride. Vous utilisez cet équilibreur de charge pour acheminer les requêtes client internes ou les requêtes client externes vers des backends situés à la fois sur site et dans Google Cloud, et qui sont basés sur différentes métriques, comme la répartition du trafic en fonction d'une pondération. Vous pouvez également faire évoluer les backends en fonction de la capacité de diffusion de l'équilibrage de charge pour les charges de travail dans Google Cloud. Pour en savoir plus, consultez la section Présentation de la gestion du trafic pour les équilibreurs de charge d'application externes globaux.

  Cette approche présente plusieurs avantages supplémentaires, tels que l'exploitation des fonctionnalités de protection DDoS de Google Cloud Armor, du WAF et du cache de contenu au niveau du cloud edge à l'aide de Cloud CDN. Toutefois, vous devez dimensionner la connectivité réseau hybride pour gérer le trafic supplémentaire.

• Comme indiqué dans la section Portabilité des charges de travail, une application peut être portable dans un autre environnement avec des modifications minimales pour assurer la cohérence des charges de travail, mais cela ne signifie pas que ses performances seront les mêmes dans les deux environnements. Les différences de calcul sous-jacent, des fonctionnalités de sécurité de l'infrastructure ou de l'infrastructure réseau, ainsi que la proximité de services dépendants, déterminent généralement les performances. Grâce aux tests, vous pouvez obtenir une visibilité plus précise et comprendre les attentes en termes de performances.

• Vous pouvez utiliser des services d'infrastructure cloud pour créer un environnement permettant d'héberger vos applications sans portabilité. Utilisez les approches suivantes pour gérer les requêtes client lorsque le trafic est redirigé pendant les pics de demande:

  • Utilisez des outils cohérents pour surveiller et gérer ces deux environnements.
  • Assurez-vous que la gestion des versions de la charge de travail est cohérente et que vos sources de données sont à jour.
  • Vous devrez peut-être ajouter une automatisation pour provisionner l'environnement cloud et rediriger le trafic lorsque la demande augmente et que la charge de travail cloud doit accepter les requêtes client pour votre application.

• Si vous avez l'intention de fermer toutes les ressources Google Cloud pendant les périodes de faible demande, l'utilisation de règles de routage DNS principalement pour l'équilibrage de la charge de trafic n'est pas toujours optimale. Cela est principalement dû aux raisons suivantes:

  • L'initialisation des ressources peut prendre un certain temps avant qu'elles puissent servir les utilisateurs.
  • Les mises à jour DNS ont tendance à se propager lentement sur Internet.

  En conséquence :

  • Les utilisateurs peuvent être acheminés vers l'environnement Cloud, même lorsqu'aucune ressource n'est disponible pour traiter leurs requêtes.
  • Les utilisateurs peuvent continuer à être redirigés vers l'environnement sur site temporairement pendant que les mises à jour DNS se propagent sur Internet.

Avec Cloud DNS, vous pouvez choisir les règles DNS et de routage qui correspondent à l'architecture et au comportement de votre solution, comme les règles de routage DNS de géolocalisation. Cloud DNS accepte également les vérifications de l'état pour les équilibreurs de charge réseau passthrough internes et les équilibreurs de charge d'application internes. Dans ce cas, vous pouvez l'intégrer à votre configuration DNS hybride globale basée sur ce modèle.

Dans certains cas, vous pouvez utiliser Cloud DNS pour distribuer les requêtes client avec des vérifications de l'état sur Google Cloud, par exemple lorsque vous utilisez des équilibreurs de charge d'application internes ou des équilibreurs de charge d'application internes interrégionaux. Dans ce scénario, Cloud DNS vérifie l'état global de l'équilibreur de charge d'application interne, qui vérifie à son tour l'état des instances backend. Pour en savoir plus, consultez la page Gérer les règles de routage DNS et les vérifications d'état.

Vous pouvez également utiliser le DNS fractionné Cloud DNS. Le DNS fractionné Cloud DNS est une approche permettant de configurer des réponses ou des enregistrements DNS en fonction de l'emplacement ou du réseau spécifique de l'expéditeur de la requête DNS pour le même nom de domaine. Cette approche est couramment utilisée pour répondre aux exigences d'une application conçue pour offrir à la fois une expérience privée et une expérience publique, chacune avec des fonctionnalités uniques. Cette approche permet également de répartir la charge de trafic entre les environnements.

Compte tenu de ces considérations, l'utilisation temporaire du cloud se prête généralement mieux aux charges de travail par lots qu'aux charges de travail interactives.

Avantages

Voici les principaux avantages du modèle d'architecture d'utilisation intensive dans le cloud:

• L'utilisation temporaire du cloud vous permet de réutiliser des centres de données et environnements informatiques privés existants. Cette réutilisation peut être permanente ou temporaire jusqu'à ce que le remplacement des équipements existants soit nécessaire. Vous pourrez alors envisager une migration complète.
• Comme vous n'avez plus besoin de conserver une capacité excédentaire pour répondre aux pics de requêtes, vous pourrez peut-être augmenter l'utilisation et la rentabilité de vos environnements informatiques privés.
• L'utilisation temporaire du cloud vous permet d'exécuter des tâches par lots en temps voulu sans qu'il soit nécessaire de provisionner des ressources de calcul supplémentaires.

Bonnes pratiques

Lorsque vous mettez en œuvre le modèle d'utilisation temporaire du cloud, tenez compte des bonnes pratiques suivantes :

• Pour vous assurer que les charges de travail exécutées dans le cloud peuvent accéder aux ressources de la même manière que les charges de travail exécutées dans un environnement sur site, utilisez le modèle maillé avec le principe d'accès de sécurité le moins privilégié. Si la conception de la charge de travail le permet, vous ne pouvez autoriser l'accès que du cloud à l'environnement IT sur site, et non l'inverse.
• Pour minimiser la latence des communications entre les environnements, choisissez une région Google Cloud géographiquement proche de votre environnement informatique privé. Pour en savoir plus, consultez la section Bonnes pratiques pour la sélection des régions Compute Engine.
• Lorsque vous utilisez le modèle d'utilisation temporaire du cloud pour des charges de travail par lots seulement, réduisez la surface d'attaque de sécurité en gardant toutes les ressources Google Cloud privées. Interdisez tout accès direct à ces ressources depuis Internet, même si vous utilisez l'équilibrage de charge externe Google Cloud pour fournir le point d'entrée à la charge de travail.

• Sélectionnez les règles DNS et de routage qui correspondent à votre modèle d'architecture et au comportement de la solution ciblée.

  • Dans le cadre de ce modèle, vous pouvez appliquer la conception de vos règles DNS de manière permanente ou lorsque vous avez besoin d'une capacité supplémentaire à l'aide d'un autre environnement pendant les pics de demande.
  • Vous pouvez utiliser des règles de routage DNS de géolocalisation pour définir un point de terminaison DNS global pour vos équilibreurs de charge régionaux. Cette stratégie présente de nombreux cas d'utilisation pour les règles de routage DNS de géolocalisation, y compris les applications hybrides qui utilisent Google Cloud avec un déploiement sur site dans une région Google Cloud.

  • Si vous devez fournir des enregistrements différents pour les mêmes requêtes DNS, vous pouvez utiliser le DNS fractionné (par exemple, pour les requêtes provenant de clients internes et externes).

    Pour en savoir plus, consultez les architectures de référence pour le DNS hybride.

• Pour vous assurer que les modifications DNS sont propagées rapidement, configurez votre DNS avec une valeur TTL relativement courte afin de pouvoir rediriger les utilisateurs vers des systèmes de secours lorsque vous avez besoin de capacité supplémentaire à l'aide d'environnements cloud.

• Pour les tâches qui ne sont pas très urgentes et qui ne stockent pas de données localement, envisagez d'utiliser des instances de VM Spot, qui reviennent nettement moins cher que les instances de VM classiques. Toutefois, une condition préalable est que, si la tâche de VM est préemptée, le système doit pouvoir la redémarrer automatiquement.

• Utilisez des conteneurs pour assurer la portabilité des charges de travail, le cas échéant. De plus, GKE Enterprise peut être une technologie clé pour cette conception. Pour en savoir plus, consultez l'architecture de référence de l'environnement hybride GKE Enterprise.

• Surveillez tout trafic envoyé depuis Google Cloud vers un environnement informatique différent. Ce trafic est soumis à des frais de transfert de données sortantes.

• Si vous prévoyez d'utiliser cette architecture à long terme avec un volume de transfert de données sortant élevé, envisagez d'utiliser Cloud Interconnect. Cloud Interconnect peut vous aider à optimiser les performances de connectivité et peut réduire les frais de transfert de données sortants pour le trafic qui répond à certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.

• Lorsque vous utilisez Cloud Load Balancing, vous devez utiliser ses fonctionnalités d'optimisation de la capacité des applications , le cas échéant. Cela peut vous aider à résoudre certains des problèmes de capacité pouvant survenir dans les applications distribuées dans le monde entier.

• Authentifiez les personnes qui utilisent vos systèmes en établissant une identité commune 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 protéger les informations sensibles, il est vivement recommandé de chiffrer toutes les communications en transit. Si le chiffrement est requis au niveau de la couche de connectivité, différentes options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, HA VPN via Cloud Interconnect et MACsec pour Cloud Interconnect.

Modèles d'architecture hybride et multicloud: que nous réserve l'avenir ?

• Découvrez comment aborder l'architecture hybride et multicloud et comment choisir les charges de travail appropriées.
• Découvrez les modèles d'architecture réseau adaptés aux modèles d'architecture hybride et multicloud sélectionnés.
• En savoir plus sur les archétypes de déploiement pour les applications cloud
• Découvrez comment concevoir et déployer une application Web d'e-commerce à l'aide de différentes architectures, y compris une application Web d'e-commerce basée sur des microservices à l'aide de GKE et une application Web dynamique basée sur une API sans serveur.