Modèles et pratiques hybrides et multicloud

Cette présentation constitue la première partie d'une série d'articles traitant des déploiements hybrides et multicloud, des modèles d'architecture et des topologies de réseau. Dans cette partie, nous explorons les possibilités et les défis des déploiements hybrides et multicloud. Nous y expliquons également comment aborder et mettre en œuvre une configuration hybride utilisant Google Cloud.

La série comprend les éléments suivants :

La transition numérique et la nécessité de s'adapter rapidement à l'évolution du marché ont entraîné une hausse du niveau d'exigence et des attentes relatives à l'informatique d'entreprise. Les infrastructures et les processus existants dans de nombreuses entreprises ne leur permettent pas d'évoluer comme elles le souhaiteraient.

Dans le même temps, les services informatiques se retrouvent souvent sous la pression des études et des impératifs de rentabilité, rendant difficile la justification de dépenses en capital supplémentaires (capex) en vue d'étendre et de moderniser leurs équipements et centres de données.

Une stratégie cloud hybride fournit une solution pragmatique. En utilisant le cloud public, vous pouvez étendre la capacité et les fonctionnalités de votre infrastructure informatique sans dépenses d'investissement initiales. En ajoutant un ou plusieurs déploiements cloud à votre infrastructure actuelle, vous préservez non seulement vos investissements existants, mais vous évitez aussi de vous engager auprès d'un seul fournisseur informatique. 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.

Cloud hybride et multicloud

Les charges de travail, l'infrastructure et les processus étant propres à chaque entreprise, toute stratégie 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 Google Cloud, le terme cloud hybride désigne une configuration dans laquelle des charges de travail communes ou interconnectées sont déployées dans plusieurs environnements informatiques, l'un étant basé dans le cloud public et au moins un autre étant privé.

L'exemple le plus courant consiste à combiner un environnement informatique privé, généralement un centre de données existant sur site, et un environnement informatique cloud public, comme le montre le diagramme ci-dessous.

Association d'un environnement informatique privé et d'un environnement informatique cloud public

Le terme multicloud désigne des configurations combinant au moins deux fournisseurs de cloud public, comme illustré ci-dessous.

Topologie multicloud associant au moins deux fournisseurs de cloud public

Une configuration multicloud peut également inclure des environnements informatiques privés.

Topologie multicloud associant au moins deux fournisseurs de cloud public et des environnements privés

Facteurs à prendre en compte dans les configurations cloud hybrides et multicloud

Les configurations hybrides et multicloud peuvent être temporaires et n'être maintenues que le temps de la migration afin d'en faciliter le processus. Cependant, dans la plupart des entreprises, ces configurations peuvent aussi constituer le futur cadre, à mesure que de nouveaux systèmes sont mis en place et que d'autres évoluent, afin d'en tirer le meilleur parti quel que soit l'emplacement choisi. Les configurations hybrides et multicloud peuvent donc être des dispositifs permanents dans le paysage informatique.

Une configuration hybride ou multicloud est rarement un objectif en soi, mais plutôt un moyen de répondre aux besoins de l'entreprise. Choisir la configuration hybride ou multicloud adéquate nécessite donc une mise au clair préalable de ces exigences.

Facteurs et contraintes stratégiques

Les entreprises sont soumises à un certain nombre de contraintes et de facteurs stratégiques, y compris les suivants :

  • réduire les efforts d'investissement ou les dépenses informatiques générales ;
  • augmenter la flexibilité et l'agilité pour mieux répondre aux nouvelles exigences du marché ;
  • développer de nouvelles fonctionnalités, telles que des services d'analyse avancés, qui peuvent être difficiles à mettre en place dans les environnements existants ;
  • améliorer la qualité et la disponibilité du service ;
  • améliorer la transparence en matière de coûts et de consommation de ressources ;
  • respecter les lois et règlements relatifs à la souveraineté des données ;
  • éviter ou réduire la dépendance vis-à-vis d'un fournisseur.

Facteurs de conception et de développement

La conception et le développement dans l'entreprise sont tributaires des facteurs suivants :

  • Automatiser et accélérer les déploiements d'applications afin de réduire le temps de production et la durée des cycles
  • Faire appel à 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

