Architecture multicloud : tirer le meilleur de Google Cloud

Défis et opportunités d'une solution hybride ou multicloud avec Google Cloud

Les entreprises sont de plus en plus nombreuses à adopter des solutions hybrides et multicloud reposant sur Google Cloud. Certaines sont des startups qui développent leur clientèle en allant au-devant de leurs utilisateurs ; d'autres sont de grands groupes en quête du meilleur outil pour résoudre leurs problèmes, garantir une haute disponibilité ou diversifier leurs fournisseurs afin de réduire les risques. Avant de se lancer dans la conception d'une solution hybride/multicloud (généralement dans le cadre d'un projet plus large de modernisation applicative), mieux vaut connaître les défis et les opportunités qui en découlent.

Dans cet article, j'aborderai ces sujets pour mettre en lumière les profils d'entreprises auxquels cette option convient, les écueils à anticiper, les solutions disponibles, mais aussi les situations dans lesquelles il vaut mieux y renoncer (du moins à court terme).

Définitions

Commençons par quelques définitions :

• Cloud public – services informatiques et infrastructures à la demande, gérés par un fournisseur tiers et partagés entre plusieurs organisations via l'Internet public
• Cloud privé – infrastructure dédiée à une seule organisation utilisatrice ; elle peut être hébergée dans le centre de données de l'organisation ou dans une installation de colocation tierce
• Cloud hybride – combine des services on-premises, de cloud privé et de cloud public tiers, et orchestre les échanges entre les plateformes
• Multicloud – combine plusieurs services de calcul et de stockage cloud au sein d'une même architecture hétérogène ; désigne également la répartition d'actifs cloud, de logiciels, d'applications, etc. entre plusieurs environnements d'hébergement cloud
• Application legacy – système d'information potentiellement basé sur des technologies obsolètes, mais critique pour les opérations quotidiennes ; généralement des applications monolithiques à trois niveaux, fragiles et difficiles à maintenir et à faire évoluer
• Application moderne – désigne généralement une application composée de microservices au sein d'une architecture N-Tier. Elle est aussi fiable que nécessaire et peut être mise à jour plusieurs fois par jour sans impacter la production (pour une définition plus large, voir l'application Twelve Factor).

Cas d'usage

Cette liste n'est pas exhaustive :

