Créez 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 des trois documents de l'ensemble. Il examine les opportunités et les considérations associées à ces architectures d'un point de vue commercial et technologique. Il analyse et discute é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 éléments suivants:

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

L'évolution rapide des demandes du marché a entraîné une hausse du niveau d'exigence et des attentes relatives à l'informatique d'entreprise, telles que l'évolutivité dynamique, l'amélioration des performances pour une expérience utilisateur optimisée et la sécurité. De nombreuses entreprises de niveau entreprise ont du mal à répondre à ces demandes et attentes en utilisant uniquement des infrastructures et des processus traditionnels. Les services IT sont également sous pression pour 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 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 frais d'investissement initiaux.

En ajoutant une ou plusieurs solutions 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 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 la planification de votre stratégie hybride ou multicloud, vous devez tenir compte de plusieurs défis et considérations de conception potentiels. Ce guide d'architecture en plusieurs parties met en avant les avantages potentiels de différentes architectures, ainsi que les défis potentiels.

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écrit 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 illustré dans le diagramme suivant, cette architecture comprend parfois un environnement IT privé (qui peut inclure l'utilisation d'un composant de cloud privé). Cette configuration 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 décrit les objectifs, les moteurs et les exigences métier, et comment ces facteurs peuvent influencer vos décisions de conception lors de la création d'architectures hybrides et multicloud.

Objectifs

Une organisation peut adopter une architecture hybride ou multicloud en tant que solution permanente pour atteindre des objectifs commerciaux spécifiques, ou en tant qu'état temporaire pour faciliter certaines exigences, telles qu'une migration vers le cloud.

Répondre aux questions suivantes sur votre entreprise est un bon moyen de définir vos exigences métier et d'établir des attentes spécifiques sur la manière d'atteindre certains ou tous vos objectifs commerciaux. Ces questions portent sur ce dont votre entreprise a besoin, et non sur la manière de l'obtenir techniquement.

  • Quels objectifs d'entreprise 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 ?
  • Quelles sont les exigences métier spécifiques ?

Dans le contexte des architectures hybrides et multicloud, un objectif commercial d'un client entreprise peut être d'étendre les opérations de vente en ligne ou les marchés 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) dans un délai de six mois.

Pour répondre aux exigences et objectifs métier mentionnés précédemment, un objectif technique principal potentiel consiste à faire évoluer l'infrastructure IT et l'architecture des applications d'une entreprise d'un modèle sur site uniquement à une architecture hybride, en utilisant les fonctionnalités et services mondiaux des clouds publics. Cet objectif doit être spécifique et mesurable, et définir clairement le champ d'application de l'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 métier. Par conséquent, choisir l'architecture hybride ou multicloud appropriée nécessite d'abord de clarifier ces exigences.

Il est important de distinguer les objectifs métier et les objectifs techniques de votre projet IT. Vos objectifs commerciaux doivent se concentrer sur l'objectif et la mission de votre organisation. Vos objectifs techniques doivent se concentrer sur la création d'une base technologique permettant à votre organisation de répondre à ses exigences et objectifs métier.

Les moteurs d'entreprise influencent la réalisation des objectifs et des objectifs commerciaux. Par conséquent, identifier clairement les moteurs d'entreprise peut aider à façonner les objectifs commerciaux afin qu'ils soient plus pertinents par rapport aux besoins et aux tendances du marché.

L'organigramme suivant illustre les moteurs, les objectifs, les objectifs et les exigences commerciaux, ainsi que les objectifs et les exigences techniques, et la relation entre tous ces facteurs:

Organigramme illustrant les éléments à prendre en compte lors du développement des exigences techniques, y compris les facteurs de développement, les objectifs, les exigences et les objectifs techniques.

Facteurs commerciaux et techniques

