Créer des architectures hybrides et multicloud à l'aide de Google Cloud

Last reviewed 2024-11-27 UTC

Ce guide d'architecture fournit des conseils pratiques pour planifier et concevoir l'architecture de vos environnements hybrides et multicloud à l'aide de Google Cloud. Ce document est le premier d'un ensemble de trois. Il examine les opportunités et les considérations associées à ces architectures d'un point de vue commercial et technologique. Il analyse et présente également de nombreux modèles d'architecture hybride et multicloud éprouvés.

L'ensemble de documents sur les modèles d'architecture hybride et multicloud se compose des parties suivantes :

Vous pouvez lire chacun de ces articles sur l'architecture de manière indépendante, mais pour en tirer le meilleur parti, nous vous recommandons de les lire dans l'ordre avant de prendre une décision architecturale.

L'évolution rapide des exigences du marché a entraîné une hausse du niveau d'exigence et des attentes relatives à l'informatique d'entreprise, comme la mise à l'échelle dynamique, l'amélioration des performances pour une expérience utilisateur optimisée et la sécurité. De nombreuses entreprises de niveau Enterprise ont du mal à répondre à ces exigences et attentes en utilisant uniquement des infrastructures et des processus traditionnels. Les services informatiques sont également soumis à la pression d'améliorer leur rentabilité, ce qui rend difficile la justification d'investissements en capital supplémentaires dans les centres de données et les équipements.

Une stratégie de cloud hybride qui utilise les capacités de cloud computing public fournit une solution pragmatique. En utilisant le cloud public, vous pouvez étendre la capacité et les fonctionnalités de vos plates-formes de calcul sans dépenses d'investissement initiales.

En ajoutant une ou plusieurs solutions basées sur le cloud public, comme Google Cloud, à votre infrastructure existante, vous préservez non seulement vos investissements existants, mais vous évitez aussi de vous engager auprès d'un seul fournisseur de cloud. De plus, une stratégie hybride vous permet de moderniser les applications et les processus de façon progressive, dans la mesure des ressources disponibles.

Pour vous aider à planifier votre décision architecturale et votre stratégie hybride ou multicloud, vous devez tenir compte de plusieurs défis potentiels et considérations de conception. Ce guide d'architecture en plusieurs parties met en évidence les avantages et les défis potentiels de diverses architectures.

Présentation du cloud hybride et du multicloud

Les charges de travail, l'infrastructure et les processus étant propres à chaque entreprise, toute stratégie cloud hybride doit être adaptée en fonction des besoins spécifiques. C'est pourquoi les termes cloud hybride et multicloud sont parfois utilisés de manière incohérente.

Dans le contexte de ce guide d'architecture Google Cloud , le terme cloud hybride désigne une architecture dans laquelle les charges de travail sont déployées dans plusieurs environnements informatiques, l'un étant basé dans le cloud public et au moins un autre étant privé (par exemple, un centre de données sur site ou une installation de colocation).

Le terme multicloud désigne une architecture combinant au moins deux CSP publics. Comme l'illustre le schéma suivant, cette architecture inclut parfois un environnement de calcul privé (qui peut inclure l'utilisation d'un composant de cloud privé). Cette organisation s'appelle une architecture hybride et multicloud.

Schéma des trois architectures abordées dans cette série: hybrides, multicloud, et une combinaison d'architectures hybrides et multicloud.

Contributeurs

Auteur : Marwan Al Shawi | Partner Customer Engineer

Autres contributeurs :

Facteurs, considérations, stratégie et approches

Ce document définit et aborde les objectifs, les moteurs et les exigences métier, et explique comment ces facteurs peuvent influencer vos décisions de conception lorsque vous créez des architectures hybrides et multicloud.

Objectifs

Une organisation peut adopter une architecture hybride ou multicloud comme solution permanente pour atteindre des objectifs commerciaux spécifiques, ou comme état temporaire pour répondre à certaines exigences, comme une migration vers le cloud.

Répondre aux questions suivantes sur votre entreprise est un bon moyen de définir vos exigences commerciales et d'établir des attentes spécifiques sur la façon d'atteindre tout ou partie de vos objectifs commerciaux. Ces questions portent sur les besoins de votre entreprise, et non sur la manière de les satisfaire techniquement.

  • Quels objectifs commerciaux motivent la décision d'adopter une architecture hybride ou multicloud ?
  • Quels objectifs commerciaux et techniques une architecture hybride ou multicloud va-t-elle vous aider à atteindre ?
  • Quels facteurs commerciaux ont influencé ces objectifs ?
  • Quels sont les besoins spécifiques de l'entreprise ?

Dans le contexte des architectures hybrides et multicloud, un objectif commercial pour un client Enterprise peut être d'étendre ses opérations ou ses marchés de vente en ligne d'une seule région pour devenir l'un des leaders mondiaux de son segment de marché. L'un des objectifs commerciaux peut être de commencer à accepter les bons de commande des utilisateurs du monde entier (ou de régions spécifiques) d'ici six mois.

Pour répondre aux exigences et objectifs commerciaux mentionnés précédemment, l'un des principaux objectifs techniques potentiels consiste à étendre l'infrastructure informatique et l'architecture d'applications d'une entreprise, en passant d'un modèle uniquement sur site à une architecture hybride, à l'aide des capacités et services mondiaux des clouds publics. Cet objectif doit être spécifique et mesurable, et définir clairement le champ d'expansion en termes de régions cibles et de délais.

En général, une architecture hybride ou multicloud est rarement un objectif en soi, mais plutôt un moyen de répondre à des objectifs techniques dictés par certaines exigences commerciales. Choisir la bonne architecture hybride ou multicloud nécessite donc une mise au clair préalable de ces exigences.

Il est important de faire la différence entre les objectifs commerciaux et techniques de votre projet informatique. Vos objectifs commerciaux doivent être axés sur l'objectif et la mission de votre organisation. Vos objectifs techniques doivent être axés sur la création d'une base technologique permettant à votre organisation de répondre à ses exigences et objectifs commerciaux.

Les facteurs commerciaux influencent la réalisation des objectifs commerciaux. Par conséquent, identifier clairement les facteurs commerciaux peut aider à définir des objectifs commerciaux plus adaptés aux besoins et aux tendances du marché.

L'organigramme suivant illustre les moteurs commerciaux, les buts, les objectifs et les exigences, ainsi que les objectifs et les exigences techniques, et la façon dont tous ces facteurs sont liés les uns aux autres :

Organigramme montrant les éléments à prendre en compte lors de l'élaboration des exigences techniques, y compris les facteurs de développement, les buts, les objectifs et les exigences commerciales, ainsi que les objectifs techniques.

Facteurs commerciaux et techniques

Réfléchissez à la façon dont vos moteurs commerciaux influencent vos objectifs techniques. Voici quelques facteurs stratégiques courants qui influencent le choix d'une architecture hybride :

  • respecter les lois et règlements relatifs à la souveraineté des données ;
  • Réduire les dépenses en capital (CAPEX) ou les dépenses informatiques générales grâce aux disciplines de gestion financière et d'optimisation des coûts dans le cloud, comme FinOps.
    • L'adoption du cloud peut être motivée par des scénarios qui contribuent à réduire les dépenses d'investissement, comme la création d'une solution de reprise après sinistre dans une architecture hybride ou multicloud.
  • Améliorer l'expérience utilisateur.
  • Augmenter la flexibilité et l'agilité pour répondre aux nouvelles exigences du marché
  • améliorer la transparence en matière de coûts et de consommation de ressources ;

Examinez ensemble votre liste de facteurs commerciaux pour l'adoption d'une architecture hybride ou multicloud. Ne les considérez pas de manière isolée. Votre décision finale doit dépendre de l'équilibre de vos priorités commerciales.

