Ce document est le deuxième d'un ensemble de trois. Il aborde 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 à 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 parties suivantes :

• Créez des architectures hybrides et multicloud : explique comment planifier une stratégie pour concevoir 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 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 une façon reproductible de structurer plusieurs composants fonctionnels d'une solution technologique, d'une application ou d'un service pour créer une solution réutilisable qui répond à certaines exigences ou à certains 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 se composer de plusieurs niveaux fonctionnels, modules ou services, chacun pouvant 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 spécifiques et servir de modèle réutilisable et fondamental.

Pour définir de manière générale 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 l'interface utilisateur graphique ou les fonctions de backend pour fournir un accès aux données).
• Comment les composants communiquent entre eux et avec les systèmes ou 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, requête/réponse ou 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é des charges de travail ou des 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 redondante : 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 pour le développement et les tests.

Lorsque vous implémentez le modèle d'architecture que vous sélectionnez, 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 aux applications. 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 Google Cloud zones ou régions 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 contient 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 redondante

  • 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 des solutions EMEA, modernisation des applications
• Ammett Williams | Ingénieur relations avec les développeurs

Modèles d'architecture distribuée

Lorsque vous migrez d'un environnement informatique non hybride ou non multicloud vers une architecture hybride ou multicloud, tenez d'abord compte des contraintes de vos applications existantes et de la façon dont ces contraintes pourraient entraîner l'échec 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 identifié vos contraintes, élaborez un plan pour les éviter ou les surmonter. Veillez à prendre en compte les fonctionnalités uniques de chaque environnement de calcul dans une architecture distribuée.

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 commerciaux, la priorité et l'effet de chaque considération peuvent varier.

Latence

Dans n'importe quel modèle d'architecture qui distribue les composants d'application (frontaux, de backend ou microservices) dans différents environnements de calcul, une latence de communication peut se produire. Cette latence est influencée par la connectivité réseau hybride (Cloud VPN et Cloud Interconnect) et par 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 délais du réseau. Les applications qui peuvent tolérer la latence sont plus adaptées au déploiement distribué initial dans un environnement hybride ou multicloud.

Architecture d'état temporaire ou 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 sortantes et optimiser les performances du réseau de connectivité hybride, Cloud Interconnect applique des remises sur les frais de transfert de données sortantes qui répondent aux conditions du taux de transfert de données remisé.

Fiabilité

La fiabilité est un facteur majeur à prendre en compte lors de la conception de systèmes informatiques. La disponibilité du temps d'activité est un aspect essentiel de la fiabilité du système. Dans Google Cloud, vous pouvez augmenter la résilience d'une application en déployant des composants redondants de cette application sur plusieurs zones d'une même région¹ ou sur plusieurs régions, avec des capacité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 avec une configuration 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 associée (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 Disponibilité composite : calculer la disponibilité globale de l'infrastructure cloud.

Pour atteindre le niveau de fiabilité du 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 la fiabilité en fonction des objectifs d'expérience utilisateur.

Connectivité hybride et multicloud

Les exigences de communication entre les composants des applications distribuées doivent influencer votre choix d'option de connectivité réseau hybride. Chaque option de connectivité présente des avantages et des 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 Remarques 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 entraîner des coûts de développement, de test et d'exploitation supplémentaires. 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 sélectionnée à la complexité potentielle à court terme par rapport aux avantages à long terme.

Coût

Chaque fournisseur de services cloud d'un environnement multicloud dispose de ses propres métriques et outils de facturation. Pour améliorer la visibilité et unifier les tableaux de bord, 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 entraîner 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 complet des ressources cloud et d'assurer la visibilité des coûts. La visibilité des coûts est essentielle pour les optimiser. Par exemple, en combinant les données de facturation des fournisseurs de services cloud que vous utilisez et en utilisant le bloc Looker Cloud Cost Management, vous pouvez créer une vue centralisée de vos coûts multicloud. Google CloudCette vue peut vous aider à obtenir une vue consolidée de vos dépenses dans plusieurs clouds. Pour en savoir plus, consultez 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 solide, une équipe centrale peut déléguer la prise de décisions concernant l'optimisation des ressources à toute autre équipe impliquée dans un projet afin d'encourager la responsabilité 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 de l'optimisation des coûts et les recommandations à prendre en compte, consultez Google Cloud Well-Architected Framework : optimisation des coûts.

Transfert de données

Le transfert de données est un élément important à prendre en compte pour la planification d'une stratégie et d'une architecture hybrides 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 les données sont classées (pour les secteurs réglementés). Ils doivent également réfléchir à la façon dont le stockage, le partage et l'accès aux données pour les systèmes distribués dans les différents environnements peuvent affecter les performances des applications et la cohérence des données. Ces facteurs peuvent influencer l'architecture de l'application et du pipeline de données. L'ensemble complet d'options de transfert de données deGoogle Cloudpermet 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é axées sur le cloud, comme la cohérence, l'observabilité et la visibilité unifiée de la sécurité. Chaque fournisseur de cloud public a sa propre approche, ses propres bonnes pratiques et ses propres capacités en matière de sécurité. Il est important d'analyser et d'aligner ces capacités pour créer une architecture de sécurité standard et fonctionnelle. Des contrôles IAM stricts, le chiffrement des données, l'analyse des failles et la conformité avec les réglementations du secteur sont également des aspects importants de la sécurité du cloud.