Exigences et contraintes opérationnelles

Il convient également de prendre en compte les exigences et contraintes opérationnelles suivantes :

  • Assurer la cohérence des procédures d'authentification, d'autorisation et d'audit, ainsi que des règles applicables aux différents environnements informatiques
  • Limiter la complexité à l'aide d'outils et de processus cohérents
  • Offrir une visibilité sur l'ensemble des environnements

Contraintes d'architecture

Sur le plan 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

Objectifs généraux

L'objectif d'une stratégie hybride et multicloud est de satisfaire ces exigences en commençant par un plan qui répond aux questions suivantes :

  • Quelles charges de travail doivent être exécutées dans tel environnement informatique ou migrées vers tel autre ?
  • Quels modèles appliquer à plusieurs charges de travail ?
  • Quelle technologie et quelle topologie de réseau utiliser ?

Fondamentalement, toute stratégie hybride et multicloud découle des besoins de l'entreprise. Cependant, la manière d'établir une stratégie applicable sur la base de ces contraintes est rarement claire. Non seulement les charges de travail, les modèles d'architecture et les technologies que vous choisissez en dépendent, mais ces éléments s'influencent aussi les uns les autres de manière cyclique. Le diagramme ci-dessous illustre ce cycle.

Effets et dépendances des charges de travail, des modèles et des technologies en fonction des exigences de l'entreprise

Définir une vision

Au sein de ce réseau de dépendances et de contraintes, 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 intérêts contradictoires des parties prenantes.

Pour éviter cette situation, commencez par rédiger un énoncé de vision cohérent avec les perspectives de l'entreprise et abordant les questions suivantes :

  • Pourquoi l'approche actuelle et l'environnement informatique sont-ils insuffisants ?
  • Quelles sont les métriques principales que vous souhaitez optimiser en optant pour le cloud public ?
  • Combien de temps comptez-vous utiliser une configuration hybride ou multicloud ? Considérez-vous cette configuration comme permanente ou provisoire pour la durée d'une migration complète vers le cloud ?

L'énoncé de vision n'indique pas comment atteindre ces objectifs.

S'accorder sur une vision et obtenir l'approbation des parties prenantes constituent la base des prochaines étapes du processus de planification.

Concevoir une stratégie hybride et multicloud

Après avoir défini une vision, vous pouvez élaborer la stratégie de la façon suivante :

  1. Effectuez une évaluation initiale des charges de travail. À partir des objectifs décrits dans l'énoncé de vision, identifiez une liste des charges de travail planifiées et existantes qui sont susceptibles de tirer avantage d'un déploiement ou d'une migration vers le cloud public. Ce sujet est exposé plus en détail dans la section suivante.

  2. En commençant par les charges de travail potentielles que vous avez sélectionnées, identifiez les modèles applicables et, en fonction de ces modèles, les topologies candidates.

    Si vous identifiez plusieurs modèles et topologies possibles, affinez votre sélection de charges de travail de manière à ne retenir qu'un seul modèle et une seule topologie. Itérez au besoin pour réduire encore vos sélections.

    Pour les grandes entreprises, l'application de plusieurs modèles et topologies peut sembler cohérente. Toutefois, cette approche est rarement idéale en raison du surcroît de complexité qui pourrait ralentir vos progrès.

  3. Hiérarchisez vos charges de travail. Compte tenu du nombre d'exigences, il est préférable d'adopter une approche itérative.

  4. Sélectionnez une charge de travail initiale à transférer dans le cloud public. Assurez-vous que cette charge de travail n'est pas critique pour l'entreprise ou trop difficile à migrer, mais suffisamment représentative pour servir de modèle aux déploiements ou migrations à venir.

    Lorsque vous sélectionnez une charge de travail à migrer, commencez à préparer votre configuration sur Google Cloud.

  5. Configurez l'organisation, les projets et les règles Google Cloud dont vous avez besoin pour préparer votre environnement cloud en vue des premiers déploiements.

  6. Mettez en œuvre la topologie du réseau, puis établissez la connectivité nécessaire entre Google Cloud et vos environnements informatiques privés.

Charges de travail