Une fois que votre organisation aura constaté les avantages du cloud, elle pourra décider de migrer complètement si aucune contrainte (comme les coûts ou les exigences de conformité spécifiques qui nécessitent l'hébergement sur site de données hautement sécurisées) ne l'en empêche.

Bien que l'adoption d'un fournisseur de services cloud unique puisse offrir plusieurs avantages, tels qu'une complexité réduite, des intégrations intégrées entre les services et des options d'optimisation des coûts comme les remises pour utilisation engagée, il existe encore des scénarios dans lesquels une architecture multicloud peut être bénéfique pour une entreprise. Voici les facteurs stratégiques courants pour l'adoption d'une architecture multicloud, ainsi que les considérations associées pour chaque facteur :

  • Respecter les lois et règlements relatifs à la souveraineté des données : le scénario le plus courant est celui où une organisation étend son activité à une nouvelle région ou un nouveau pays et doit se conformer à de nouvelles réglementations sur l'hébergement des données.
    • Si le fournisseur de services cloud (CSP) utilisé actuellement ne dispose d'aucune région cloud locale dans le pays concerné, la solution courante pour assurer la conformité consiste à utiliser un autre CSP qui dispose d'une région cloud locale dans ce pays.
  • Réduction des coûts : la réduction des coûts est souvent le moteur commercial le plus courant pour l'adoption d'une technologie ou d'une architecture. Toutefois, il est important de prendre en compte plus que le coût des services et les remises potentielles sur les prix lorsque vous décidez d'adopter une architecture multicloud. Tenez compte du coût de création et d'exploitation d'une solution sur plusieurs clouds, ainsi que des contraintes d'architecture qui pourraient découler des systèmes existants.

Parfois, les défis potentiels associés à une stratégie multicloud peuvent l'emporter sur les avantages. Une stratégie multicloud peut entraîner des coûts supplémentaires par la suite.

Voici quelques-uns des défis courants associés au développement d'une stratégie multicloud :

  • La complexité de la gestion augmente.
  • Maintenir une sécurité cohérente.
  • Intégrer des environnements logiciels.
  • Obtenir des performances et une fiabilité cohérentes dans plusieurs clouds.
  • La création d'une équipe technique possédant des compétences multicloud peut être coûteuse et nécessiter l'expansion de l'équipe, sauf si elle est gérée par une entreprise tierce.
  • Gérer les outils de tarification et de gestion des produits de chaque CSP
    • Sans une solution capable de fournir une visibilité unifiée sur les coûts et des tableaux de bord, il peut être difficile de gérer efficacement les coûts dans plusieurs environnements. Dans ce cas, vous pouvez utiliser la solution Looker de gestion des coûts cloud, le cas échéant. Pour en savoir plus, consultez Stratégie pour optimiser efficacement la gestion des coûts de facturation cloud.
  • Utiliser les fonctionnalités uniques de chaque CSP : une architecture multicloud permet aux entreprises d'utiliser de nouvelles technologies supplémentaires pour améliorer leurs propres offres de fonctionnalités métier sans être limitées aux choix proposés par un seul fournisseur de services cloud.
    • Pour éviter tout risque ou toute complexité imprévus, évaluez vos défis potentiels à l'aide d'une évaluation de la faisabilité et de l'efficacité, y compris les défis courants mentionnés précédemment.
  • Éviter la dépendance vis-à-vis d'un fournisseur : parfois, les entreprises souhaitent éviter de dépendre d'un seul fournisseur de services cloud. Une approche multicloud leur permet de choisir la solution la mieux adaptée à leurs besoins commerciaux. Toutefois, la faisabilité de cette décision dépend de plusieurs facteurs, tels que les suivants :
    • Dépendances techniques
    • Remarques sur l'interopérabilité entre les applications
    • Coûts de reconstruction ou de refactorisation des applications
    • Compétences techniques
    • Sécurité et facilité de gestion cohérentes
  • Améliorer le niveau de fiabilité et de disponibilité des applications critiques : dans certains cas, une architecture multicloud peut offrir une résilience aux pannes. Par exemple, si une région d'un CSP est indisponible, le trafic peut être acheminé vers un autre CSP de la même région. Ce scénario suppose que les deux fournisseurs de services cloud sont compatibles avec les fonctionnalités ou services requis dans cette région.

Lorsque les réglementations sur la résidence des données dans un pays ou une région spécifiques imposent le stockage de données sensibles (comme les informations permettant d'identifier personnellement les utilisateurs) dans cet emplacement, une approche multicloud peut fournir une solution conforme. En utilisant deux CSP dans une même région pour assurer la résilience en cas de panne, vous pouvez faciliter la conformité avec les restrictions réglementaires tout en répondant aux exigences de disponibilité.

Voici quelques points à prendre en compte concernant la résilience avant d'adopter une architecture multicloud :

  • Transfert de données : à quelle fréquence les données peuvent-elles être transférées dans votre environnement multicloud ?
    • Le transfert de données peut-il entraîner des frais importants ?
  • Sécurité et facilité de gestion : y a-t-il des problèmes potentiels de sécurité ou de facilité de gestion ?
  • Parité des fonctionnalités : les deux CSP de la région sélectionnée proposent-ils les fonctionnalités et les services requis ?
  • Compétences techniques : l'équipe technique possède-t-elle les compétences requises pour gérer une architecture multicloud ?

Tenez compte de tous ces facteurs lorsque vous évaluez la faisabilité de l'utilisation d'une architecture multicloud pour améliorer la résilience.

Lorsque vous évaluez la faisabilité d'une architecture multicloud, il est important de tenir compte des avantages à long terme. Par exemple, le déploiement d'applications sur plusieurs clouds pour la reprise après sinistre ou l'augmentation de la fiabilité peut augmenter les coûts à court terme, mais peut éviter les pannes ou les défaillances. Ces échecs peuvent entraîner des dommages financiers et de réputation à long terme. Par conséquent, il est important de comparer les coûts à court terme à la valeur potentielle à long terme de l'adoption du multicloud. De plus, la valeur potentielle à long terme peut varier en fonction de la taille de l'organisation, de l'ampleur de la technologie, de la criticité de la solution technologique et du secteur.

Les entreprises qui prévoient de créer un environnement hybride ou multicloud doivent envisager de créer un centre d'excellence cloud (COE) pour le cloud. Une équipe COE peut servir de canal pour transformer la façon dont les équipes internes de votre organisation servent l'entreprise lors de votre transition vers le cloud. Un COE est l'un des moyens dont dispose votre organisation pour adopter le cloud plus rapidement, favoriser la standardisation et maintenir un alignement plus fort entre votre stratégie commerciale et vos investissements cloud.

Si l'objectif de l'architecture hybride ou multicloud est de créer un état temporaire, les facteurs stratégiques courants incluent :

  • La nécessité de réduire les dépenses d'investissement ou les dépenses informatiques générales pour les projets à court terme.
  • La capacité à provisionner rapidement une telle infrastructure pour prendre en charge un cas d'utilisation métier. Exemple :
    • Cette architecture peut être utilisée pour des projets à durée limitée. Il peut être utilisé pour prendre en charge un projet qui nécessite une infrastructure distribuée à grande échelle pendant une durée limitée, tout en utilisant des données sur site.
  • La nécessité de mener des projets de transformation numérique pluriannuels qui exigent d'une grande entreprise qu'elle établisse et utilise une architecture hybride pendant un certain temps pour l'aider à aligner la modernisation de son infrastructure et de ses applications sur ses priorités commerciales.
  • La nécessité de créer une architecture hybride, multicloud ou mixte temporaire après une fusion d'entreprises. Cela permet à la nouvelle organisation de définir une stratégie pour l'état final de sa nouvelle architecture cloud. Il est courant que deux entreprises qui fusionnent utilisent des fournisseurs de services cloud différents, ou qu'une entreprise utilise un centre de données privé sur site et l'autre le cloud. Dans les deux cas, la première étape d'une fusion-acquisition consiste presque toujours à intégrer les systèmes informatiques.

Facteurs techniques

La section précédente traitait des facteurs commerciaux. Pour être approuvées, les décisions architecturales majeures ont presque toujours besoin du soutien de ces pilotes. Toutefois, les facteurs techniques, qui peuvent être basés sur un gain ou une contrainte technique, peuvent également influencer les facteurs commerciaux. Dans certains cas, il est nécessaire de traduire les facteurs techniques en facteurs commerciaux et d'expliquer comment ils peuvent affecter l'entreprise de manière positive ou négative.

La liste non exhaustive suivante contient quelques facteurs techniques courants pour l'adoption d'une architecture hybride ou multicloud :

  • Développer des capacités technologiques, telles que des services d'analyse avancés et l'IA, qui peuvent être difficiles à mettre en place dans les environnements existants.
  • améliorer la qualité et les performances du service ;
  • Automatiser et accélérer les déploiements d'applications afin de réduire le temps de production et la durée des cycles
  • Utiliser des API et des services de haut niveau pour accélérer le développement
  • Accélérer le provisionnement des ressources de calcul et de stockage
  • Utiliser des services sans serveur pour créer des services et des fonctionnalités élastiques plus rapidement et à grande échelle.
  • Utiliser les capacités de l'infrastructure mondiale pour créer des architectures mondiales ou multirégionales afin de répondre à certaines exigences techniques.

Le facteur technique le plus courant pour les architectures hybrides et multicloud temporaires est de faciliter la migration d'un environnement sur site vers le cloud ou vers un cloud supplémentaire. En général, les migrations vers le cloud mènent presque toujours à des configurations de cloud hybride. Les entreprises doivent souvent faire migrer leurs applications et leurs données de manière systématique en fonction de leurs priorités. De même, une configuration à court terme peut être destinée à faciliter une démonstration de faisabilité à l'aide de technologies avancées disponibles dans le cloud pendant une certaine période.

Décisions de conception technique

L'objectif technique identifié et ses facteurs sont essentiels pour prendre une décision architecturale axée sur l'activité et pour sélectionner l'un des modèles d'architecture abordés dans ce guide. Par exemple, pour atteindre un objectif commercial spécifique, une entreprise peut définir un objectif commercial visant à développer une pratique de recherche et développement pendant trois à six mois. La principale exigence commerciale pour atteindre cet objectif peut être de créer l'environnement technologique requis pour la recherche et la conception avec le CAPEX le plus faible possible.

L'objectif technique est ici de disposer d'une configuration de cloud hybride temporaire. L'objectif technique est de tirer parti du modèle de tarification à la demande du cloud pour répondre aux exigences commerciales mentionnées précédemment. Un autre facteur est lié aux exigences technologiques spécifiques qui nécessitent une solution cloud avec une capacité de calcul élevée et une configuration rapide.

Utiliser Google Cloud pour les architectures hybrides et multicloud

L'utilisation de solutions Open Source peut faciliter l'adoption d'une approche hybride et multicloud, et minimiser la dépendance vis-à-vis d'un fournisseur. Toutefois, vous devez tenir compte des complexités potentielles suivantes lors de la planification d'une architecture :

  • Interopérabilité
  • Gestion
  • Coût
  • Sécurité

S'appuyer sur une plate-forme cloud qui contribue à l'Open Source et le prend en charge peut vous aider à simplifier l'adoption d'architectures hybrides et multicloud. Le cloud ouvert vous permet de choisir l'approche qui vous convient le mieux et d'abstraire la complexité. De plus, Google Cloud offre la flexibilité nécessaire pour migrer, créer et optimiser des applications dans des environnements hybrides et multicloud, tout en réduisant la dépendance vis-à-vis d'un fournisseur, en exploitant des solutions de pointe et en répondant aux exigences réglementaires.

Google est également l'un des principaux contributeurs de l'écosystème Open Source. Il collabore avec la communauté Open Source pour développer des technologies Open Source bien connues comme Kubernetes. Lorsqu'il est déployé en tant que service géré, Kubernetes peut contribuer à réduire la complexité de la gestion et de la sécurité hybrides et multicloud.

Planifier une stratégie hybride et multicloud

Ce document explique comment appliquer des considérations commerciales prédéfinies lors de la planification d'une stratégie hybride et multicloud. Il développe les conseils fournis dans Facteurs, considérations, stratégie et approches. Cet article définit et analyse les considérations commerciales dont les entreprises doivent tenir compte lorsqu'elles planifient une telle stratégie.

Clarifier et convenir de la vision et des objectifs

En fin de compte, l'objectif principal d'une stratégie hybride ou multicloud est de répondre aux exigences commerciales identifiées et aux objectifs techniques associés pour chaque cas d'utilisation métier, en fonction d'objectifs commerciaux spécifiques. Pour atteindre cet objectif, créez un plan bien structuré qui inclut les éléments suivants :

Sachez que l'élaboration d'un plan prenant en compte l'ensemble des charges de travail et des exigences est une tâche difficile, en particulier dans un environnement informatique complexe. En outre, la planification prend du temps et peut ne pas satisfaire les avis contradictoires des parties prenantes.

Pour éviter ce type de situation, commencez par rédiger un énoncé de vision qui répond au moins aux questions suivantes :

  • Quel cas d'utilisation métier ciblée permet d'atteindre des objectifs commerciaux spécifiques ?
  • Pourquoi l'approche actuelle et l'environnement informatique sont-ils insuffisants pour atteindre les objectifs commerciaux ?
  • Quels sont les principaux aspects technologiques à optimiser en optant pour le cloud public ?
  • Pourquoi et comment la nouvelle approche va-t-elle optimiser et atteindre vos objectifs commerciaux ?
  • Combien de temps comptez-vous utiliser votre configuration hybride ou multicloud ?

S'accorder sur les principaux objectifs et moteurs commerciaux et techniques, puis obtenir l'approbation des parties prenantes concernées peuvent constituer la base des prochaines étapes du processus de planification. Pour aligner efficacement votre solution proposée sur la vision architecturale globale de votre organisation, coordonnez-vous avec votre équipe et les partenaires responsables de la direction et du financement de cette initiative.

Identifier et clarifier d'autres considérations

Lorsque vous planifiez une architecture hybride ou multicloud, il est important d'identifier et de convenir des contraintes architecturales et opérationnelles de votre projet.

Du point de vue des opérations, la liste non exhaustive suivante fournit quelques exigences qui peuvent créer des contraintes à prendre en compte lors de la planification de votre architecture :

  • Gérer et configurer plusieurs clouds séparément ou créer un modèle global pour gérer et sécuriser les différents environnements cloud.
  • Assurer la cohérence des procédures d'authentification, d'autorisation et d'audit, ainsi que des règles applicables aux différents environnements
  • Utiliser des outils et des processus cohérents dans tous les environnements pour obtenir une vue globale de la sécurité, des coûts et des opportunités d'optimisation.
  • Utiliser des normes de conformité et de sécurité cohérentes pour appliquer une gouvernance unifiée.

Sur le plan de la planification de l'architecture, les contraintes les plus importantes découlent souvent des systèmes existants, en particulier de ces éléments :

  • Dépendances entre les applications
  • Exigences de performances et de latence pour la communication entre les systèmes
  • Utilisation de matériel ou de systèmes d'exploitation qui ne sont pas disponibles dans le cloud public
  • Restrictions de licence
  • Dépendance à la disponibilité des fonctionnalités requises dans les régions sélectionnées d'une architecture multicloud

Pour en savoir plus sur les autres considérations liées à la portabilité des charges de travail, au transfert de données et aux aspects de sécurité, consultez Autres considérations.

Concevoir une stratégie d'architecture hybride et multicloud

Une fois que vous avez clarifié les spécificités des objectifs commerciaux et techniques avec les exigences commerciales associées (et idéalement clarifié et convenu d'un énoncé de vision), vous pouvez élaborer votre stratégie pour créer une architecture hybride ou multicloud.

L'organigramme suivant résume les étapes logiques à suivre pour créer une telle stratégie.

Lorsque vous élaborez votre stratégie, tenez compte de vos objectifs commerciaux, obtenez l'adhésion de votre équipe, créez un plan général, puis utilisez-le pour définir votre stratégie.

Pour vous aider à déterminer vos objectifs et besoins techniques en matière d'architecture hybride ou multicloud, les étapes du diagramme précédent commencent par les exigences et objectifs commerciaux. La façon dont vous mettez en œuvre votre stratégie peut varier en fonction des objectifs, des moteurs et du chemin de migration technologique de chaque cas d'utilisation métier.

Il est important de se rappeler qu'une migration est un voyage. Le diagramme suivant illustre les phases de ce parcours, comme décrit dans Migrer vers Google Cloud.

Chemin de migration en quatre phases.

Cette section fournit des conseils sur les phases "Évaluer", "Planifier", "Déployer" et "Optimiser" du diagramme précédent. Ces informations sont présentées dans le contexte d'une migration hybride ou multicloud. Vous devez aligner toute migration sur les conseils et les bonnes pratiques abordés dans la section Chemin de migration du guide Migrate to Google Cloud . Ces phases peuvent s'appliquer à chaque charge de travail individuellement, et non à toutes les charges de travail en même temps. À tout moment, plusieurs charges de travail peuvent se trouver à différentes phases :

Phase d'évaluation

Dans la phase Évaluer, vous effectuez une évaluation initiale des charges de travail. Pendant cette phase, tenez compte des objectifs décrits dans vos documents de planification de la vision et de la stratégie. Déterminez un plan de migration en identifiant d'abord une liste de charges de travail susceptibles de tirer avantage d'un déploiement ou d'une migration vers le cloud public.

Pour commencer, choisissez une charge de travail qui n'est pas critique pour l'entreprise ou trop difficile à migrer (avec des dépendances minimales ou nulles par rapport à une charge de travail dans d'autres environnements), mais suffisamment représentative pour servir de modèle pour les déploiements ou les migrations à venir.

Idéalement, la charge de travail ou l'application que vous sélectionnez doit faire partie d'un cas d'utilisation ou d'une fonction métier ciblés qui ont un effet mesurable sur l'entreprise une fois qu'ils sont terminés.

Pour évaluer et atténuer les risques potentiels liés à la migration, effectuez une évaluation des risques de migration. Il est important d'évaluer votre charge de travail candidate pour déterminer si elle peut être migrée vers un environnement multicloud. Cette évaluation consiste à évaluer différents aspects des applications et de l'infrastructure, y compris les suivants :

  • Exigences de compatibilité des applications avec les fournisseurs de services cloud sélectionnés
  • Modèles de tarification
  • Fonctionnalités de sécurité proposées par les fournisseurs de services cloud sélectionnés
  • Exigences d'interopérabilité des applications

L'exécution d'une évaluation vous aide également à identifier les exigences en matière de confidentialité des données, de conformité et de cohérence, ainsi que les solutions dans plusieurs environnements cloud. Les risques que vous identifiez peuvent affecter les charges de travail que vous choisissez de migrer ou d'exploiter.

Plusieurs types d'outils, comme le centre de migration Google Cloud, peuvent vous aider à évaluer les charges de travail existantes. Pour en savoir plus, consultez Migrer vers Google Cloud : choisir un outil d'évaluation.

Du point de vue de la modernisation des charges de travail, l'outil d'évaluation de l'adéquation permet d'évaluer une charge de travail de VM pour déterminer si elle est adaptée à la modernisation vers un conteneur ou à la migration vers Compute Engine.

Phase de planification

Dans la phase Planifier, commencez par les applications et les charges de travail cloud requises identifiées, puis effectuez les tâches suivantes :

  1. Élaborez une stratégie de migration prioritaire qui définit les vagues de migration des applications et les chemins de migration.
  2. Identifiez le modèle d'architecture d'application hybride ou multicloud de haut niveau applicable.
  3. Sélectionnez un modèle d'architecture réseau compatible avec le modèle d'architecture d'application sélectionné.

Idéalement, vous devriez intégrer le modèle de mise en réseau cloud à la conception de la zone de destination. La conception de la zone de destination constitue un élément fondamental des architectures hybrides et multicloud globales. La conception nécessite une intégration fluide avec ces modèles. Ne concevez pas la zone de destination de manière isolée. Considérez ces modèles de mise en réseau comme un sous-ensemble de la conception de la zone d'atterrissage.

Une zone d'atterrissage peut être constituée de différentes applications, chacune avec un modèle d'architecture réseau différent. En outre, au cours de cette phase, il est important de choisir la conception de l'Google Cloud organisation, des projets et de la hiérarchie des ressources afin de préparer la zone de destination de votre environnement cloud pour l'intégration et le déploiement hybride ou multicloud.

Dans cette phase, vous devez tenir compte des points suivants :

  • Définissez l'approche de migration et de modernisation. Vous trouverez plus d'informations sur les approches de migration plus loin dans ce guide. Pour en savoir plus, consultez la section Types de migration de Migrer vers Google Cloud.
  • Utilisez les résultats de votre phase d'évaluation et de découverte. Alignez-les sur la charge de travail candidate que vous prévoyez de migrer. Ensuite, élaborez un plan de vagues de migration pour les applications. Le plan doit intégrer les exigences de dimensionnement des ressources estimées que vous avez déterminées lors de la phase d'évaluation.
  • Définissez le modèle de communication requis entre les applications distribuées et entre les composants d'application pour l'architecture hybride ou multicloud prévue.
  • Choisissez un archétype de déploiement adapté pour déployer votre charge de travail (zonal, régional, multirégional ou mondial, par exemple) pour le modèle d'architecture choisi. L'archétype que vous sélectionnez sert de base pour construire les architectures de déploiement spécifiques aux applications et adaptées à vos besoins commerciaux et techniques.
  • Définissez des critères de réussite mesurables pour la migration, avec des étapes claires pour chaque phase ou vague de migration. Il est essentiel de sélectionner des critères, même si l'objectif technique est de mettre en place une architecture hybride à court terme.
  • Définissez des SLA et des KPI pour les applications lorsqu'elles fonctionnent dans une configuration hybride, en particulier pour celles qui peuvent avoir des composants distribués dans plusieurs environnements.

Pour en savoir plus, consultez À propos de la planification de la migration. Vous pourrez ainsi planifier une migration réussie et minimiser les risques associés.

Phase de déploiement

Dans la phase Déployer, vous êtes prêt à exécuter votre stratégie de migration. Compte tenu du nombre potentiel d'exigences, il est préférable d'adopter une approche itérative.

Hiérarchisez vos charges de travail en fonction des vagues de migration et d'applications que vous avez définies lors de la phase de planification. Avec les architectures hybrides et multicloud, commencez votre déploiement en établissant la connectivité nécessaire entre Google Cloud et les autres environnements de calcul. Pour faciliter le modèle de communication requis pour votre architecture hybride ou multicloud, basez le déploiement sur la conception et le type de connectivité réseau que vous avez sélectionnés, avec le modèle de réseau applicable. Nous vous recommandons d'adopter cette approche pour votre décision de conception globale de la zone de destination.

De plus, vous devez tester et valider l'application ou le service en fonction des critères de réussite définis pour l'application. Idéalement, ces critères doivent inclure des exigences de tests fonctionnels et de charge (non fonctionnels) avant de passer à la production.

Phase d'optimisation

Dans la phase Optimiser, testez votre déploiement : une fois les tests terminés et si l'application ou le service répond aux attentes en termes de capacité fonctionnelle et de performances, vous pouvez le mettre en production. Les outils de visibilité et de surveillance du cloud, tels que Cloud Monitoring, peuvent vous donner des informations sur les performances, la disponibilité et l'état de vos applications et de votre infrastructure, et vous aider à les optimiser si nécessaire.

Pour en savoir plus, consultez Migrer vers Google Cloud : optimiser votre environnement. Pour savoir comment concevoir de tels outils pour une architecture hybride ou multicloud, consultez Modèles de surveillance et de journalisation hybrides et multicloud.

Évaluer les charges de travail candidates

Le choix des environnements de calcul pour différentes charges de travail a une incidence considérable sur le succès d'une stratégie hybride et multicloud. Les décisions de placement des charges de travail doivent être alignées sur des objectifs commerciaux spécifiques. Par conséquent, ces décisions doivent être guidées par des cas d'utilisation métier ciblés qui permettent d'obtenir des effets commerciaux mesurables. Toutefois, il n'est pas toujours nécessaire ni recommandé de commencer par la charge de travail/application la plus critique pour l'entreprise. Pour en savoir plus, consultez Choisir les applications à migrer en premier dans le guide "Migrer vers Google Cloud ".

Comme indiqué dans la section Facteurs commerciaux et techniques, il existe différents types de facteurs et de considérations pour les architectures hybrides et multicloud.

La liste récapitulative des facteurs ci-dessous peut vous aider à évaluer votre cas d'utilisation de la migration dans le contexte d'une architecture hybride ou multicloud avec des opportunités d'avoir un impact commercial mesurable :

  • Potentiel de différenciation ou d'innovation sur le marché grâce à l'utilisation de services cloud pour activer certaines fonctions ou capacités commerciales, telles que les capacités d'intelligence artificielle qui utilisent les données sur site existantes pour entraîner des modèles de machine learning.
  • Économies potentielles sur le coût total de possession d'une application
  • Améliorations potentielles de la disponibilité, de la résilience, de la sécurité ou des performances (par exemple, en ajoutant un site de reprise après sinistre dans le cloud).
  • Accélération potentielle des processus de développement et de publication (par exemple, en créant vos environnements de développement et de test dans le cloud).

Les facteurs suivants peuvent vous aider à évaluer les risques de migration :

  • Impact potentiel des pannes provoquées par une migration
  • L'expérience de votre équipe avec les déploiements de cloud public ou avec les déploiements pour un nouveau fournisseur de cloud ou un deuxième fournisseur de cloud.
  • Nécessité de vous conformer aux restrictions légales ou réglementaires.

Les facteurs suivants peuvent vous aider à évaluer les difficultés techniques d'une migration :

  • Taille, complexité et ancienneté de l'application
  • Nombre de dépendances avec d'autres applications et services dans différents environnements informatiques.
  • Toutes les restrictions imposées par des licences tierces.
  • Dépendances liées à des versions spécifiques de systèmes d'exploitation, de bases de données ou d'autres configurations d'environnement

Une fois que vous avez évalué vos charges de travail initiales, vous pouvez commencer à les hiérarchiser et à définir vos vagues et approches de migration. Vous pouvez ensuite identifier les modèles d'architecture applicables et les modèles de mise en réseau associés. Cette étape peut nécessiter plusieurs itérations, car votre évaluation peut changer au fil du temps. Il est donc intéressant de réévaluer les charges de travail après vos premiers déploiements cloud.

Approches architecturales d'adoption d'une architecture hybride ou multicloud

Ce document fournit des conseils sur les approches et les considérations courantes et éprouvées pour migrer votre charge de travail vers le cloud. Il développe les conseils de Concevoir une stratégie d'architecture hybride et multicloud, qui présente plusieurs étapes possibles et recommandées pour concevoir une stratégie d'adoption d'une architecture hybride ou multicloud.

Approche centrée sur le cloud

Le cloud public est souvent privilégié en tant qu'approche centrée sur le cloud. Cette approche consiste à déployer vos nouvelles charges de travail dans le cloud public, tandis que vos charges de travail existantes restent en place. Dans ce cas, si un déploiement de cloud public n'est pas possible pour des raisons techniques ou organisationnelles, un déploiement classique dans un environnement informatique privé doit être envisagé.

Une stratégie centrée sur le cloud présente des avantages et des inconvénients. Sa nature prospective est un avantage indéniable : Vous pouvez déployer de nouvelles charges de travail de façon moderne, tout en évitant (ou en minimisant) les tracas liés à une migration des charges de travail existantes.

Bien qu'une approche centrée sur le cloud puisse offrir certains avantages, elle peut potentiellement entraîner des opportunités manquées pour améliorer ou utiliser les charges de travail existantes. En effet, les nouvelles charges de travail ne représentent souvent qu'une fraction du paysage informatique global. Leur impact sur les dépenses et les performances informatiques peut donc être limité. Allouer du temps et des ressources à la migration d'une charge de travail existante peut potentiellement générer des avantages ou des économies plus importants que d'essayer d'adapter une nouvelle charge de travail dans l'environnement cloud.

Par ailleurs, l'application stricte d'une approche cloud-first risque de complexifier encore plus votre environnement informatique. Cette approche peut créer des redondances, réduire les performances par excès d'intercommunications ou créer un environnement informatique inadapté aux particularités des charges de travail. De plus, le respect des réglementations du secteur et des lois sur la confidentialité des données peut empêcher les entreprises de migrer certaines applications contenant des données sensibles.

Par conséquent, vous avez plutôt intérêt à réserver l'approche centre sur le cloud à certaines charges de travail sélectionnées. Une approche axée sur le cloud vous permet de vous concentrer sur les charges de travail qui peuvent le plus bénéficier d'un déploiement ou d'une migration dans le cloud. Cette approche tient également compte de la modernisation des charges de travail existantes.

Un exemple courant d'architecture hybride cloud-first est celui où des applications et services anciens contenant des données critiques doivent être intégrés à de nouvelles données ou applications. Pour finaliser l'intégration, vous pouvez utiliser une architecture hybride qui modernise les anciens services à l'aide d'interfaces API, ce qui les déverrouille pour permettre aux nouveaux services et applications cloud de les utiliser. Avec une plate-forme de gestion des API cloud, comme Apigee, vous pouvez implémenter de tels cas d'utilisation en apportant un minimum de modifications aux applications et en ajoutant de la sécurité, des analyses et de l'évolutivité aux anciens services.

Migration et modernisation

Le multicloud hybride et la modernisation informatique sont deux concepts distincts au sein d'un même cercle vertueux. L'utilisation du cloud public peut faciliter et simplifier la modernisation des charges de travail informatiques. La modernisation de vos charges de travail informatiques peut vous aider à tirer le meilleur parti du cloud.

La modernisation des charges de travail répond aux principaux objectifs suivants :

  • Obtenir une plus grande agilité de façon à s'adapter à l'évolution des besoins
  • Réduisez les coûts de votre infrastructure et de vos opérations.
  • Augmenter la fiabilité et la résilience pour minimiser les risques

Toutefois, il n'est peut-être pas possible de moderniser toutes les applications en même temps lors du processus de migration. Comme décrit dans Migrer vers Google Cloud, vous pouvez implémenter l'un des types de migration suivants, ou même combiner plusieurs types selon vos besoins :

  • Réhéberger (migration Lift and Shift)
  • Changer de plate-forme (migration Lift and Optimize)
  • Refactoriser (migration Move and Improve)
  • Redéfinir l'architecture (poursuivre la modernisation)
  • Recompilez (suppression et remplacement, parfois appelé migration Rip and Replace)
  • Rachetez

Lorsque vous prenez des décisions stratégiques concernant vos architectures hybrides et multicloud, il est important de tenir compte de la faisabilité de votre stratégie en termes de coûts et de temps. Vous pouvez envisager une approche de migration par phases, en commençant par le lift and shift ou le replatforming, puis en refactorisant ou en redéfinissant l'architecture comme prochaine étape. En général, le lift and shift permet d'optimiser les applications du point de vue de l'infrastructure. Une fois les applications exécutées dans le cloud, il est plus facile d'utiliser et d'intégrer des services cloud pour les optimiser davantage à l'aide d'architectures et de fonctionnalités cloud-first. De plus, ces applications peuvent toujours communiquer avec d'autres environnements via une connexion réseau hybride.

Par exemple, vous pouvez refactoriser ou redéfinir l'architecture d'une grande application monolithique basée sur des VM et la transformer en plusieurs microservices indépendants, en fonction d'une architecture de microservices basée sur le cloud. Dans cet exemple, l'architecture de microservices utilise des services de conteneurs gérés par Google Cloud , comme Google Kubernetes Engine (GKE) ou Cloud Run. Toutefois, si l'architecture ou l'infrastructure d'une application n'est pas acceptée telle quelle dans l'environnement cloud cible, vous pouvez envisager de commencer par une stratégie de replatforming, de refactoring ou de réarchitecture pour surmonter ces contraintes, dans la mesure du possible.

Lorsque vous utilisez l'une de ces approches de migration, envisagez de moderniser vos applications (le cas échéant et si possible). La modernisation peut nécessiter l'adoption et l'implémentation des principes de l'ingénierie de la fiabilité des sites (SRE) ou de DevOps. Vous devrez peut-être également étendre la modernisation des applications à votre environnement privé dans une configuration hybride. Bien que l'implémentation des principes SRE implique avant tout de l'ingénierie, il s'agit davantage d'un processus de transformation que d'un défi technique. Par conséquent, il nécessitera probablement des changements procéduraux et culturels. Pour en savoir plus sur la première étape de l'implémentation de la SRE dans une organisation, qui consiste à obtenir l'adhésion de la direction, consultez Avec la SRE, ne pas planifier, c'est planifier l'échec.

Combiner plusieurs approches de migration

Chacune des approches de migration présentées ici a ses points forts et ses points faibles. La stratégie hybride et multicloud a pour avantage principal de ne pas imposer un choix unique. Vous pouvez en effet décider de l'approche qui convient le mieux en fonction de chaque charge de travail ou pile d'applications, comme illustré dans le diagramme suivant.

Organigramme présentant différentes approches pour migrer des charges de travail depuis votre environnement cloud.

Ce diagramme conceptuel illustre les différents chemins ou approches de migration et de modernisation qui peuvent être appliqués simultanément à différentes charges de travail, en fonction des exigences et des objectifs commerciaux et techniques uniques de chaque charge de travail ou application.

De plus, il n'est pas nécessaire que les mêmes composants de la pile d'applications suivent la même approche ou stratégie de migration. Exemple :

  • La base de données de backend sur site d'une application peut être replatformée de MySQL auto-hébergé vers une base de données gérée à l'aide de Cloud SQL dans Google Cloud.
  • Les machines virtuelles du frontend de l'application peuvent être refactorisées pour s'exécuter sur des conteneurs à l'aide de GKE Autopilot, où Google gère la configuration du cluster, y compris les nœuds, le scaling, la sécurité et d'autres paramètres préconfigurés.
  • La solution d'équilibrage de charge matérielle sur site et les fonctionnalités de pare-feu d'application Web (WAF) peuvent être remplacées par Cloud Load Balancing et Google Cloud Armor.

Choisissez le réhébergement ("lift and shift") si l'une des conditions suivantes est remplie pour les charges de travail :

  • Le nombre de dépendances dans leur environnement est relativement faible.
  • Il ne semble pas utile de les refactoriser ou la refactorisation avant la migration n'est pas possible.
  • Elles sont basées sur des logiciels tiers.

Privilégiez l'approche "refactoriser (déplacer et améliorer)" pour les charges de travail qui répondent à ces critères :

  • Il existe des dépendances qu'il faut dénouer.
  • Elles reposent sur des systèmes d'exploitation, du matériel ou des systèmes de base de données qui ne peuvent pas être hébergés dans le cloud.
  • Les ressources de calcul ou de stockage sont mal utilisées.
  • Elles ne peuvent pas être déployées de manière automatisée sans un certain effort.

Déterminez si la reconstruction (suppression et remplacement) répond à vos besoins pour les types de charges de travail suivants :

  • Elles ne satisfont plus les exigences actuelles.
  • Elles peuvent être intégrées à d'autres applications offrant des fonctionnalités similaires sans compromettre les exigences métier.
  • Elles reposent sur une technologie tierce en fin de vie.
  • Elles exigent des droits de licences tierces qui ne se justifient plus sur le plan économique.

Le programme de migration rapide montre comment Google Cloud aide les clients à utiliser les bonnes pratiques, à réduire les risques, à maîtriser les coûts et à simplifier leur transition vers le cloud.

Autres points à noter

Ce document met en évidence les principales considérations de conception qui jouent un rôle essentiel dans la conception de votre architecture hybride et multicloud globale. Analysez et évaluez de manière holistique ces considérations dans l'ensemble de l'architecture de votre solution, en englobant toutes les charges de travail, et pas seulement certaines.

Refactoriser

Lors d'une migration de refactorisation, vous modifiez vos charges de travail afin de tirer parti des fonctionnalités cloud, et pas seulement de les modifier pour qu'elles fonctionnent dans le nouvel environnement. Vous pouvez optimiser les performances, les fonctionnalités, les coûts ou l'expérience utilisateur associés à chaque charge de travail. Comme indiqué dans Refactoriser : migrer et améliorer, certains scénarios de refactoring vous permettent de modifier les charges de travail avant de les migrer vers le cloud. Cette approche de refactoring offre les avantages suivants, en particulier si votre objectif est de créer une architecture hybride comme architecture cible à long terme :

  • Vous facilitez le processus de déploiement.
  • Vous pouvez accélérer la cadence de publication et raccourcir les cycles de commentaires en investissant dans une infrastructure et des outils d'intégration/de déploiement continus (CI/CD).
  • Vous pouvez utiliser le refactoring comme base pour créer et gérer une architecture hybride avec portabilité des applications.

Pour fonctionner correctement, cette approche nécessite généralement certains investissements dans l'infrastructure et les outils sur site. Par exemple, en configurant un Container Registry local et en provisionnant des clusters Kubernetes pour conteneuriser les applications. L'édition Enterprise de Google Kubernetes Engine (GKE) peut être utile dans cette approche pour les environnements hybrides. Pour en savoir plus sur GKE Enterprise, consultez la section suivante. Pour en savoir plus, vous pouvez également consulter l'architecture de référence de l'environnement hybride GKE Enterprise.

Portabilité des charges de travail

Avec les architectures hybrides et multicloud, vous pouvez déplacer des charges de travail entre les environnements de calcul qui hébergent vos données. Pour faciliter le déplacement des charges de travail entre les environnements, tenez compte des facteurs suivants :

  • Vous pouvez déplacer une application d'un environnement de calcul vers un autre sans modifier de manière significative l'application et son modèle opérationnel :
    • Le déploiement et la gestion des applications sont cohérents dans tous les environnements informatiques.
    • La visibilité, la configuration et la sécurité sont cohérentes dans tous les environnements de calcul.
  • La possibilité de rendre une charge de travail portable ne doit pas entrer en conflit avec le fait qu'elle soit axée sur le cloud.

Automatisation de l'infrastructure

L'automatisation de l'infrastructure est essentielle à la portabilité dans des architectures hybrides et multicloud. L'une des approches courantes pour automatiser la création d'infrastructures consiste à utiliser l'Infrastructure as Code (IaC). L'IaC consiste à gérer votre infrastructure dans des fichiers au lieu de configurer manuellement des ressources (comme une VM, un groupe de sécurité ou un équilibreur de charge) dans une interface utilisateur. Terraform est un outil IaC très répandu qui permet de définir des ressources d'infrastructure dans un fichier. Terraform vous permet également d'automatiser la création de ces ressources dans des environnements hétérogènes.

Pour en savoir plus sur les fonctions principales de Terraform qui peuvent vous aider à automatiser le provisionnement et la gestion des ressources, consultez Plans et modules Terraform pour Google Cloud. Google Cloud

De plus, pensez à des outils de gestion de configuration tels qu'Ansible, Puppet ou Chef pour établir un processus de déploiement et de configuration commun. Vous pouvez également utiliser un outil de génération d'images tel que Packer pour créer des images de VM pour différentes plates-formes. En utilisant un seul fichier de configuration partagé, vous pouvez utiliser Packer et Cloud Build pour créer une image de VM à utiliser sur Compute Engine. Enfin, des solutions comme Prometheus et Grafana vous permettent d'assurer une surveillance cohérente sur l'ensemble des environnements.

Sur la base de ces outils, vous pouvez assembler une chaîne d'outils commune, comme illustré dans le diagramme logique suivant. Cette chaîne d'outils commune élimine les différences entre les environnements informatiques. Il vous permet également d'unifier le provisionnement, le déploiement, la gestion et la surveillance.

Une chaîne d'outils permet la portabilité des applications.

Bien qu'une chaîne d'outils commune vous aide à réaliser la portabilité, elle présente plusieurs des inconvénients suivants :

  • L'utilisation de VM en tant que socle commun peut rendre difficile la mise en œuvre d'applications véritablement cloud-first. De plus, l'utilisation de VM uniquement peut vous empêcher d'utiliser des services gérés dans le cloud. Vous risquez de manquer des occasions de réduire les frais d'administration.
  • La mise en place et la maintenance d'une chaîne d'outils commune entraînent des frais généraux et opérationnels.
  • À mesure que la chaîne d'outils s'étend, elle peut développer des complexités uniques adaptées aux besoins spécifiques de votre entreprise. Cette complexité accrue peut contribuer à l'augmentation des coûts d'entraînement.

Avant de décider de développer des outils et une automatisation, explorez les services gérés proposés par votre fournisseur de services cloud. Lorsque votre fournisseur propose des services gérés compatibles avec le même cas d'utilisation, vous pouvez faire abstraction d'une partie de sa complexité. Cela vous permet de vous concentrer sur la charge de travail et l'architecture de l'application plutôt que sur l'infrastructure sous-jacente.

Par exemple, vous pouvez utiliser le modèle de ressource Kubernetes pour automatiser la création de clusters Kubernetes à l'aide d'une approche de configuration déclarative. Vous pouvez utiliser la conversion de Deployment Manager pour convertir vos configurations et modèles Deployment Manager dans d'autres formats de configuration déclaratifs compatibles avec Google Cloud (comme Terraform et le modèle de ressources Kubernetes) afin qu'ils soient portables lorsque vous les publiez.

Vous pouvez également envisager d'automatiser la création de projets et de ressources dans ces projets. Cette automatisation peut vous aider à adopter une approche de type infrastructure en tant que code pour le provisionnement de projet.

Conteneurs et Kubernetes

L'utilisation de fonctionnalités gérées dans le cloud permet de réduire la complexité de la création et de la maintenance d'une chaîne d'outils personnalisée pour automatiser et rendre portable la charge de travail. Cependant, l'utilisation de VM en tant que socle commun rend difficile la mise en œuvre d'applications véritablement cloud first. Une solution consiste utiliser des conteneurs et Kubernetes à la place.

Les conteneurs améliorent la fiabilité d'exécution du logiciel lorsque vous le déplacez d'un environnement à un autre. Les conteneurs permettent de dissocier les applications de l'infrastructure hôte sous-jacente, ce qui facilite le déploiement dans des environnements de calcul tels que les environnements hybrides et multicloud.

Kubernetes gère l'orchestration, le déploiement, le scaling et la gestion de vos applications conteneurisées. Il est Open Source et régi par la Cloud Native Computing Foundation. L'utilisation de Kubernetes fournit les services qui constituent la base d'une application cloud-first. Étant donné que Kubernetes peut être installé et exécuté sur différents environnements informatiques, vous pouvez également l'utiliser pour établir une couche d'exécution commune aux environnements informatiques :

  • Quel que soit l'environnement informatique, cloud ou privé, Kubernetes fournit les mêmes services et les mêmes API. De plus, le niveau d'abstraction est beaucoup plus élevé qu'avec des VM. Cela se traduit généralement par une réduction du travail de base et une amélioration de la productivité des développeurs.
  • Contrairement aux chaînes d'outils personnalisées, la technologie Kubernetes est largement utilisée pour le développement et la gestion des applications. Vous bénéficiez ainsi de l'expertise et de la documentation existantes, ainsi que de l'assistance d'un tiers.
  • Kubernetes est compatible avec toutes les implémentations de conteneurs qui :

Lorsqu'une charge de travail s'exécute sur Google Cloud, vous pouvez éviter le travail d'installation et d'exécution de Kubernetes en utilisant une plate-forme Kubernetes gérée, telle que Google Kubernetes Engine (GKE). Cela peut aider le personnel des opérations à se concentrer sur la création et la maintenance des applications plutôt que sur celles de l'infrastructure.

Vous pouvez également utiliser Autopilot, un mode de fonctionnement de GKE qui gère la configuration de votre cluster, y compris vos nœuds, le scaling, la sécurité et d'autres paramètres préconfigurés. Lorsque vous utilisez GKE Autopilot, tenez compte de vos besoins en termes de scaling et de ses limites de scaling.

Techniquement, vous pouvez installer et exécuter Kubernetes sur de nombreux environnements informatiques pour établir une couche d'exécution commune. Toutefois, en pratique, la création et l'exploitation d'une telle architecture peuvent s'avérer complexes. L'architecture devient encore plus complexe lorsque vous avez besoin d'un contrôle de sécurité au niveau du conteneur (maillage de services).

Pour simplifier la gestion des déploiements multiclusters, vous pouvez utiliser GKE Enterprise pour exécuter des applications modernes à grande échelle, où que ce soit. GKE inclut de puissants composants Open Source gérés pour sécuriser les charges de travail, appliquer les règles de conformité et fournir une observabilité et un dépannage réseau approfondis.

Comme illustré dans le schéma suivant, l'utilisation de GKE Enterprise vous permet d'exploiter des applications multiclusters en tant que parcs.

Diagramme de pile montrant les possibilités de gestion de parc offertes par GKE Enterprise.

GKE Enterprise vous aide à choisir parmi les options de conception suivantes pour prendre en charge les architectures hybrides et multicloud :

  • Concevez et créez des expériences de type cloud sur site ou des solutions unifiées pour transférer des applications vers un environnement hybride GKE Enterprise. Pour en savoir plus, consultez l'architecture de référence de l'environnement hybride GKE Enterprise.

  • Concevez et créez une solution pour résoudre la complexité multicloud avec une stratégie cohérente de gouvernance, d'opérations et de sécurité avec GKE Multi-Cloud. Pour en savoir plus, consultez la documentation GKE Multi-Cloud.

GKE Enterprise fournit également des regroupements logiques d'environnements similaires avec une sécurité, une configuration et une gestion des services cohérentes. Par exemple, GKE Enterprise est à la base d'une architecture distribuée Zero Trust. Dans une architecture distribuée "zéro confiance", les services déployés sur site ou dans un autre environnement cloud peuvent communiquer entre les environnements grâce à des communications de service à service sécurisées par mTLS de bout en bout.

Considérations relatives à la portabilité des charges de travail

Kubernetes et GKE Enterprise fournissent une couche d'abstraction pour les charges de travail, qui peut masquer de nombreuses subtilités et différences entre les environnements de calcul. La liste suivante décrit certaines de ces abstractions :

  • Une application peut être portable dans un autre environnement sans modifications majeures, mais ses performances ne seront pas forcément 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, peuvent engendrer des performances sensiblement différentes.
  • Le déplacement d'une charge de travail entre les environnements informatiques peut également nécessiter un transfert de données.
    • Différents environnements peuvent disposer de services et d'installations de stockage et de gestion de données différents.
  • Le comportement et les performances des équilibreurs de charge provisionnés avec Kubernetes ou GKE Enterprise peuvent varier d'un environnement à l'autre.

Transfert de données

Étant donné qu'il peut être complexe de déplacer, de partager et d'accéder à des données à grande échelle entre des environnements de calcul, les entreprises peuvent hésiter à créer une architecture hybride ou multicloud. Cette hésitation peut s'accroître s'ils stockent déjà la plupart de leurs données sur site ou dans un seul cloud.

Toutefois, les différentes options de transfert de données proposées par Google Cloudoffrent aux entreprises un ensemble complet de solutions pour les aider à transférer, intégrer et transformer leurs données. Ces options aident les entreprises à stocker, partager et accéder aux données dans différents environnements de manière à répondre à leurs cas d'utilisation spécifiques. Cette capacité permet aux décideurs commerciaux et technologiques d'adopter plus facilement des architectures hybrides et multicloud.

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. Votre équipe doit identifier vos différents cas d'utilisation professionnels et les données qui les alimentent. Vous devez également réfléchir au type de stockage, à la capacité, à l'accessibilité et aux options de déplacement.

Si une entreprise dispose d'une classification des données pour les secteurs réglementés, cette classification peut aider à identifier les emplacements de stockage et les restrictions de transfert de données entre régions pour certaines classes de données. Pour en savoir plus, consultez Sensitive Data Protection. Sensitive Data Protection est un service entièrement géré conçu pour vous aider à découvrir, classer et protéger vos éléments de données.

Pour découvrir le processus, de la planification d'un transfert de données à l'utilisation des bonnes pratiques de mise en œuvre d'un plan, consultez Migration vers Google Cloud : transférer vos ensembles de données volumineux.

Sécurité

À mesure que les entreprises adoptent des architectures hybrides et multicloud, leur surface d'attaque peut augmenter en fonction de la façon dont leurs systèmes et leurs données sont distribués dans différents environnements. Associées à un paysage des menaces en constante évolution, les surfaces d'attaque accrues peuvent entraîner un risque accru d'accès non autorisé, de perte de données et d'autres incidents de sécurité. Réfléchissez attentivement à la sécurité lorsque vous planifiez et mettez en œuvre des stratégies hybrides ou multicloud.

Pour en savoir plus, consultez Gestion de la surface d'attaque pour Google Cloud.

Lors de la conception d'une architecture hybride, il n'est pas toujours techniquement possible ou viable d'étendre les approches de sécurité sur site au cloud. Toutefois, de nombreuses fonctionnalités de sécurité réseau des appliances matérielles sont des fonctionnalités cloud-first et fonctionnent de manière distribuée. Pour en savoir plus sur les fonctionnalités de sécurité réseau axées sur le cloud de Google Cloud, consultez Sécurité réseau cloud.

Les architectures hybrides et multicloud peuvent entraîner des problèmes de sécurité supplémentaires, comme la cohérence et l'observabilité. Chaque fournisseur de cloud public a sa propre approche de la sécurité, y compris des modèles, des bonnes pratiques, des fonctionnalités de sécurité des infrastructures et des applications, des obligations de conformité et même des noms de services de sécurité différents. Ces incohérences peuvent augmenter les risques de sécurité. De plus, le modèle de responsabilité partagée de chaque fournisseur de services cloud peut varier. Il est essentiel d'identifier et de comprendre la répartition exacte des responsabilités dans une architecture multicloud.

L'observabilité est essentielle pour obtenir des insights et des métriques à partir des différents environnements. Dans une architecture multicloud, chaque cloud fournit généralement des outils pour surveiller la posture de sécurité et les erreurs de configuration. Toutefois, l'utilisation de ces outils entraîne une visibilité cloisonnée, ce qui empêche de créer une veille avancée sur les menaces dans l'ensemble de l'environnement. Par conséquent, l'équipe de sécurité doit passer d'un outil à l'autre et d'un tableau de bord à l'autre pour assurer la sécurité du cloud. Sans visibilité globale sur la sécurité de bout en bout pour les environnements hybrides et multiclouds, il est difficile de hiérarchiser et d'atténuer les failles.

Pour obtenir une visibilité et une posture complètes de tous vos environnements, hiérarchisez vos failles et atténuez celles que vous identifiez. Nous vous recommandons d'utiliser un modèle de visibilité centralisé. Un modèle de visibilité centralisé évite de devoir corréler manuellement différents outils et tableaux de bord provenant de différentes plateformes. Pour en savoir plus, consultez Modèles de surveillance et de journalisation hybrides et multicloud.

Pour vous aider à planifier et à concevoir votre solution cloud afin d'atteindre vos objectifs de sécurité et de conformité, et pour vous aider à planifier la réduction des risques de sécurité et le déploiement des charges de travail surGoogle Cloud, explorez le centre des bonnes pratiques de sécurité et le plan de base Enterprise. Google Cloud

Les objectifs de conformité peuvent varier, car ils sont influencés à la fois par les réglementations spécifiques au secteur et par les exigences réglementaires variables des différentes régions et des différents pays. Pour en savoir plus, consultez le Centre de ressources pour la conformité. Google Cloud Voici quelques-unes des principales approches recommandées pour concevoir une architecture hybride et multicloud sécurisée :

  • Développez une stratégie et une architecture de sécurité cloud unifiées et personnalisées. Les stratégies de sécurité hybrides et multicloud doivent être adaptées aux besoins et objectifs spécifiques de votre organisation.

    Il est essentiel de comprendre l'architecture et l'environnement cibles avant d'implémenter des contrôles de sécurité, car chaque environnement peut utiliser des fonctionnalités, des configurations et des services différents.

  • Envisagez une architecture de sécurité unifiée pour les environnements hybrides et multicloud.

  • Standardisez la conception et les déploiements cloud, en particulier la conception et les fonctionnalités de sécurité. Cela peut améliorer l'efficacité et permettre une gouvernance et des outils unifiés.

  • Utilisez plusieurs contrôles de sécurité.

    En règle générale, aucun contrôle de sécurité unique ne peut répondre de manière adéquate à toutes les exigences de protection de la sécurité. Par conséquent, les organisations doivent utiliser une combinaison de contrôles de sécurité dans une approche de défense multicouche, également appelée défense en profondeur.

  • Surveillez et améliorez en permanence les postures de sécurité : votre organisation doit surveiller ses différents environnements pour détecter les menaces et les failles de sécurité. Il doit également s'efforcer d'améliorer en permanence sa stratégie de sécurité.

  • Envisagez d'utiliser la gestion des stratégies de sécurité dans le cloud (CSPM) pour identifier et corriger les erreurs de configuration de la sécurité et les menaces de cybersécurité. La CSPM fournit également des évaluations des failles dans les environnements hybrides et multicloud.

Security Command Center est une solution intégrée de gestion de la sécurité et des risques pour Google Cloudqui permet d'identifier les erreurs de configuration, les failles et plus encore. Security Health Analytics est un outil d'analyse géré pour l'évaluation des failles. Il s'agit d'une fonctionnalité de Security Command Center qui identifie les risques et les failles de sécurité dans votre environnementGoogle Cloud et fournit des recommandations pour les corriger.

Mandiant Attack Surface Management pour Google Cloud permet à votre organisation de mieux visualiser les composants de son environnement multicloud ou cloud hybride. Il détecte automatiquement les ressources de plusieurs fournisseurs de services cloud, du DNS et de la surface d'attaque externe étendue pour permettre à votre entreprise de mieux comprendre son écosystème. Utilisez ces informations pour hiérarchiser la correction des failles et des expositions qui présentent le plus de risques.

  • Solution SIEM (Security Information and Event Management) pour le cloud : permet de collecter et d'analyser les journaux de sécurité des environnements hybrides et multicloud pour détecter les menaces et y répondre. Google Security Operations SIEM de Google Cloud permet de fournir des informations sur la sécurité et d'assurer une gestion des événements en collectant, en analysant, en détectant et en examinant toutes vos données de sécurité en un seul endroit.

Créer des architectures hybrides et multicloud à l'aide de Google Cloud : ce qui vous attend