Lorsque vous planifiez une stratégie de migration, nous vous recommandons d'analyser les points à prendre en compte mentionnés précédemment. Ils peuvent vous aider à minimiser les risques d'introduction de complexités dans l'architecture à mesure que vos applications ou vos 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 zones. 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 Conception de la 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 d'architecture d'une application peuvent être classés dans l'une des deux catégories suivantes : 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 d'application d'interface sont directement exposés aux utilisateurs finaux ou aux appareils. Par conséquent, ces applications sont souvent sensibles aux performances. Les mises à jour logicielles peuvent être fréquentes pour développer de nouvelles fonctionnalités et apporter des améliorations. Comme les applications frontend 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 de données limités.

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 dédiés au stockage et à la gestion des données. Dans certaines architectures, la logique métier peut être intégrée au composant de backend. Les applications backend ont tendance à être mises à jour moins souvent que les applications d'interface. Les applications de backend doivent relever les défis suivants :

• Gérer un grand nombre de demandes
• Gérer un grand volume de données
• Sécuriser les données
• Maintenir des données actuelles et à jour dans toutes les répliques du système

La solution d'application Web à trois niveaux est l'une des implémentations les plus populaires pour créer des applications Web d'entreprise, comme les sites Web d'e-commerce contenant différents composants d'application. Cette architecture contient les niveaux suivants. Chaque niveau fonctionne indépendamment, 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 backend