Le choix d'exécuter les charges de travail dans un environnement informatique plutôt qu'un autre conditionne en grande partie l'efficacité d'une stratégie hybride et multicloud. Migrer la mauvaise charge de travail dans le cloud peut compliquer votre déploiement, sans apporter d'avantages significatifs. En revanche, placer une charge de travail appropriée au bon endroit contribue non seulement à en faciliter l'exécution, mais également à mieux comprendre les avantages de chaque environnement.

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 les nouvelles charges de travail dans le cloud public. Dans ce cas, si un déploiement cloud 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 déployez de nouvelles charges de travail de façon native et transparente dans le cloud, tout en évitant (ou en minimisant) les tracas liés à une migration des charges de travail existantes.

En revanche, une stratégie centrée sur le cloud peut vous faire passer à côté d'opportunités intéressantes pour ces charges de travail existantes. En effet, les nouvelles charges de travail ne représentent souvent qu'une fraction de la charge informatique globale. Leur impact sur les dépenses et les performances informatiques générales est donc limité. Par conséquent, migrer une charge de travail existante s'avère souvent plus économique en temps et en coût que d'orchestrer une nouvelle charge de travail dans le cloud.

Par ailleurs, l'application stricte d'une stratégie centrée sur le cloud 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.

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. De cette façon, en centrant votre action sur les charges de travail les plus qualifiées pour un déploiement ou une migration dans le cloud, vous en tirerez tous les bénéfices. Par ailleurs, comme décrit dans la section suivante, cette approche tient également compte de la modernisation des charges de travail existantes.

Migration et modernisation

La transition hybride/multicloud et la modernisation des systèmes informatiques sont deux concepts distincts au sein d'un même cercle vertueux. Si l'utilisation du cloud public peut faciliter et simplifier la modernisation des charges de travail informatiques, la modernisation du système informatique permet de 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 d'infrastructure et des opérations
  • Augmenter la fiabilité et la résilience afin de limiter le plus possible les risques pour l'entreprise

Comme décrit sur la page Migration vers Google Cloud, vous pouvez mettre en œuvre l'un des types de migration suivants, ou même combiner plusieurs types selon vos besoins :

  • Migration Lift and Shift
  • Migration Improve and Move
  • Migration Rip and Replace

Migration Lift and Shift

L'expression lift and shift désigne le processus de migration d'une charge de travail d'un environnement informatique privé vers le cloud public sans modification majeure de la charge de travail. Le plus souvent, ce processus consiste à migrer des machines virtuelles existantes (VM) et leurs images vers Compute Engine.

L'exécution de VM dans Compute Engine plutôt que dans un environnement informatique privé présente certains avantages :

  • Vous pouvez accélérer le provisionnement des ressources informatiques et de stockage, en évitant les retards liés à l'acquisition et à l'installation d'équipements dans des centres de données classiques (privés ou sur site).

  • Vous ne payez que les ressources de calcul que vous utilisez, sans engagement préalable ni investissement.

  • En automatisant les tâches opérationnelles, vous vous simplifiez le travail et réduisez les coûts.

Si, en plus, vous réécrivez les applications pour les rendre cloud natives, vous bénéficiez d'avantages supplémentaires non négligeables :

  • L'autoscaling vous permet de ne provisionner les ressources informatiques qu'au moment où vous en avez besoin, ce qui évite les coûts de surprovisionnement.

  • Vous disposez de gestionnaires de clusters tels que Kubernetes permettant de renforcer la résilience des applications par redémarrage automatique ou transfert sur d'autres machines en cas de défaillance.

  • Vous disposez de services gérés grâce auxquels vous pouvez réduire encore plus les coûts opérationnels.

  • Vous pouvez automatiser le déploiement afin d'accélérer les processus de développement et de publication des produits. Votre entreprise peut ainsi réagir plus rapidement aux commentaires, ainsi qu'à l'évolution des besoins et du marché.

Modernisation d'une charge de travail en améliorant l'application et en la transférant dans le cloud

Comme le montre ce diagramme, lorsque vous modernisez une charge de travail existante, prévoyez de transférer l'application dans le cloud et de l'améliorer afin de la rendre cloud native.

Migration Improve and Move