Réfléchissez à l'impact de vos moteurs commerciaux sur vos objectifs techniques. Voici quelques facteurs d'influence courants sur le plan commercial lors du 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 IT générales grâce à des disciplines de gestion financière et d'optimisation des coûts dans le cloud, comme les FinOps.
    • L'adoption du cloud peut être motivée par des scénarios qui aident à réduire les dépenses d'investissement en capital, 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 votre liste des moteurs d'entreprise pour l'adoption d'une architecture hybride ou multicloud. Ne les considérez pas isolément. Votre décision finale doit dépendre de l'équilibre de vos priorités commerciales.

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

Bien que l'adoption d'un seul fournisseur cloud puisse présenter plusieurs avantages, tels que la réduction de la complexité, les intégrations intégrées entre les services et les options d'optimisation des coûts telles que les remises sur l'utilisation engagée, il existe encore des scénarios où une architecture multicloud peut être bénéfique pour une entreprise. Voici les facteurs d'incitation commerciaux courants à l'adoption d'une architecture multicloud, ainsi que les considérations associées à chacun d'eux:

  • Respecter les lois et règlements relatifs à la souveraineté des données: le scénario le plus courant est celui d'une entreprise qui développe son activité dans une nouvelle région ou un nouveau pays et qui doit se conformer aux nouvelles réglementations sur l'hébergement de données.
    • Si le fournisseur de services cloud (CSP) utilisé n'a pas de région cloud locale dans ce pays, la solution courante consiste à utiliser un autre CSP disposant d'une région cloud locale dans ce pays.
  • Réduire les coûts: la réduction des coûts est souvent le moteur commercial le plus courant pour adopter une technologie ou une architecture. Toutefois, il est important de prendre en compte d'autres éléments que le coût des services et les remises tarifaires potentielles lorsque vous décidez d'adopter une architecture multicloud. Tenez compte des coûts 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:

  • Complexité de gestion accrue.
  • Maintenir une sécurité cohérente.
  • Intégrer des environnements logiciels
  • Obtenir des performances et une fiabilité cohérentes entre les clouds
  • Créer une équipe technique disposant de compétences multicloud peut être coûteux et nécessiter d'élargir 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 solution capable de fournir une visibilité et des tableaux de bord unifiés sur les coûts, il peut être difficile de gérer efficacement les coûts dans plusieurs environnements. Dans ce cas, vous pouvez utiliser la solution de gestion des coûts cloud Looker, le cas échéant. Pour en savoir plus, consultez la section Stratégie pour optimiser efficacement la gestion des coûts de facturation cloud.
  • Utiliser les fonctionnalités uniques de chaque FSC: 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 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: les entreprises souhaitent parfois éviter d'être dépendantes d'un seul fournisseur de services cloud. Une approche multicloud leur permet de choisir la meilleure solution pour leurs besoins métier. Toutefois, la faisabilité de cette décision dépend de plusieurs facteurs, tels que :
    • Dépendances techniques
    • Considérations concernant l'interopérabilité entre les applications
    • Coûts de recompilation ou de refactorisation des applications
    • Compétences techniques
    • Sécurité et gestion cohérentes
  • Amélioration du niveau de fiabilité et de disponibilité des applications critiques pour l'entreprise: dans certains cas, une architecture multicloud peut assurer la résilience face 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 prennent en charge 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écifique exigent le stockage de données sensibles (telles que les informations permettant d'identifier personnellement l'utilisateur) dans ce pays ou cette région, 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é aux restrictions réglementaires tout en répondant aux exigences de disponibilité.

Voici quelques éléments de résilience à évaluer avant d'adopter une architecture multicloud:

  • Déplacement des données: à quelle fréquence les données peuvent-elles être déplacées dans votre environnement multicloud ?
    • Le transfert de données peut-il entraîner des frais de transfert importants ?
  • Sécurité et gestion: existe-t-il des complexités potentielles en termes de sécurité ou de gestion ?
  • Parité des fonctionnalités: les deux CSP de la région sélectionnée proposent-ils les fonctionnalités et services requis ?
  • Compétences techniques: l'équipe technique dispose-t-elle des compétences requises pour gérer une architecture multicloud ?

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