En plaçant ces couches dans des conteneurs, vous séparez leurs besoins techniques, comme les exigences de scaling, et vous pouvez 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 parGoogle Cloud, comme Cloud SQL, permettent de fournir le backend en tant que couche de base de données.

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 de l'application d'interface au cas par cas. Pour en savoir plus, consultez 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 du coût, du temps et des risques lié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. En retour, l'interface de l'application renvoie les données à l'environnement sur site où est hébergé le backend de l'application (idéalement via une passerelle d'API).

Avec le modèle d'architecture hybride par tranche, vous pouvez exploiter l'infrastructure et les services mondiaux deGoogle 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 surGoogle Cloud, consultez Créer une plate-forme d'e-commerce numérique sur Google Cloud.

Dans le schéma précédent, l'interface de l'application est hébergée surGoogle Cloud pour offrir une expérience utilisateur multirégionale et optimisée à l'échelle mondiale, qui utilise l'équilibrage de charge global, l'autoscaling et la protection DDoS 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 de backend vers le cloud public. Si vous prévoyez de diffuser un trafic important, opter pour des services gérés dans le cloud peut vous aider à économiser des efforts d'ingénierie lors de la gestion de votre propre infrastructure. Envisagez cette option, sauf si des contraintes ou des exigences imposent d'héberger les composants de l'application backend sur site. Par exemple, si vos données de 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 de backend ne dépendent pas des composants de 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 applications backend.
  • 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 YouTube How to port stateful web apps to Cloud Run (Comment migrer des applications Web avec état vers Cloud Run).

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 CI/CD pour envoyer des mises à jour de manière efficace et automatisée. Pour en savoir plus, consultez 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, 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 microfrontend, qui étendent les microservices aux composants frontend.

  L'extension des microservices est couramment utilisée avec les interfaces utilisateur qui impliquent la collaboration de plusieurs équipes sur la même application. Ce type de structure d'équipe nécessite une approche itérative et une maintenance continue. Voici quelques 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 l'interface utilisateur qui peuvent ê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 vous aident à :

  • 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 que 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 aborde les modèles de mise en réseau possibles pour activer une telle architecture. Apigee hybrid est une plate-forme permettant de créer et de gérer des proxys d'API dans un modèle de déploiement hybride. Pour en savoir plus, consultez Architecture faiblement couplée, 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:

• En fonction de l'évaluation des modèles de communication des applications identifiées, sélectionnez la solution de communication 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. Dans l'idéal, 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 des communications entre les environnements, sélectionnez une régionGoogle Cloud géographiquement proche de l'environnement informatique privé dans lequel sont hébergés les composants de backend de votre application. Pour en savoir plus, consultez 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 potentiellement 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 versGoogle Cloud par rapport au trafic sortant de Google Cloud. Toutefois, vous devez connaître le volume de transfert de données sortantes prévu quittant Google Cloud. Si vous prévoyez d'utiliser cette architecture à long terme avec des volumes de transfert de données sortantes élevés, 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 sortantes pour le trafic qui remplit 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, le VPN haute disponibilité sur Cloud Interconnect et MACsec pour Cloud Interconnect.

• Pour surmonter les incohérences dans les protocoles, les API et les mécanismes d'authentification entre différents backends, nous vous recommandons, le cas échéant, de déployer une passerelle ou un proxy API en tant que façade 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 de backend.
  • Facilite les journaux d'audit pour la communication entre toutes les applications multi-environnements et leurs composants découplés.
  • Agit comme une couche de communication intermédiaire entre les services anciens et modernisés.
    • Apigee et Apigee hybrid vous permettent d'héberger et de gérer des passerelles hybrides et de niveau entreprise dans des environnements sur site, en périphérie, dans d'autres clouds et dans des environnementsGoogle Cloud .

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

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

  • 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.
  • Utilisez 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 maillage de services pour sécuriser et contrôler la communication et l'exposition des services avec l'architecture des microservices.

  • Utilisez Cloud Service Mesh pour permettre la communication entre les services nécessaires au maintien de 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 aux entités externes d'utiliser ces services en les exposant sous forme d'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 charges de travail et d'applications 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.
• Le fait de traiter les API comme des interfaces de backend simplifie les intégrations, le développement de l'interface, les interactions de service et masque les complexités du système de backend. Pour relever ces défis, Apigee facilite le développement et la gestion des 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 les applications Web axées sur le contenu, plusieurs options sont disponibles, y compris les architectures monolithiques, sans serveur, basées sur des événements et de microservices. Pour sélectionner l'architecture la plus adaptée, évaluez minutieusement ces options en fonction des exigences actuelles et futures de votre application. Pour vous aider à prendre une décision architecturale qui correspond à vos objectifs commerciaux et techniques, consultez Comparaison de différentes architectures pour les backends d'applications Web axées sur le contenu et Points clés à 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 possibilité de moderniser les charges de travail, puis de migrer vers Google Cloud à différents moments. Cela peut être 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'utiliser les meilleures ressources disponibles dans chaque environnement. Dans tous les cas, GKE Enterprise peut être une technologie clé. Pour en savoir plus, consultez 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 d'anciens backends sur site 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 vers une architecture de microservices afin de moderniser l'architecture de votre application Web, consultez Introduction aux 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 à divers besoins de stockage de données. Cela dit, 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 axées sur le contenu et les modalités efficaces, consultez Options de stockage de données pour les applications Web axé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é combine plusieurs environnements de cloud public exploités par différents fournisseurs de services cloud. Cette architecture offre la flexibilité nécessaire pour déployer une application dans un environnement de calcul optimal qui tient compte des facteurs et des considérations multicloud abordés dans la première partie de cette série.

Le diagramme suivant illustre un modèle d'architecture multicloud partitionnée.

Ce modèle d'architecture peut être créé de deux manières différentes. La première approche consiste à déployer les composants de l'application dans différents environnements de cloud public. Cette approche est également appelée architecture composite et est identique à celle du modèle d'architecture hybride à plusieurs niveaux. Au lieu d'utiliser un environnement sur site avec un cloud public, il utilise au moins deux environnements cloud. Dans une architecture composite, une seule charge de travail ou application utilise des composants provenant de plusieurs clouds. La deuxième approche consiste à déployer différentes applications dans différents environnements de cloud public. La liste non exhaustive suivante décrit certains des moteurs commerciaux de la deuxième approche :

• Intégrer complètement les applications hébergées dans des environnements cloud disparates lors d'un scénario de fusion et acquisition entre deux entreprises.
• Pour favoriser la flexibilité et répondre aux diverses préférences cloud de votre organisation. Adoptez cette approche pour encourager les unités organisationnelles à choisir le fournisseur de services cloud qui répond le mieux à leurs besoins et préférences spécifiques.
• Pour fonctionner dans un déploiement multirégional ou mondial du cloud. Si une entreprise est tenue de respecter les réglementations sur la résidence des données dans des régions ou des pays spécifiques, elle doit choisir parmi les fournisseurs de services cloud disponibles dans cette zone géographique si son fournisseur de services cloud principal ne dispose pas d'une région cloud dans cette zone.

Avec le modèle d'architecture multicloud partitionné, vous pouvez, si vous le souhaitez, conserver la possibilité de déplacer les charges de travail d'un environnement cloud public à un autre selon les besoins. Dans ce cas, la portabilité de vos charges de travail devient une exigence clé. Lorsque vous déployez des charges de travail dans plusieurs environnements informatiques et que vous souhaitez conserver la possibilité de les déplacer, vous devez éliminer les différences entre les environnements. En utilisant GKE Enterprise, vous pouvez concevoir et créer une solution pour résoudre la complexité multicloud avec des postures de gouvernance, d'opérations et de sécurité cohérentes. Pour en savoir plus, consultez GKE Multi-Cloud.

Comme mentionné précédemment, il peut y avoir des raisons commerciales et techniques de combiner Google Cloud avec un autre fournisseur de cloud et de partitionner les charges de travail dans ces environnements de cloud. Les solutions multicloud vous offrent la flexibilité nécessaire pour migrer, créer et optimiser la portabilité des applications dans des environnements multicloud, tout en minimisant la dépendance vis-à-vis d'un fournisseur et en vous aidant à répondre aux exigences réglementaires. Par exemple, vous pouvez connecter Google Cloud Oracle Cloud Infrastructure (OCI) pour créer une solution multicloud qui exploite les capacités de chaque plate-forme à l'aide d'un Cloud Interconnect privé afin de combiner les composants exécutés dans OCI avec les ressources exécutées sur Google Cloud. Pour en savoir plus, consultez Google Cloud et "Oracle Cloud Infrastructure : exploiter tout le potentiel du multicloud". De plus, Cross-Cloud Interconnect facilite la connectivité dédiée à bande passante élevée entre Google Cloud et d'autres fournisseurs de services cloud compatibles. Vous pouvez ainsi concevoir et créer des solutions multicloud pour gérer un volume de trafic inter-cloud élevé.

Avantages

L'utilisation d'une architecture multicloud offre plusieurs avantages commerciaux et techniques, comme indiqué dans Facteurs, considérations, stratégie et approches. Il est toutefois essentiel de réaliser une évaluation détaillée de la faisabilité de chaque avantage potentiel. Votre évaluation doit tenir compte de tous les défis directs ou indirects associés, ou des éventuels obstacles, et de votre capacité à les surmonter efficacement. De plus, gardez à l'esprit que la croissance à long terme de vos applications ou services peut entraîner des complexités qui pourraient l'emporter sur les avantages initiaux.

Voici quelques avantages clés du modèle d'architecture multicloud partitionné :

• Dans les scénarios où vous pourriez avoir besoin de minimiser l'engagement auprès d'un seul fournisseur de services cloud, vous pouvez distribuer les applications sur plusieurs fournisseurs de services cloud. Par conséquent, vous pouvez réduire relativement le verrouillage fournisseur en ayant la possibilité de changer de forfait (dans une certaine mesure) entre vos fournisseurs de services cloud. Le cloud ouvert permet d'importer des fonctionnalités Google Cloud , comme GKE Enterprise, dans différents emplacements physiques. En étendant les capacité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 cloud principal ne dispose pas de région cloud ni de point de présence. Ce modèle est particulièrement utile lorsque vous utilisez une connectivité multicloud à haute capacité et à faible latence, comme Cross-Cloud Interconnect et CDN Interconnect avec un CDN distribué.

• Vous pouvez déployer des applications auprès de plusieurs fournisseurs cloud, d'une manière qui vous permet de choisir parmi les meilleurs services offerts par les différents fournisseurs.

• Le modèle d'architecture multicloud partitionné peut faciliter et accélérer les scénarios de fusion et d'acquisition, dans lesquels les applications et les services des deux entreprises peuvent être hébergés dans différents environnements de cloud public.

Bonnes pratiques

• Commencez par déployer une charge de travail non critique. Ce déploiement initial dans le cloud secondaire peut ensuite servir de modèle pour les futurs déploiements ou migrations. Toutefois, cette approche n'est probablement pas applicable dans les situations où la charge de travail spécifique est légalement ou réglementairement requise pour résider dans une région cloud spécifique, et où le fournisseur de cloud principal ne dispose pas d'une région dans le territoire requis.
• Minimisez les dépendances entre les systèmes exécutés dans différents environnements de cloud public, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances, réduire la disponibilité globale et potentiellement entraîner des frais de transfert de données sortantes supplémentaires.
• Pour éliminer les différences entre les environnements, envisagez d'utiliser des conteneurs et Kubernetes lorsque cela est possible et pris en charge par les applications.
• Assurez-vous que les pipelines CI/CD et les outils de déploiement et de surveillance sont cohérents dans l'ensemble des environnements cloud.
• Sélectionnez le modèle d'architecture réseau optimal qui fournit la solution de communication la plus efficace pour les applications que vous utilisez.
  • La communication doit être précise et contrôlée. Utilisez des API sécurisées pour exposer les composants de l'application.
  • En fonction de vos exigences commerciales et techniques spécifiques, envisagez d'utiliser le modèle d'architecture en maillage ou l'un des modèles de mise en réseau avec passerelle.
• Pour répondre à vos attentes en termes de disponibilité et de performances, concevez des systèmes offrant une haute disponibilité (HA) de bout en bout, une faible latence et des débits appropriés.

• Pour protéger les informations sensibles, nous vous recommandons de chiffrer toutes les communications en transit.

  • Si le chiffrement est requis au niveau de la connectivité, différentes options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, VPN haute disponibilité sur Cloud Interconnect et MACsec pour Cross-Cloud Interconnect.

• Si vous utilisez plusieurs CDN dans votre modèle d'architecture partitionnée multicloud et que vous insérez des fichiers de données volumineux dans votre autre CDN à partir de Google Cloud, pensez à utiliser les liaisons CDN Interconnect entre Google Cloud et les fournisseurs compatibles pour optimiser ce trafic et, potentiellement, son coût.

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

• Pour équilibrer efficacement les requêtes entre Google Cloud et une autre plate-forme cloud, vous pouvez utiliser Cloud Load Balancing. Pour en savoir plus, consultez Router le trafic vers un emplacement sur site ou un autre cloud.

  • Si le volume de transfert de données sortantes de Google Cloudvers d'autres environnements est élevé, envisagez d'utiliser Cross-Cloud Interconnect.

• Pour surmonter les incohérences dans les protocoles, les API et les mécanismes d'authentification entre différents backends, nous vous recommandons, le cas échéant, de déployer une passerelle ou un proxy API en tant que façade 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 de backend.
  • Facilite les journaux d'audit pour la communication entre toutes les applications multi-environnements et leurs composants découplés.
  • Agit comme une couche de communication intermédiaire entre les services anciens et modernisés.
    • Apigee et Apigee hybrid vous permettent d'héberger et de gérer des passerelles hybrides et de niveau entreprise dans des environnements sur site, en périphérie, dans d'autres clouds et dans des environnementsGoogle Cloud .

• Dans certains des cas suivants, l'utilisation de Cloud Load Balancing avec une passerelle API peut fournir une solution robuste et sécurisée pour gérer, sécuriser et distribuer le trafic API à grande échelle dans plusieurs régions :

  • Déployer un basculement multirégional pour les runtimes d'API Apigee dans différentes régions.

  • Améliorer les performances avec Cloud CDN

  • Fournir une protection WAF et DDoS via Google Cloud Armor.

• Utilisez des outils cohérents pour la journalisation et la surveillance dans les environnements cloud, dans la mesure du possible. Vous pouvez envisager d'utiliser des systèmes de surveillance Open Source. Pour en savoir plus, consultez Modèles de surveillance et de journalisation hybrides et multicloud.

• Si vous déployez des composants d'application de manière distribuée, où les composants d'une même application sont déployés dans plusieurs environnements cloud, consultez les bonnes pratiques pour le modèle d'architecture hybride par tranche.

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 séparation 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 analytiques 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 les 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 dansGoogle 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 possibles en montrant 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 transférer vos données vers Google Cloud et en tirer de la valeur, 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 indiqué dans le diagramme précédent, la connexion de Google Cloud avec des environnements sur site et d'autres environnements cloud peut permettre 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 sur site et à d'autres fournisseurs de services cloud.

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 versGoogle 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 déplacement de données sur Google Cloud proposent une suite complète de produits permettant de déplacer, d'intégrer et de transformer des données de différentes manières, de manière fluide.
  • 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 décloisonner vos données. L'utilisation d'un data 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 de 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 Présentation des sources de données externes.

Bonnes pratiques

Pour mettre en œuvre le modèle d'architecture d'analyse hybride et multicloud, 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 les modèles de transfert et 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. Ces deux services de traitement de données cloud sont entièrement gérés et 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 (comme 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, lorsque cela est applicable et conforme.

• 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 Migration vers Google Cloud : transférer vos ensembles de données volumineux.

• Si vous devez transférer ou échanger des données entre Google Cloud et d'autres clouds à long terme avec un volume de trafic élevé, vous devez envisager d'utiliser Google Cloud Cross-Cloud Interconnect pour établir une connectivité dédiée à bande passante élevée entreGoogle Cloud et d'autres fournisseurs de services cloud (disponible dans certaines zones géographiques).

• Si le chiffrement est requis au niveau de la connectivité, différentes options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, 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

Pour exécuter des charges de travail dans le cloud, les clients doivent disposer d'une connectivité Internet rapide et fiable dans certains scénarios. 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 :

• 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 garanties de disponibilité offertes par 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 les charges de travail urgentes et stratégiques localement, à la périphérie du réseau, tout en utilisant le cloud pour tous les autres types de 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

Le fait d'exécuter certaines charges de travail à la périphérie et d'autres dans le cloud offre plusieurs avantages :

• Le trafic entrant (transfert de données de la périphérie versGoogle 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 en local. 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'informatique en périphérie 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 d'API conteneurisée telle qu'Apigee hybrid. Cela permet aux applications et systèmes anciens de s'intégrer aux services modernisés, comme 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 périphériques se connectant àGoogle Cloud sur l'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 partenaireGoogle 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, le cas échéant et si possible, pour éliminer les différences entre les divers 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 la périphérie et le cloud.
  • 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 en périphérie à Google Cloud.
• Dans ce modèle, bien que certains composants GKE Enterprise puissent fonctionner en cas d'interruption temporaire de la connectivité àGoogle Cloud, n'utilisez pas GKE Enterprise lorsqu'il est déconnecté de Google Cloud comme mode de fonctionnement nominal. Pour en savoir plus, consultez Impact d'une déconnexion temporaire de Google Cloud.
• Pour surmonter les incohérences dans les protocoles, les API et les mécanismes d'authentification entre les différents services de backend et de périphérie, nous vous recommandons, le cas échéant, de déployer une passerelle ou un proxy d'API 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 de backend.
  • Facilite les journaux d'audit pour la communication entre toutes les applications multi-environnements et leurs composants découplés.
  • Agit comme une couche de communication intermédiaire entre les services anciens et modernisés.
    • Apigee et Apigee hybrid vous permettent d'héberger et de gérer des passerelles hybrides et de niveau entreprise dans des environnements sur site, en périphérie, dans d'autres clouds et dans des environnementsGoogle Cloud .
• É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. Le déploiement vise à 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. Il est possible qu'elles ne s'appliquent 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 des systèmes de production peut sembler risqué et aller à l'encontre des bonnes pratiques existantes ou des tentatives visant à minimiser les différences entre de tels 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 d'applications nouvelles ou mises à jour.

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.

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 que vos procédures de déploiement d'application fonctionnent comme prévu. Dès lors qu'une version atteint un environnement de préproduction, vos tests fonctionnels devraient être terminés. La préproduction est la dernière étape avant le déploiement du 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 l'illustre le schéma suivant, les environnements de test et de développement sont basé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 et la même version de base de données dans l'environnement sur site, une version fonctionnellement équivalente 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 de test de charge des performances n'est pas valide.

Les scénarios suivants peuvent s'accorder bien avec le 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 si 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 Zero Trust, vous pouvez contrôler et maintenir la séparation requise des communications 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 correspond à vos exigences spécifiques, basez vos choix sur une évaluation approfondie des besoins et des contraintes de votre entreprise.
• Différences entre les environnements : dans 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 l'inspection du trafic).
• Gouvernance : 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'existe 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. Ils doivent être conformes aux normes d'assurance qualité des logiciels de votre organisation. Appliquez ces normes à toutes les applications que vous développez et testez.
• Redondance : bien que 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 capacités redondantes et de la possibilité de tester différents scénarios d'échec. Vos exigences concernant les scénarios d'échec peuvent vous amener à inclure la redondance dans la conception de 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 machines virtuelles (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 d'extraction. Cela réduit également les frais généraux 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 concevoir votre architecture réseau afin d'empêcher les communications directes entre les systèmes de différents environnements. Si la communication entre les environnements est nécessaire, elle doit être contrôlée.

• La stratégie de déploiement et de test des applications 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 des fonctionnalités progressivement dans un environnement ou un groupe d'utilisateurs spécifiques avant de les rendre disponibles à plus grande échelle.

• 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.

• Mettez en place une chaîne d'outils commune qui fonctionne dans plusieurs environnements informatiques pour déployer, configurer et utiliser 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 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 Déployer et sécuriser votre application exposée à Internet en moins d'une heure à l'aide de la boîte à outils Dev(Sec)Ops.

• Utilisez les mêmes outils pour la journalisation et la surveillance dans Google Cloudet les environnements cloud existants. Envisagez d'utiliser des systèmes de surveillance Open Source. Pour en savoir plus, consultez Modèles de surveillance et de journalisation hybrides et multicloud.

• Si différentes équipes gèrent les charges de travail de test et de production, il peut être acceptable dans ce cas d'utiliser des outils distincts. Toutefois, l'utilisation des mêmes outils avec des autorisations d'affichage différentes peut vous aider à réduire l'effort de formation et la complexité.

• 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 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 indique les produits Google Cloud compatibles avec les produits OSS courants.

Produit OSS	Compatible avec le produit Google Cloud
Apache HBase	Bigtable
Apache Beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL, PostgreSQL	Cloud SQL
Redis Cluster, Redis, 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 opérations pour les systèmes stratégiques est d'aider une organisation à être résiliente et à poursuivre ses opérations commerciales pendant et après des événements de défaillance. 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 grave défaillance du système, une attaque de cybersécurité ou même une erreur de configuration du système.

Il est essentiel d'optimiser un système pour qu'il résiste aux défaillances afin d'assurer une continuité des activités efficace. La fiabilité d'un système peut être influencée par plusieurs facteurs, y compris, mais sans s'y limiter, les performances, la résilience, la disponibilité du temps d'activité, la sécurité et l'expérience utilisateur. Pour en savoir plus sur la conception et l'exploitation de services fiables surGoogle Cloud, consultez le pilier Fiabilité du Google Cloud Well-Architected Framework 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é des activités peut être définie comme la capacité d'une organisation à poursuivre ses fonctions ou services clés à des niveaux acceptables prédéfinis à la suite d'un événement perturbateur.

La reprise après sinistre est considérée comme un sous-ensemble de la continuité des activités. Elle vise explicitement à garantir que les systèmes informatiques assurant des fonctions métier critiques sont opérationnels dès que possible après une interruption. 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 commercial doit définir deux métriques clés : l'objectif de point de récupération (RPO) et l'objectif de temps de récupération (RTO). 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 un coût plus élevé, car cela signifie qu'il faut créer des systèmes redondants. Les systèmes redondants capables d'effectuer une réplication des données quasiment en temps réel et fonctionnant à la même échelle après un événement d'échec augmentent la complexité, les frais administratifs et les coûts.

La décision de sélectionner une stratégie ou un modèle de reprise après sinistre doit être basée sur une analyse de l'impact commercial. Par exemple, les pertes financières subies par une organisation de services financiers, même en cas de quelques minutes d'indisponibilité, peuvent dépasser de loin le coût de l'implémentation d'un système de reprise après sinistre. Toutefois, les entreprises d'autres secteurs peuvent supporter 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 Continuité d'activité hybride. Le cloud peut être particulièrement intéressant d'un point de vue financier, 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 à moindre coût, 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 reprise après sinistre ou de basculement vers 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.

L'évaluation d'une reprise après sinistre sur plusieurs clouds par rapport à l'utilisation d'un seul fournisseur de 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 depuis plusieurs fournisseurs de services cloud peuvent être coûteux en cas de communication inter-cloud continue.
  • La réplication de bases de données peut générer un volume de trafic élevé.
  • le coût total de possession et le coût de gestion de l'infrastructure réseau multicloud.

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 de services cloud situé dans votre pays comme solution de reprise après sinistre. 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 restructurer votre solution cloud, votre deuxième fournisseur de services cloud doit idéalement proposer toutes les fonctionnalités et tous les services requis dans la région.

Considérations de conception

• Attentes en matière de reprise après sinistre : les objectifs de RPO et de RTO que votre entreprise souhaite atteindre doivent orienter votre architecture de reprise après sinistre et la planification de la création.
• Architecture de la solution : avec ce modèle, vous devez répliquer les fonctions et les capacité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é de l'hébergement, de la refactorisation ou de la réarchitecture de vos applications afin de fournir les mêmes fonctions et performances (ou des fonctions et performances plus optimisées) dans l'environnement cloud.
• Concevez et créez : 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 Conception de la zone d'atterrissage 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 reprise après sinistre 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é ? Le processus d'approbation est-il manuel ou peut-il être automatisé pour atteindre un faible délai de reprise après sinistre ?
  • Comment concevoir les mécanismes de détection et de notification des défaillances système pour déclencher le basculement conformément au délai de reprise attendu ?
  • Comment le trafic est-il redirigé vers l'environnement de reprise après sinistre une fois la défaillance détectée ?

  Validez vos réponses à ces questions en effectuant des 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 peut vous donner plus d'assurance pour invoquer la reprise après sinistre si nécessaire. Chaque fois qu'une nouvelle modification ou mise à jour est apportée au processus ou à la solution technologique, effectuez à nouveau les tests.

• Compétences de l'é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 offre 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 biré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 des 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 une réplication plus rapide avec un RPO plus faible, les objets stockés dans des emplacements birégionaux peuvent éventuellement utiliser la réplication turbo entre 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 région multiple.
• Fournit une ou plusieurs des options suivantes pour réduire les dépenses en capital et les dépenses d'exploitation 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 signifie que vous ne payez 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'adapter automatiquement la taille de votre environnement de reprise après sinistre selon vos besoins.

Par exemple, le schéma suivant montre une application exécutée dans un environnement sur site (production) qui utilise des composants de récupération surGoogle 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 une VM ou d'une base de données gérée Google Cloud , comme Cloud SQL, pour une récupération plus rapide avec une réplication continue des données. 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 d'échec, 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'invocation d'une reprise après sinistre, de provisionnement de la charge de travail dans le cloud et de redirection 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 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.
• En fonction de votre analyse de l'impact commercial et des objectifs RPO et RTO requis identifiés, envisagez les actions suivantes :
  • 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 maillé peut être une bonne option pour répliquer 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 séparation peut amener les systèmes des deux environnements à conclure que l'autre environnement n'est pas disponible et qu'ils disposent d'un accès exclusif aux données. Cela peut entraîner des modifications conflictuelles des données. Il existe deux façons courantes d'éviter le problème de split-brain :

  • Utilisez un environnement informatique tiers. 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 Reprise après sinistre pour les bases 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 (lorsque les applications le permettent et que cela est faisable) afin que les systèmes restent cohérents dans tous les environnements. Vous pouvez y parvenir en utilisant 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. Vous pourrez ainsi rediriger les utilisateurs vers des systèmes de secours en cas de sinistre.

• Sélectionnez la règle DNS et la règle de routage qui correspondent à l'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 entre les environnements sur site et cloud grâce à une configuration DNS multiproviders.

    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 DNS public multiproviders avec Cloud DNS.

• Lorsque vous utilisez des systèmes de secours, créez un basculement automatique à l'aide d'équilibreurs de charge. 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 certains scénarios qui se produisent lorsque vous utilisez ce modèle d'architecture. Les requêtes de clients internes ou les requêtes de clients 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 répartition du trafic basée sur le poids. Pour en savoir plus, consultez la 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 sortantes 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 sortantes pour le trafic qui remplit 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 réplications de données, ainsi que d'autres tâches qui répondent à vos exigences, y compris vos objectifs de RPO et de RTO.

• Testez et évaluez les scénarios d'invocation de la reprise après sinistre pour comprendre dans quelle mesure l'application peut se remettre d'un sinistre par rapport à la valeur 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 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è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'accroître la capacité, 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 schéma ci-dessus, lorsque la capacité de données est à sa limite dans un environnement privé sur site, le système peut obtenir une capacité supplémentaire à partir d'un environnementGoogle Cloud si nécessaire.

Les principaux moteurs de ce modèle sont les économies d'argent et la réduction du temps et des efforts nécessaires pour répondre aux changements d'exigences de mise à l'échelle. Avec cette approche, vous ne payez que les ressources utilisées pour gérer les charges supplémentaires. Cela signifie que vous n'avez pas besoin de surprovisionner votre infrastructure. Vous pouvez plutôt profiter des ressources cloud à la demande et les adapter à la demande et à toutes les métriques prédéfinies. Votre entreprise peut ainsi éviter les interruptions de service pendant les périodes de forte demande.

La portabilité des charges de travail est une condition essentielle 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 différents environnements qui utilisent des infrastructures différentes. 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 doivent également initier l'augmentation ou la diminution 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 capables de procéder au suivi des ressources pourrait 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 pour suivre les 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 des clients internes ou les requêtes des clients externes vers des backends situés à la fois sur site et dansGoogle 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 effectuer un scaling des 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 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'utilisation des fonctionnalités de protection DDoS de Google Cloud Armor, du WAF et de la mise en cache du contenu en périphérie du cloud à 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 minimes 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 d'infrastructures de calcul ou de mise en réseau sous-jacentes, ainsi que la proximité de services dépendants, déterminent généralement les performances. Les tests vous permettent d'obtenir une visibilité plus précise et de 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 périodes de forte demande :

  • Utilisez des outils cohérents pour surveiller et gérer ces deux environnements.
  • Assurez-vous que le versionnage des charges de travail est cohérent et que vos sources de données sont à jour.
  • Vous devrez peut-être ajouter de l'automatisation pour provisionner l'environnement cloud et rediriger le trafic lorsque la demande augmente et que la charge de travail cloud est censée 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 charge du 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 être diffusées aux utilisateurs.
  • Les mises à jour DNS ont tendance à se propager lentement sur Internet.

  En conséquence :

  • Les utilisateurs peuvent être routés vers l'environnement Cloud même lorsqu'aucune ressource n'est disponible pour traiter leurs requêtes.
  • Il est possible que les utilisateurs continuent d'être redirigés temporairement vers l'environnement sur site pendant la propagation des mises à jour DNS sur Internet.

Avec Cloud DNS, vous pouvez choisir la stratégie DNS et la stratégie de routage qui correspondent à l'architecture et au comportement de votre solution, comme les stratégies de routage DNS par géolocalisation. Cloud DNS accepte également les vérifications d'é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 général de l'équilibreur de charge d'application interne, qui vérifie lui-même l'état des instances backend. Pour en savoir plus, consultez Gérer les règles de routage DNS et les vérifications de l'état.

Vous pouvez également utiliser le DNS fractionné Cloud DNS. L'horizon partagé 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écifiques de l'auteur de la requête DNS pour le même nom de domaine. Cette approche est couramment utilisée pour répondre aux exigences selon lesquelles une application est conçue pour offrir 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 Cloud Bursting :

• 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'aurez 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 les 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 de sécurité du moindre privilège. Si la conception de la charge de travail le permet, vous pouvez autoriser l'accès uniquement du cloud vers l'environnement informatique sur site, et non l'inverse.
• Pour minimiser la latence des communications entre les environnements, choisissez une régionGoogle Cloud géographiquement proche de votre environnement informatique privé. Pour en savoir plus, consultez 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 de la charge de travail.

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

  • Dans ce modèle, vous pouvez appliquer la conception de vos règles DNS de manière permanente ou lorsque vous avez besoin de capacité supplémentaire en utilisant un autre environnement pendant les périodes de forte 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 tactique 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 où la région Google Cloud existe.

  • Si vous devez fournir des enregistrements différents pour les mêmes requêtes DNS, vous pouvez utiliser le DNS fractionné (par exemple, 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. Vous pourrez ainsi rediriger les utilisateurs vers des systèmes de secours lorsque vous aurez besoin de capacité supplémentaire à l'aide d'environnements cloud.

• Pour les tâches qui ne sont pas urgentes et qui ne stockent pas de données en local, envisagez d'utiliser des instances de VM spot, qui sont nettement moins chères que les instances de VM classiques. Toutefois, une condition préalable est que, si la VM est préemptée, le système doit pouvoir redémarrer automatiquement le job.

• Assurez la portabilité des charges de travail à l'aide de conteneurs, 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 élevé de transfert de données sortantes, 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 sortantes pour le trafic qui remplit certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.

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

• 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 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 : prochaines étapes

• 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.