Bien qu'il soit courant de transférer une application dans le cloud avant d'investir dans son amélioration, l'approche inverse peut être préférable dans certains cas. Le concept améliorer et déplacer consiste à commencer par refactoriser et moderniser une application en place en vue de sa migration. Avant même que vous ne déplaciez l'application vers le cloud, cette amélioration présente plusieurs avantages :

  • Vous facilitez le processus de déploiement.

  • L'investissement dans une infrastructure et des outils d'intégration/de déploiement continus (CI/CD) permet d'accélérer la cadence de publication et de raccourcir les cycles de commentaires.

Une fois l'amélioration effectuée, vous déplacez l'application vers le cloud, ce qui permet d'accélérer le provisionnement des ressources et d'améliorer la rentabilité grâce à l'autoscaling, lequel élimine les coûts de surprovisionnement.

Pour que l'amélioration et le déplacement fonctionnent correctement, prévoyez certains investissements dans l'infrastructure et les outils sur site, tels que la configuration d'un registre Docker local et le provisionnement de clusters Kubernetes pour la conteneurisation des applications.

Migration Rip and Replace

L'approche rip and replace consiste à supprimer un système et à le remplacer. Dans certains cas, tenter de faire évoluer un système et un codebase existants n'est pas rentable, ni même possible. Les conditions peuvent avoir changé de façon importante ou l'application existante peut être basée sur une pile logicielle ou matérielle inadaptée aux futurs investissements. Dans de tels cas, mieux vaut remplacer le système, soit en achetant une nouvelle solution, soit en développant une application plus moderne et cloud native en partant de zéro.

Combiner plusieurs approches de migration

Les trois approches de migration ont chacune leurs points forts et leurs 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.

Choisissez l'approche "Lift and shift" pour les charges de travail qui remplissent au moins l'une de ces conditions :

  • Le nombre de dépendances dans leur environnement est relativement faible.
  • Il ne semble pas utile de les refactoriser.
  • Elles sont basées sur des logiciels tiers.

Privilégiez l'approche "améliorer et déplacer" 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 sont peu adaptées à un déploiement automatisé.

Enfin, la méthode "rip and replace" peut être préférable pour les charges de travail qui répondent à ces caractéristiques :

  • Elles ne satisfont plus les exigences actuelles.
  • 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.

Portabilité

Dans la plupart des migrations, le transfert d'une charge de travail vers le cloud constitue une opération unique et irréversible. Toutefois, dans le cas d'un scénario hybride, en particulier multicloud, vous aurez peut-être besoin plus tard de transférer des charges de travail entre différents clouds. Pour ce faire, vous devez vous assurer de la portabilité de vos charges de travail :

  • Veillez à pouvoir déplacer une charge de travail d'un environnement informatique vers un autre sans modification importante.
  • Veillez à maintenir la cohérence du déploiement et de la gestion des applications dans tous les environnements informatiques.
  • Veillez à ne pas créer de conflit entre le fait d'assurer la portabilité de la charge de travail et celui de maintenir ses caractéristiques cloud natives.

Au niveau de l'infrastructure, vous pouvez utiliser des outils tels que Terraform afin d'automatiser et d'unifier la création de ressources d'infrastructure, par exemple des VM ou des équilibreurs de charge dans des environnements hétérogènes. 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 vous servir d'un outil de génération d'images tel que Packer afin de créer des images de VM pour différentes plates-formes à l'aide d'un seul fichier de configuration partagé. 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 semblable à celle du diagramme ci-dessous. Cette chaîne d'outils élimine les différences entre les environnements informatiques et vous permet d'unifier le provisionnement, le déploiement, la gestion et la surveillance.

Chaîne d'outils qui élimine les différences entre les environnements informatiques et permet d'unifier le provisionnement, le déploiement, la gestion et la surveillance

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

  • Vous n'aurez peut-être pas accès à certaines fonctionnalités natives d'un environnement cloud. Plus précisément, l'utilisation de VM en tant que socle commun rend difficile la mise en œuvre d'applications véritablement cloud natives. Parfois, l'accès à des services gérés n'est pas possible à partir de VM. Vous risquez donc de manquer des occasions de réduire les frais d'administration.

  • La mise en place et la maintenance de la chaîne d'outils entraînent des frais généraux et opérationnels.

  • Au fil du temps, la chaîne d'outils peut devenir complexe et créer des problèmes spécifiques à votre entreprise. Cette complexité peut générer une augmentation des coûts de formation.