Lorsque vous évaluez la faisabilité d'une architecture multicloud, il est important de prendre en compte les 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. De telles défaillances peuvent entraîner des dommages financiers et réputationnels à 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'échelle 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). Une équipe COE peut devenir le canal permettant de transformer la façon dont les équipes internes de votre organisation servent l'entreprise lors de la transition vers le cloud. Un centre d'excellence cloud est l'un des moyens pour votre organisation d'adopter le cloud plus rapidement, de favoriser la standardisation et de 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 d'incitation commerciaux courants sont les suivants:

  • Besoin de réduire les dépenses d'investissement ou les dépenses IT générales pour des projets à court terme.
  • La possibilité de 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 sur une durée limitée, tout en utilisant des données sur site.
  • Besoin de projets de transformation numérique pluriannuels qui nécessitent la mise en place d'une grande entreprise et qui utilisent une architecture hybride pendant un certain temps pour les aider à aligner la modernisation de leur infrastructure et de leurs applications sur leurs priorités métier.
  • 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 fusionnant utilisent différents fournisseurs de services cloud, 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 des fusions et acquisitions consiste presque toujours à intégrer les systèmes IT.

Facteurs techniques

La section précédente a abordé les moteurs d'activité. Pour être approuvées, les décisions architecturales majeures ont presque toujours besoin de l'appui de ces moteurs. Toutefois, les moteurs techniques, qui peuvent être basés sur un gain technique ou une contrainte, peuvent également influencer les moteurs commerciaux. Dans certains cas, il est nécessaire de traduire les moteurs techniques en moteurs commerciaux et d'expliquer comment ils peuvent avoir un impact positif ou négatif sur l'entreprise.

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

  • développer de nouvelles fonctionnalité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
  • Utilisation de services sans serveur pour créer des services et des fonctionnalités élastiques plus rapidement et à grande échelle.
  • Utilisation des fonctionnalités d'infrastructure mondiale pour créer des architectures globales ou multirégionales afin de répondre à certaines exigences techniques.

Le moteur technique le plus courant pour les architectures hybrides temporaires 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 naturellement à une configuration de cloud hybride. Les entreprises doivent souvent 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 preuve de concept à 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 moteurs sont essentiels pour prendre une décision d'architecture guidée par l'entreprise et sélectionner l'un des modèles d'architecture abordés dans ce guide. Par exemple, pour soutenir un objectif commercial spécifique, une entreprise peut définir un objectif commercial visant à créer une pratique de recherche et de développement pendant trois à six mois. L'exigence métier principale pour soutenir cet objectif peut être de créer l'environnement technologique requis pour la recherche et la conception avec les dépenses d'investissement en capital les plus faibles possibles.

L'objectif technique dans ce cas est de configurer un cloud hybride temporaire. L'objectif technique de cette approche est de tirer parti du modèle de tarification à la demande du cloud pour répondre à l'exigence métier mentionnée précédemment. Un autre facteur est influencé par les exigences technologiques spécifiques qui nécessitent une solution cloud avec une capacité de calcul élevée et une configuration rapide.

Utilisez 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 réduire la dépendance vis-à-vis d'un fournisseur. Toutefois, vous devez prendre en compte les 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 la prend en charge peut vous aider à simplifier l'adoption d'architectures hybrides et multicloud. Le cloud ouvert vous offre une approche qui offre un maximum de choix et qui abstrait la complexité. De plus, Google Cloud vous permet de migrer, de créer et d'optimiser des applications dans des environnements hybrides et multicloud tout en réduisant la dépendance vis-à-vis d'un fournisseur, en utilisant 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 et 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é liée à la gestion et à la sécurité des environnements hybrides et multicloud.

Planifier une stratégie hybride et multicloud

Ce document explique comment appliquer des considérations métier prédéfinies lors de la planification d'une stratégie hybride et multicloud. Il complète les conseils fournis dans la section Facteurs, considérations, stratégie et approches. Cet article définit et analyse les considérations commerciales que les entreprises doivent prendre en compte lors de la planification d'une telle stratégie.