1. Étape intermédiaire dans la migration d'une infrastructure informatique dont le déplacement vers le cloud présente une difficulté modérée : par exemple, un client dispose d'un parc important de serveurs on-prem (généralement Linux ou Windows), une connexion est établie via VPN ou interconnexion, et des groupes de VMs (selon les frontières des workloads applicatifs) sont migrés vers le cloud. Les clients de l'entreprise sont alors servis par une solution hybride, avec une partie des applications fonctionnant on-prem et l'autre dans le cloud, jusqu'à ce que tous les workloads soient migrés vers le cloud public (cloud hybride).
2. Le client souhaite moderniser sa solution mais possède des applications et bases de données très difficiles à migrer vers le cloud : par exemple, un client disposant d'un mainframe ou d'une base Oracle (la difficulté s'est atténuée) dans son environnement de cloud privé, qui souhaite faire évoluer l'application vers une architecture moderne telle que Kubernetes (cloud hybride).
3. Exigences réglementaires : les exigences de régionalité des données peuvent par exemple imposer que certaines informations ne quittent pas les frontières du pays.
4. Cloudbursting : dans ce scénario, une capacité supplémentaire peut être provisionnée automatiquement dans le cloud et mise à l'échelle si l'environnement on-prem est saturé. C'est typiquement le cas dans le retail lors d'événements comme le Black Friday ou le Cyber Monday (cloud hybride).
5. Haute disponibilité et reprise après sinistre (cloud hybride et multicloud)
6. Choisir le bon cloud pour le bon cas d'usage : par exemple, héberger les environnements Kubernetes et d'analytique de données sur Google Cloud Platform (GCP) et les applications adossées à Microsoft sur Azure.
7. Éviter le verrouillage fournisseur (vendor lock-in)

Stack technique et capacités requises

Penchons-nous maintenant sur la stack technique et les capacités à acquérir ou à développer, ainsi que sur les défis qu'elles peuvent représenter pour les entreprises selon leur degré de maturité :

Calcul :

• Maîtriser l'environnement de cloud privé – les VMs et les diverses technologies au niveau de l'hyperviseur : pour les entreprises déjà installées dans un cloud privé, ce n'est évidemment pas un problème. En revanche, pour les entreprises digital native qui n'ont jamais eu à composer avec la stack technique ni avec les enjeux politiques liés au déploiement d'une solution cloud dans un environnement de cloud privé, cela peut représenter un défi de taille.
• Maîtriser l'environnement de cloud public : ce n'est pas un problème pour les entreprises digital native, mais cela peut soulever d'importants enjeux de sécurité et de politique interne pour celles qui opèrent encore on-premises. Elles devront se familiariser avec une nouvelle stack et de nouvelles façons de gérer les VMs, l'autoscaling, etc.

Bases de données et stockage :

• Pour les entreprises actuellement en cloud privé, le défi consiste à se former et à choisir une base de données cloud-native pertinente. Les options simples consistent à passer à des services managés SQL Server/PostgreSQL/MySQL mais, selon les objectifs métier et techniques, certaines entreprises peuvent souhaiter ou devoir migrer vers des technologies comme Spanner, BigTable ou BigQuery. L'exercice peut s'avérer délicat.
• Faire cohabiter deux stacks techniques en parallèle peut être difficile : une entreprise disposant d'une application on-prem adossée à une base Oracle et souhaitant migrer vers PostgreSQL a deux options, selon la complexité et les fonctionnalités utilisées. La première : un lift-and-shift vers une option bare-metal, suivi d'une modernisation. La seconde : laisser l'application en place, la moderniser dans le cloud privé puis la migrer vers le cloud. Dans les deux cas, l'entreprise devra exploiter deux types de bases de données simultanément jusqu'à ce que la modernisation soit achevée et que l'une d'elles puisse être désactivée.

Réseau :

• Il existe des différences notables entre la mise en réseau dans les clouds publics et privés – et même d'un cloud à l'autre. Le VPC global de Google Cloud, par exemple, simplifie considérablement le réseau. De nombreuses entreprises issues du cloud privé doivent en apprendre le fonctionnement. Elles peinent également à renoncer consciemment à reproduire dans le cloud public les pratiques en vigueur dans leur cloud privé.
• La configuration de VPNs, de partner-interconnect et d'interconnects peut être simple dans certains cas, mais aussi prendre des semaines, voire des mois, selon la localisation du cloud privé du client.

Sécurité :

• Mettre en place des mesures de sécurité unifiées et prêtes pour la production dans des environnements hybrides et multicloud peut s'avérer délicat. Chaque fournisseur cloud applique des mesures de sécurité différentes, mises en œuvre de façons différentes. La manière dont vous déployez vos logiciels et testez leurs vulnérabilités au cours du déploiement peut constituer un projet à part entière.
• Mettre en place des systèmes de supervision de la sécurité couvrant plusieurs clouds est un véritable défi.

CI/CD :

• Construire de manière fiable un pipeline d'intégration et de déploiement continus (CI/CD) pour bâtir, tester, sécuriser et déployer à la fois l'infrastructure (IaC – via Terraform ou Pulumi) et les applications dans plusieurs environnements représente un défi de taille. Cela exige aussi des équipes d'ingénierie et un outillage particulièrement aguerris.

Modernisation :

• Décider quoi moderniser et comment, qu'il s'agisse d'applications ou de bases de données, n'a rien d'anodin et requiert d'importantes phases d'évaluation et de planification. L'opération peut prendre des mois, voire des années, et nécessiter un accompagnement au changement organisationnel important pour que les clients du cloud privé apprennent K8s et la meilleure manière de travailler avec ce système.

Authentification :

• L'enjeu consiste à gérer la fédération SSO, la fédération AD, etc. sur plusieurs plateformes via une source unique de vérité.

Équipe :

• Les Engineers et architectes maîtrisant plusieurs plateformes sont rares ; il faut donc investir dans la formation de vos équipes.
• L'alternative consiste à apprendre et à se tenir à jour sur plusieurs environnements dans un univers cloud en mutation rapide, tout en constituant des équipes distinctes aux compétences différentes et en cherchant à définir un processus métier qui leur permette de collaborer efficacement.

Coût :

• À l'image d'un environnement multi-régions à haute disponibilité (HA), une solution multicloud ou hybride peut coûter jusqu'à dix fois plus cher. Il ne s'agit pas seulement d'ajouter une VM ou une base de données et de payer un supplément : les opérations de Day 2 – orchestration, réplication, coûts de sortie réseau, sans oublier le soutien aux équipes et aux mécanismes qui font tourner ces systèmes – finissent par peser lourd.
• Les entreprises doivent réfléchir au FinOps et instaurer une culture où les équipes pilotent leurs coûts cloud, où chacun s'approprie son utilisation, où un groupe central de bonnes pratiques apporte son soutien, et où une vision à 360° des coûts hybrides/multicloud émerge.

Définir une solution

À ce stade, vous vous dites probablement que le multicloud et le cloud hybride sont vraiment difficiles à mettre en œuvre. Pourtant, c'est dans cette direction que va le secteur, et il faut donc trouver une solution.

Il est essentiel de garder en tête que ce type de projets prend du temps, puis de procéder selon la méthodologie suivante :

1. Évaluez la culture de votre entreprise, vos pratiques DevOps, votre stack technique, etc.
2. Planifiez en fonction des objectifs métier et technologiques de votre entreprise et des résultats de l'évaluation. Intégrez le fait que les changements apportés à votre système entraînent des courbes d'apprentissage importantes, en interne comme chez vos clients. Cela peut prendre du temps, et il faut laisser à chacun le temps de s'adapter aux nouvelles méthodes de travail et aux nouvelles technologies.
3. Migrez/refactorisez : démarrez doucement et à petite échelle, autorisez l'échec rapide, tirez les leçons de ces échecs et progressez. En commençant lentement, la cadence augmentera de façon incrémentale. N'essayez pas d'optimiser pendant que vous changez de plateforme, de codebase, etc.
4. Optimisez une fois le changement initial effectué et un nouveau système opérationnel en place. Travaillez l'optimisation à la fois sur le plan des performances et sur celui des coûts.

Construire la stack technique hybride optimale

Aucune solution technologique du marché ne résoudra tout. Vous devez évaluer votre stack et combiner différentes solutions pour bâtir une stack hybride complète.

Couche applicative :

GCP Anthos est une excellente solution qui couvre plusieurs aspects nécessaires à l'exploitation de la couche code/application de votre solution. Elle inclut les couches suivantes, qui vous permettent d'orchestrer et d'exécuter des clusters Kubernetes et même des VMs (en private preview) sur GCP, AWS, Azure, en cloud privé et en bare metal.

Couches applicatives de Google Cloud Anthos

Les clusters Anthos, la couche Kubernetes managée à la base de la stack, simplifient considérablement les opérations de Day 2 par rapport à l'exécution de vos propres clusters Kubernetes open source.

Anthos Ingress est un contrôleur Ingress multi-cluster hébergé dans le cloud, destiné aux clusters GKE.

Anthos Service Mesh est une suite d'outils pour superviser et gérer un service mesh fiable, on-premises ou sur Google Cloud.

Anthos Config Management est un service de gestion de configuration et de politiques qui combine trois composants : Policy Controller, Config Sync et Config Controller. Ensemble, ils permettent à Anthos Config Management de protéger et de configurer en continu vos ressources Google Cloud et Kubernetes.

Les fleets Anthos (anciennement environs) sont un concept Google Cloud permettant d'organiser logiquement les clusters et autres ressources, afin d'utiliser et de gérer des fonctionnalités multi-cluster et d'appliquer des politiques cohérentes dans l'ensemble de vos systèmes.

Limitations : il est important de noter que le service se limite au contrôle et à la supervision des seules parties de votre solution qui s'exécutent au sein de l'environnement Anthos.

Couche bases de données et stockage :

• Si vous exploitez vos propres couches de stockage et de base de données en dehors du périmètre du cluster, vous pouvez tirer parti de services de bases de données managés tels que CloudSQL ou RDS.
• Si vous exploitez votre base de données au sein de votre cluster Kubernetes (par exemple MySQL ou MongoDB), vous ajoutez une charge opérationnelle importante par rapport à l'utilisation des versions managées proposées par le fournisseur cloud.

Sécurité et supervision :

• SIEM et supervision : recherchez des outils proposant une solution multicloud/hybride, tels que Splunk, Datadog ou PagerDuty.
• Gestion de la sécurité et des secrets : par exemple HashiCorp Vault et AWS Secrets Manager.

CI/CD :

• Des solutions du marché telles que GitLab et Jenkins fonctionnent dans différents environnements et permettent de construire et de déployer aussi bien des conteneurs que des VMs.

Si vous n'avez pas besoin de construire et de déployer des VMs, regardez du côté de Spinnaker.

Provisionnement de l'infrastructure :

• Parmi les options : HashiCorp Terraform, Red Hat Ansible et Pulumi.

Pour conclure :

• Construire une solution hybride/multicloud est très difficile et très coûteux, tant du point de vue des personnes et des processus que sur le plan technologique.
• Des technologies telles que GCP Anthos prennent en charge une solution multicloud, mais aucune technologie ne fournit à elle seule une solution de bout en bout. Il faut en tenir compte lors de la conception de l'architecture de votre solution.
• Le processus sera plus simple pour les entreprises qui exécutent déjà Kubernetes en production à grande échelle, on-prem ou dans le cloud.
• Il sera le plus difficile pour :

  • Les entreprises qui exploitent des applications monolithiques legacy on-prem. Construire une solution hybride et opérer la transformation requise au niveau des processus métier, de la montée en compétences des équipes et de l'évolution de la stack technique peut prendre entre deux et dix ans, selon la complexité et l'ampleur du changement.

    C'est dans cette direction que va le marché, et les entreprises qui mènent ce projet à bien obtiennent un ROI significatif. Toutefois, en se lançant dans une telle aventure, mieux vaut tempérer ses attentes en mesurant l'ampleur du défi.

  • Les startups aux équipes réduites : Kubernetes est un sujet passionnant et stimulant, et votre startup veut servir tous ses clients dans tous les environnements, mais les ressources sont limitées et il vous faut un produit fonctionnel avec la charge opérationnelle et le coût les plus faibles possibles. Compte tenu des défis inhérents, concentrez-vous d'abord sur un produit viable (en gardant à l'esprit la portabilité des workflows) et sur une base de clients hébergée sur un seul cloud, en utilisant un maximum de services entièrement managés. Une fois que votre équipe sera suffisamment étoffée et la solution suffisamment stable, vous pourrez explorer la façon de refactoriser et d'exploiter une solution multicloud.

Si vous souhaitez en savoir plus sur ce sujet et voir une démonstration du fonctionnement d'Anthos dans un environnement multicloud, inscrivez-vous à notre événement le 22 février 2022 à 13 h GMT.

N'hésitez pas à nous contacter si vous avez des questions ou souhaitez échanger sur votre parcours vers une application moderne dans un environnement hybride ou multicloud.