Conteneurs et Kubernetes

La création et la maintenance d'une chaîne d'outils personnalisée pour réaliser la portabilité de la charge de travail à l'aide de VM posent de nombreux défis. Une solution consiste à tirer parti des conteneurs et de Kubernetes.

Les conteneurs améliorent la fiabilité d'exécution du logiciel lorsque vous le déplacez d'un environnement à un autre. Kubernetes gère l'orchestration, le déploiement, le scaling et la gestion de vos applications en conteneurs, en fournissant les services qui constituent la base d'une application cloud native. É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.

  • La technologie Kubernetes utilise les conteneurs Docker, une norme reconnue dans le secteur pour la création de packages d'applications, qui n'est liée à aucun fournisseur spécifique. Elle correspond elle-même à un produit Open Source et régi par la Cloud Native Computing Foundation.

Pour éviter le travail d'installation et d'exécution de Kubernetes, optez pour une plate-forme Kubernetes gérée, telle que Google Kubernetes Engine (GKE). Le personnel affecté pourra ainsi se consacrer davantage aux applications qu'à l'infrastructure. Le diagramme ci-dessous représente un exemple de plate-forme Kubernetes gérée.

Plate-forme Kubernetes gérée

Limites de la portabilité des charges de travail

Afin d'améliorer la portabilité des charges de travail, Kubernetes fournit une couche d'abstraction qui peut masquer de nombreuses subtilités et différences entre les environnements informatiques. Cette abstraction présente toutefois certaines limites :

  • 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. La copie ou le déplacement des données entre les environnements requiert du temps, des efforts et de l'argent. Par ailleurs, ces derniers n'utilisent généralement pas les mêmes services et installations pour le stockage et la gestion de ces données.

  • Kubernetes offre un moyen unifié pour provisionner différents types d'équilibreurs de charge. Leur comportement n'est cependant pas défini en détail et peut différer légèrement d'un environnement à l'autre.

  • GKE intègre le contrôle d'accès basé sur les rôles (RBAC, Role-Based Access Control) via la fonctionnalité de gestion de l'authentification et des accès. Toutefois, dans d'autres environnements, les méthodes de configuration du contrôle d'accès RBAC et de sécurisation des charges de travail peuvent différer.

Même avec Kubernetes, il peut être difficile d'éliminer les différences entre les environnements informatiques et les clouds publics. La portabilité de la charge de travail vise principalement à simplifier les migrations entre environnements et non à les automatiser.

Évaluation des charges de travail

Lorsque de nouveaux projets sont actifs et que des centaines, voire des milliers, de charges de travail sont déjà en cours d'exécution, choisir les charges de travail à déployer ou à migrer vers tel ou tel environnement informatique peut sembler complexe.

Pour vous aider à prendre des décisions cohérentes et objectives, pensez à classer et à évaluer les charges de travail par opportunité, par risque et par difficulté technique.

Ces facteurs vous aideront à évaluer les opportunités de migration :

  • Potentiel offert par l'utilisation de services cloud en termes de différenciation ou d'innovation sur le marché
  • É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
  • Accélération potentielle des processus de développement et de publication

Ces facteurs vous aideront à évaluer les risques de migration :

  • Impact potentiel des pannes provoquées par une migration ou par votre manque d'expérience des déploiements cloud publics
  • Nécessité de vous conformer aux restrictions légales ou réglementaires

Ces facteurs vous aideront à évaluer les difficultés techniques d'une migration :

  • Taille, complexité et ancienneté de l'application
  • Nombre de dépendances avec d'autres applications
  • 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é les charges de travail initiales, vous pouvez commencer à les hiérarchiser, et à identifier les modèles d'architecture et les topologies de réseau applicables. Cette étape peut nécessiter plusieurs itérations. Votre évaluation pouvant évoluer avec le temps, pensez à réévaluer les charges de travail après vos premiers déploiements cloud.

Étapes suivantes