Clarifier et définir la vision et les objectifs

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

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 IT 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 formuler un énoncé de vision qui répond aux questions suivantes (au minimum):

  • 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 utilisant 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 partenaires concernés peut 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, alignez-vous sur votre équipe et les personnes concernées chargées de diriger et de sponsoriser 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 côté des opérations, la liste non exhaustive suivante fournit certaines 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
  • Utilisation d'outils et de processus cohérents dans tous les environnements pour fournir 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 de 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 la section Autres considérations.

Concevoir une stratégie d'architecture hybride et multicloud

Une fois que vous avez clarifié les détails des objectifs métier et techniques avec les exigences métier 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.

Le diagramme 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 d'ensemble, puis utilisez-le pour élaborer votre stratégie.

Pour vous aider à déterminer les objectifs et les besoins techniques de votre architecture hybride ou multicloud, les étapes du diagramme précédent commencent par les exigences et les objectifs métier. La façon dont vous implémentez votre stratégie peut varier en fonction des objectifs, des moteurs et du parcours de migration technologique de chaque cas d'utilisation commercial.

Il est important de se rappeler qu'une migration est un voyage. Le schéma 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 d'évaluation, de planification, de déploiement et d'optimisation du diagramme précédent. Il présente ces informations dans le contexte d'une migration hybride ou multicloud. Vous devez aligner toute migration sur les conseils et les bonnes pratiques décrits dans la section "Chemin de migration" du guide de migration vers 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 dans différentes phases:

Phase d'évaluation

Lors de la phase d'évaluation, vous effectuez une évaluation initiale de la charge de travail. Au cours de cette phase, tenez compte des objectifs décrits dans vos documents de planification de la vision et de la stratégie. Définissez un plan de migration en commençant par identifier une liste de charges de travail candidates qui pourraient bénéficier 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.

Dans l'idéal, 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ée qui a un impact mesurable sur l'entreprise une fois terminée.

Pour évaluer et atténuer les risques potentiels de migration, effectuez une évaluation des risques de migration. Il est important d'évaluer votre charge de travail candidate pour déterminer si elle est adaptée à la migration vers un environnement multicloud. Cette évaluation implique d'évaluer divers aspects des applications et de l'infrastructure, y compris les suivants:

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

Effectuer une évaluation vous aide également à identifier les exigences de confidentialité des données, les exigences de conformité, les exigences de cohérence et 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 la page 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 de planification, commencez par les applications identifiées et les charges de travail cloud requises, puis effectuez les tâches suivantes:

  1. Développez une stratégie de migration prioritaire qui définit les vagues de migration des applications et les chemins.
  2. Identifiez le modèle d'architecture d'application hybride ou multicloud d'ordre général 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 devez 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 sert de base fondamentale aux 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 de destination.

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

Lors de 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. Vous trouverez également des informations plus détaillées dans la section Types de migration de Migrer vers Google Cloud.
  • Utilisez les résultats de la phase d'évaluation et de découverte. Alignez-les sur la charge de travail candidate que vous prévoyez de migrer. Développez ensuite un plan de vagues de migration pour les applications. Le plan doit intégrer les exigences d'ajustement 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 approprié pour déployer votre charge de travail, par exemple zonal, régional, multirégional ou mondial, en fonction du modèle d'architecture choisi. L'archétype que vous sélectionnez sert de base à la création des architectures de déploiement spécifiques aux applications adaptées à vos besoins commerciaux et techniques.
  • Définissez des critères de réussite mesurables pour la migration, avec des jalons clairs pour chaque phase ou vague de migration. La sélection des critères est essentielle, même si l'objectif technique est de configurer l'architecture hybride à court terme.
  • Définissez des KPI et des contrats de niveau de service pour vos applications lorsque celles-ci fonctionnent dans une configuration hybride, en particulier pour celles qui peuvent avoir des composants distribués sur plusieurs environnements.

Pour en savoir plus, consultez la section À propos de la planification de la migration pour vous aider à planifier une migration réussie et à minimiser les risques associés.

Phase de déploiement

Lors de la phase Déploiement, vous êtes prêt à commencer à 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'application que vous avez développées 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 IT. 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.

En outre, vous devez tester et valider l'application ou le service en fonction des critères de réussite définis. Dans l'idéal, ces critères doivent inclure à la fois les exigences fonctionnelles et les exigences de test de charge (non fonctionnelles) avant de passer en production.

Phase d'optimisation

Lors de la phase Optimisation, testez votre déploiement: une fois les tests terminés et que l'application ou le service répondent aux attentes en termes de capacité fonctionnelle et de performances, vous pouvez les mettre en production. Les outils de surveillance et de visibilité dans le cloud, tels que Cloud Monitoring, peuvent fournir des insights 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 la page Migrer vers Google Cloud: optimiser votre environnement. Pour en savoir plus sur la conception de tels outils pour une architecture hybride ou multicloud, consultez la section Modèles de surveillance et de journalisation hybrides et multicloud.

Évaluer les charges de travail candidates

Le choix des environnements informatiques pour les différentes charges de travail a un impact significatif sur la réussite d'une stratégie hybride et multicloud. Les décisions d'emplacement des charges de travail doivent être adaptées à 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/l'application la plus critique pour l'entreprise. Pour en savoir plus, consultez la section Choisir les applications à migrer en premier dans le guide de migration 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 suivante peut vous aider à évaluer votre cas d'utilisation de 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 fonctionnalités métier, telles que les fonctionnalité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, ajout d'un site de reprise après sinistre (DR) dans le cloud)
  • Accélération potentielle des processus de développement et de publication (par exemple, création de vos environnements de développement et de test dans le cloud).

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

  • Effet potentiel des pannes provoquées par une migration.
  • L'expérience de votre équipe avec les déploiements dans le cloud public ou les déploiements pour un nouveau fournisseur de cloud ou un deuxième fournisseur
  • 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.
  • 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 de migration et vos approches. 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 judicieux 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 complète les conseils de l'article 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. Dans cette approche, vous déployez vos nouvelles charges de travail dans le cloud public, tandis que vos charges de travail existantes restent à leur place. Dans ce cas, si un déploiement 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 cloud first puisse présenter certains avantages, elle peut potentiellement entraîner des opportunités manquées d'amélioration ou d'utilisation des charges de travail existantes. Les nouvelles charges de travail peuvent représenter une fraction du paysage IT global, et leur impact sur les dépenses et les performances IT peut être limité. Attribuer du temps et des ressources à la migration d'une charge de travail existante peut potentiellement générer des avantages ou des économies de coûts plus importants que d'essayer d'intégrer 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 IT. 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 cloud first vous permet de vous concentrer sur les charges de travail les plus qualifiées pour un déploiement ou 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 lorsque les applications et services existants contenant des données critiques doivent être intégrés à de nouvelles données ou applications. Pour effectuer 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 ces cas d'utilisation avec un minimum de modifications apportées aux applications, et ajouter de la sécurité, des analyses et de l'évolutivité aux anciens services.

Migration et modernisation

Le multicloud hybride et la modernisation IT 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 IT. La modernisation de vos charges de travail IT peut vous aider à tirer le meilleur parti du cloud.

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

  • Bénéficier d'une plus grande agilité de façon à s'adapter à l'évolution des besoins
  • Réduire les coûts de votre infrastructure et de vos opérations
  • Améliorez la fiabilité et la résilience pour minimiser les risques.

Toutefois, il peut s'avérer impossible de moderniser toutes les applications du processus de migration en même temps. Comme décrit dans la section Migration 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)
  • Migration (Lift and Optimize)
  • Refactorisation (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 prendre en compte la faisabilité de votre stratégie en termes de coûts et de délais. Vous pouvez envisager une approche de migration par étapes, en commençant par la migration Lift and Shift ou le replatforming, puis en passant à la refactorisation ou à la refonte. En règle générale, 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 les 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 une application monolithique volumineuse basée sur des VM et la transformer en plusieurs microservices indépendants, basés sur une architecture de microservices dans 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 compatible dans l'environnement cloud cible, vous pouvez commencer par replatformer, refactoriser ou redéfinir votre stratégie de migration pour surmonter ces contraintes, le cas échéant.

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

Combiner plusieurs approches de migration

Chaque approche de migration décrite ici présente certains avantages et inconvénients. 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 illustrant les différentes approches de migration 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 métier et techniques uniques, ainsi que des objectifs de chaque charge de travail ou application.

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

  • La base de données sur site de backend d'une application peut être migrée de MySQL autogéré 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, dans lequel 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 rehosting (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 réalisable.
  • Elles sont basées sur des logiciels tiers.

Privilégiez le refactoring (déplacement et amélioration) 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 effort.

Déterminez si la recréation (suppression et remplacement) répond à vos besoins pour ces types de charges de travail:

  • Elles ne satisfont plus les exigences actuelles.
  • Ils peuvent être intégrés à d'autres applications qui offrent 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 à appliquer 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 globale ces considérations dans l'ensemble de l'architecture de votre solution, en englobant toutes les charges de travail, et pas seulement des charges spécifiques.

Refactoriser

Lors d'une migration de refactorisation, vous modifiez vos charges de travail afin de tirer parti des fonctionnalités cloud, et pas seulement pour les rendre opérationnelles 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 Refactor: déplacer et améliorer, certains scénarios de refactorisation 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 en tant qu'architecture ciblée à 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 la 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, configurer un Container Registry local et provisionner des clusters Kubernetes pour conteneuriser des 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, consultez 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 souhaiter pouvoir déplacer des charges de travail entre les environnements informatiques qui hébergent vos données. Pour faciliter le transfert fluide des charges de travail entre les environnements, tenez compte des facteurs suivants:

  • Vous pouvez déplacer une application d'un environnement IT à 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 les environnements IT.
  • La possibilité de rendre une charge de travail portable ne doit pas entrer en conflit avec le fait qu'elle soit cloud first.

Automatisation de l'infrastructure

L'automatisation de l'infrastructure est essentielle à la portabilité dans des architectures hybrides et multicloud. Une approche courante pour automatiser la création d'infrastructure 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 populaire 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 de base de Terraform qui peuvent vous aider à automatiser le provisionnement et la gestion des ressources Google Cloud , consultez Blueprints et modules Terraform pour 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. À l'aide d'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 schéma 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 puisse vous aider à assurer 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 se développe, 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 de formation.

Avant de décider de développer des outils et des automatisations, 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 en éliminer une partie de la complexité. Vous pouvez ainsi 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 Infrastructure as 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 transférer les charges de travail. Toutefois, l'utilisation exclusive de VM comme base commune 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. Étant donné que les conteneurs dissocient les applications de l'infrastructure hôte sous-jacente, ils facilitent le déploiement dans les environnements IT, 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 vous pouvez installer et exécuter Kubernetes sur de nombreux 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 d'installer et d'exécuter Kubernetes en utilisant une plate-forme Kubernetes gérée telle que Google Kubernetes Engine (GKE). Cela peut aider le personnel d'exploitation à se concentrer sur la création et la maintenance d'applications plutôt que sur 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 exigences de mise à l'échelle et de ses limites de mise à l'échelle.

Techniquement, vous pouvez installer et exécuter Kubernetes sur de nombreux environnements informatiques pour établir une couche d'exécution commune. Toutefois, dans la 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 des conteneurs (maillage de services).

Pour simplifier la gestion des déploiements multiclusters, vous pouvez utiliser GKE Enterprise pour exécuter des applications modernes partout à grande échelle. 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 approfondis du réseau.

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

Schéma de pile illustrant les opportunités de gestion de flotte offertes par GKE Enterprise.

GKE Enterprise propose les options de conception suivantes pour prendre en charge les architectures hybrides et multicloud:

  • Concevez et créez des expériences cloud sur site ou des solutions unifiées pour la transition des applications vers l'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é du 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 sur 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 alimente une architecture distribuée zéro confiance. Dans une architecture distribuée de confiance zéro, les services déployés sur site ou dans un autre environnement cloud peuvent communiquer entre les environnements via des communications de service à service sécurisées mTLS de bout en bout.

Considérations sur la portabilité des charges de travail

Kubernetes et GKE Enterprise fournissent une couche d'abstraction pour les charges de travail qui peut masquer les nombreuses subtilités et différences entre les environnements informatiques. 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, de sécurité de l'infrastructure 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.
    • Les différents environnements peuvent avoir des services et des installations de stockage et de gestion des données différents.
  • Le comportement et les performances des équilibreurs de charge provisionnés avec Kubernetes ou GKE Enterprise peuvent différer 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 aux données à grande échelle entre les environnements informatiques, les entreprises d'envergure 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 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 à déplacer, 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 stratégie et la planification de l'architecture hybride et multicloud. Votre équipe doit identifier vos différents cas d'utilisation métier et les données qui les alimentent. Vous devez également tenir compte du type de stockage, de la capacité, de l'accessibilité et des 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 les régions pour certaines classes de données. Pour en savoir plus, consultez la section Protection des données sensibles. La protection des données sensibles 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 la page Migrer 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 répartis 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é. Tenez compte de la sécurité lorsque vous planifiez et implémentez des stratégies hybrides ou multicloud.

Pour en savoir plus, consultez la section 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. Cependant, 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 cloud first de Google Cloud, consultez la section Sécurité réseau cloud.

Les architectures hybrides et multicloud peuvent présenter des défis de sécurité supplémentaires, tels que la cohérence et l'observabilité. Chaque fournisseur de cloud public a sa propre approche de la sécurité, y compris différents modèles, bonnes pratiques, fonctionnalités de sécurité de l'infrastructure et des applications, obligations de conformité et même noms de services de sécurité. Ces incohérences peuvent augmenter le risque de sécurité. De plus, le modèle de responsabilité partagée de chaque fournisseur de services cloud peut différer. Il est essentiel d'identifier et de comprendre la démarcation 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 stratégie de sécurité et les mauvaises configurations. Toutefois, l'utilisation de ces outils entraîne une visibilité cloisonnée, ce qui empêche de créer une intelligence sur les menaces avancée dans l'ensemble de l'environnement. Par conséquent, l'équipe de sécurité doit passer d'un outil à un autre et d'un tableau de bord à un autre pour assurer la sécurité du cloud. Sans une visibilité globale de 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 la section Modèles de surveillance et de journalisation hybrides et multicloud.

Dans le cadre de votre planification visant à atténuer les risques de sécurité et à déployer des charges de travail surGoogle Cloud, et pour vous aider à planifier et à concevoir votre solution cloud afin d'atteindre vos objectifs de sécurité et de conformité, explorez le Centre des bonnes pratiques de sécurité et le plan de base d'entreprise pour 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 différentes des différentes régions et pays. Pour en savoir plus, consultez le Centre de ressources sur la conformité pour Google Cloud. Voici quelques-unes des principales approches recommandées pour concevoir une architecture hybride et multicloud sécurisée:

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

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

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

  • Standardiser 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é 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 en couches, é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 essayer 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é. Le 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 Cloud. Elle permet d'identifier les erreurs de configuration, les failles, etc. Security Health Analytics est un outil d'analyse d'évaluation des failles géré. 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 ressources de son environnement multicloud ou cloud hybride. Il détecte automatiquement les ressources de plusieurs fournisseurs de services cloud, le DNS et la surface d'attaque externe étendue pour fournir à votre entreprise une meilleure compréhension de son écosystème. Utilisez ces informations pour hiérarchiser les corrections en fonction des failles et des expositions qui présentent le plus de risques.

  • Solution de gestion des informations et des événements de sécurité (SIEM, Security Information and Event Management) dans le cloud: aide à collecter et à analyser les journaux de sécurité des environnements hybrides et multicloud pour détecter et gérer les menaces. Le SIEM Google Security Operations 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é au même endroit.

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