Mise en œuvre de microservices dans des environnements de production

Informatec Digital » Ressources » Mise en œuvre de microservices dans des environnements de production

Adopter une architecture de microservices en environnement réel ne se résume pas à décomposer un monolithe en éléments plus petits ; cela implique de repenser l’infrastructure, les équipes, les processus, les données, la sécurité et les opérations . Lors du passage de la théorie à la production, des problèmes surgissent concernant la découverte de services, les contrats entre équipes, l’intégration et le déploiement continus (CI/CD), l’observabilité, la résilience et la scalabilité. Si ces problèmes ne sont pas correctement traités, ils peuvent transformer les microservices en un chaos distribué.

La bonne nouvelle, c'est que nous bénéficions aujourd'hui d'une riche expérience accumulée par des organisations comme Netflix, Amazon, Google et d'autres grandes entreprises qui exploitent des centaines de microservices en production . En nous appuyant sur ces enseignements, ainsi que sur les meilleures pratiques en environnements d'entreprise utilisant Kubernetes et OpenShift, nous pouvons développer une approche très robuste pour concevoir, déployer et exploiter des microservices à grande échelle tout en gardant le contrôle.

Pourquoi déployer des microservices en production (et quand cela n'en vaut pas la peine)

Une architecture de microservices bien conçue permet de travailler avec des équipes restreintes, autonomes et pluridisciplinaires, responsables de l'intégralité du service. Chaque équipe opère dans un contexte précis, peut déployer fréquemment et assumer l'entière responsabilité de son service, ce qui réduit le cycle de développement et accélère la mise en œuvre de nouvelles fonctionnalités.

Un autre avantage clé réside dans la mise à l'échelle indépendante de chaque service . Inutile de surdimensionner l'application entière si seuls le catalogue, la page de paiement ou l'API publique connaissent des pics de trafic. Vous pouvez ajuster chaque microservice horizontalement ou verticalement en fonction de sa charge, mesurer précisément le coût de chaque fonctionnalité et garantir la disponibilité même en cas de forte augmentation de la consommation dans une zone spécifique.

La manière dont ces services sont conçus et déployés facilite une mise en œuvre continue et à faible risque . Le déploiement indépendant de chaque microservice simplifie considérablement le test de nouvelles idées et la restauration des versions problématiques : les déploiements progressifs, les retours en arrière (blue/green) et les restaurations automatisées réduisent le coût des échecs et offrent un espace d’expérimentation.

D'un point de vue technologique, les microservices offrent la liberté de choisir les langages, les frameworks et les bases de données pour chaque service. Tous les besoins ne s'inscrivent pas dans la même pile technologique : on peut avoir des services métier en .NET ou Java, du traitement de données en Scala/Spark, des services spécialisés en Python ou F#, ou encore des microservices d'IA en R. Cette diversité maîtrisée permet d'utiliser l'outil le plus adapté à chaque cas, sans imposer à l'ensemble de l'application une refonte technologique globale.

De plus, la décomposition du système en petits éléments bien définis facilite la réutilisation des fonctionnalités comme briques de base . Un microservice initialement créé pour une fonctionnalité plus vaste peut ensuite être réutilisé comme dépendance d'autres parties du système sans qu'il soit nécessaire de réécrire sa logique. Enfin, grâce à l'isolation des services, une défaillance de l'un d'eux entraîne généralement une dégradation partielle du système, et non une interruption totale, à condition que la résilience ait été intégrée dès la conception.

Conception architecturale et de services

Pour que les microservices fonctionnent correctement en production, il est essentiel de commencer par une conception rigoureuse des limites et des responsabilités des services . Concrètement, cela commence généralement par l'identification de services à granularité grossière au sein du monolithe existant : de grands domaines fonctionnels ou métiers (par exemple, les commandes, le catalogue, les utilisateurs, la facturation) qui présentent déjà une certaine séparation logique.

À partir de ces grands éléments de base, le processus consiste à affiner la conception pour obtenir des microservices finement granulaires qui exploitent un ensemble de données cohérent , possèdent leur propre modèle et savent précisément quelles données lire ou écrire dans d'autres services. Ce processus s'appuie généralement sur les concepts de conception pilotée par le domaine (DDD) et les contextes délimités, empêchant ainsi un microservice de devenir un « mini ​​monolithe ».

Les API exposant ces services doivent disposer de contrats bien définis et stables . Cela implique une documentation rigoureuse (REST avec OpenAPI, gRPC avec fichiers .proto, etc.), un versionnage explicite, le maintien de la rétrocompatibilité lorsque cela est possible et l'automatisation de la validation des contrats afin de détecter les changements susceptibles d'entraîner des ruptures de compatibilité avant leur mise en production.

Dans les environnements comportant des dizaines, voire des centaines de services, il est crucial d'intégrer des mécanismes de résilience dès la conception, afin de préparer le système aux pannes partielles . Des mécanismes tels que les disjoncteurs, les tentatives de redémarrage avec temporisation, les délais d'attente clairement définis, les cloisonnements et la gestion de la contre-pression contribuent à empêcher la défaillance d'un service d'entraîner l'arrêt des autres. Les outils d'ingénierie du chaos comme ChaosMonkey ou Gremlin sont utiles pour tester concrètement le comportement de la plateforme lors de pannes simulées.

De nombreux systèmes complexes combinent des services CRUD relativement simples avec des services plus sophistiqués gérant l'évolution des règles métier. Tous les microservices ne nécessitent pas une architecture interne complexe : certains peuvent être de simples contrôleurs HTTP avec un accès basique aux données, tandis que d'autres, comme les services de commande ou de facturation, peuvent exploiter des modèles plus avancés (DDD, CQRS, événements de domaine, etc.).

Infrastructure de production : cloud, conteneurs et Kubernetes/OpenShift

L'expérience pratique montre que les microservices sont bien plus performants lorsqu'ils sont déployés sur une infrastructure cloud avec des conteneurs et une orchestration que sur des machines virtuelles isolées. Des plateformes comme Kubernetes et OpenShift fournissent les primitives nécessaires pour conteneuriser les services, les mettre à l'échelle, les mettre à jour, équilibrer la charge et garantir une haute disponibilité.

En règle générale, chaque microservice est encapsulé dans une image conteneurisée basée sur une image de base d'entreprise (par exemple, OpenJDK 21 pour les services Java) gérée par l'équipe d'infrastructure. Cette image de base est mise à jour régulièrement avec les correctifs de sécurité, et lors de la publication d'une nouvelle version, les équipes de développement sont chargées de reconstruire et de redéployer leurs services dans les environnements correspondants.

Dans Kubernetes/OpenShift, l'unité de déploiement de base est le pod, qui encapsule un ou plusieurs conteneurs . Généralement, un microservice correspond à un type de pod et est déployé à l'aide de ressources telles que les Deployments (pour les services sans état) ou les StatefulSets (lorsqu'un état est associé). Dès le départ, un nombre minimal de réplicas par environnement est défini afin que les environnements de test, de préproduction et de production bénéficient de niveaux de disponibilité adaptés à leur criticité.

La mise à l'échelle automatique est assurée par HorizontalPodAutoscaler (HPA) , qui ajuste le nombre de réplicas en fonction de métriques telles que l'utilisation du processeur, de la mémoire ou d'autres métriques personnalisées. La plateforme doit également configurer des règles d'anti-affinité pour les pods afin de répartir les réplicas d'un même service sur différents nœuds, évitant ainsi qu'une panne sur un seul nœud n'entraîne l'arrêt de toutes les instances.

Concernant le dimensionnement vertical, les propriétés `resources.requests` et `resources.limits` permettent de définir la plage de CPU et de mémoire qu'un pod peut consommer. Par exemple, on peut réserver un minimum de 100 Mo de CPU et 256 Mo de mémoire, et autoriser jusqu'à 500 Mo et 2 Go respectivement pour un service Java, en ajustant la JVM (Xms, Xmx, Xss) afin d'optimiser l'utilisation des ressources du conteneur.

Gestion d'état : microservices sans état et microservices avec état

La plupart des microservices métier sont conçus comme des services sans état . Cela signifie que le pod ne stocke aucune information devant survivre aux redémarrages ; l’état est persisté dans des bases de données externes, des files d’attente de messages ou d’autres systèmes de stockage. Cette approche facilite la mise à l’échelle horizontale dynamique et les déploiements sans friction, car n’importe quelle réplique peut traiter n’importe quelle requête.

Cependant, dans certains cas, l' utilisation de volumes persistants pour les microservices avec état est indispensable . C'est le cas de certaines bases de données, systèmes de fichiers distribués ou composants nécessitant la conservation de données locales. Ces pods sont généralement déployés avec des StatefulSets, liés à des PersistentVolumes via des PersistentVolumeClaims, et leur mise à l'échelle est verticale plutôt qu'horizontale.

Lorsqu'un microservice nécessite un stockage persistant, une PersistentVolumeClaim (PVC) est demandée, précisant sa taille, son mode d'accès et son utilisation prévue . L'équipe d'exploitation la provisionne ensuite conformément aux politiques de la plateforme. Cette PVC est référencée dans le manifeste de déploiement et montée sur le pod afin que le service puisse lire et écrire des données de manière persistante.

Bien que les modèles avec état puissent s'avérer nécessaires dans certains cas, il est généralement recommandé de privilégier les services sans état . Cela simplifie le déploiement, la mise à l'échelle, la résilience et la reprise après sinistre, et réduit la complexité opérationnelle dans les environnements comportant de nombreux microservices.

Décentralisation des données et souveraineté des services

Dans les infrastructures traditionnelles, il est courant de centraliser les bases de données et le stockage pour optimiser l'efficacité. Avec les microservices, cette approche entre en conflit avec l'autonomie des équipes et le découplage . Si de nombreux services partagent le même schéma relationnel, toute modification structurelle peut bloquer plusieurs équipes et entraîner des problèmes de compatibilité.

Il est donc recommandé que chaque microservice possède son propre modèle de données et sa propre base de données . En environnement de développement, cette base de données s'exécute dans un conteneur au sein du cluster afin de simplifier le déploiement. En production, on utilise généralement des instances gérées dans le cloud ou d'autres serveurs de bases de données à haute disponibilité, en veillant toujours à maintenir une séparation claire des responsabilités.

Cela ne signifie pas qu'il n'y a pas d'intégration de données ; cela signifie que la cohérence entre les services est gérée par des événements et une messagerie asynchrone , en acceptant une cohérence éventuelle lorsque cela est pertinent. Il est courant d'utiliser des bus d'événements (RabbitMQ, Azure Service Bus, Kafka, etc.) pour propager les changements d'état entre les microservices, réduisant ainsi les fortes dépendances à une base de données unique.

La plateforme cloud permet aux équipes de choisir facilement le type de base de données optimal pour chaque service (relationnelle, documentaire, clé-valeur, séries temporelles, etc.), sans imposer de technologie unique. L'essentiel est que la conception prenne en compte la possibilité de migrer les schémas et les structures sans rompre les contrats avec les autres services, et que les décisions relatives aux données soient prises en cohérence avec les limites du domaine de chaque microservice.

Gouvernance distribuée, équipes et organisation

Passer aux microservices sans restructurer l'organisation, c'est s'exposer à des difficultés. Au lieu des silos fonctionnels classiques (réseaux, systèmes, bases de données, développement et opérations) , une structure basée sur des équipes produit est préconisée, regroupant des profils issus du développement, de l'assurance qualité, du DevOps et, le cas échéant, de l'analyse métier ou des données.

Chaque équipe est responsable d'un ou plusieurs microservices au sein du même domaine fonctionnel, et prend en charge à la fois le développement et l'exploitation (vous le construisez, vous l'exécutez) . Cela signifie que l'équipe gère ses pipelines CI/CD, collabore avec l'équipe infrastructure pour les besoins spécifiques et participe à la surveillance et à la gestion des incidents. L'infrastructure et la plateforme cloud visent à fournir des services communs et standardisés.

Pour éviter que cette gouvernance distribuée ne sombre dans l'anarchie, il est crucial de définir des normes légères et des catalogues partagés : images de base approuvées, modèles de déploiement, conventions de nommage pour les espaces de noms et les services, directives relatives aux API, modèles Dockerfile et Kustomize, etc. Ces directives servent de « garde-fous » qui orientent les équipes sans entraver leur capacité à prendre des décisions.

Dans de nombreux environnements d'entreprise, des espaces de noms distincts sont utilisés pour chaque projet ou domaine , avec au moins un par environnement (développement, préproduction, production). Un projet de grande envergure peut répartir ses microservices sur plusieurs espaces de noms, à condition que les communications internes soient correctement configurées et que les règles de sécurité soient respectées.

CI/CD, automatisation et modèle GitOps

Lorsqu'une architecture comprend des dizaines, voire des centaines de microservices, le seul moyen d'assurer son fonctionnement est d'investir massivement dans l'automatisation de bout en bout . Cela inclut des pipelines CI/CD cohérents, des définitions de déploiement déclaratives, des tests automatisés et des mécanismes de restauration automatiques.

Un pipeline d'intégration et de déploiement continus classique gère la compilation du code, l'exécution des tests, l'analyse de la qualité avec des outils comme SonarQube , la création de l'image conteneurisée à partir du Dockerfile d'entreprise et la mise à jour des manifestes de déploiement. Ensuite, un système comme ArgoCD ou équivalent applique les modifications au cluster selon une approche GitOps.

Chaque dépôt de microservices comprend généralement un Dockerfile standardisé, un fichier de configuration de pipeline (par exemple, ci.json) , des propriétés pour l'analyse de la qualité et un répertoire de déploiement contenant les définitions Kubernetes (Kustomize ou Helm) organisées par environnement. Les webhooks du dépôt déclenchent le pipeline lors d'événements tels que l'ajout de tags ou la création de demandes de fusion.

Le modèle GitOps établit le dépôt Git comme source unique de référence pour l'infrastructure et le déploiement . Les manifestes des déploiements, des services, des ConfigMaps, des PVC, des SealedSecrets et autres ressources y sont versionnés, et des outils spécifiques gèrent la synchronisation de l'état du cluster avec les données définies dans Git. Ceci garantit la traçabilité, la validation des demandes de fusion et une restauration aisée.

Paramètres, secrets et sécurité

Dans une plateforme de microservices mature, la gestion de la configuration repose sur les ConfigMaps pour les paramètres non sensibles et les Secrets pour les informations confidentielles . Chaque microservice possède généralement sa propre ConfigMap spécifique à son environnement, qui stocke des propriétés telles que les URL des services dépendants, les indicateurs de fonctionnalité et les paramètres de configuration.

Les secrets (identifiants, clés, jetons, certificats) sont gérés selon des politiques de sécurité strictes . Dans les environnements moins critiques, il peut être acceptable de les conserver en clair, gérés par l'équipe de développement. Cependant, dans les environnements de préproduction et de production, il est recommandé de les chiffrer à l'aide d'outils tels que Sealed Secrets ou de gestionnaires externes spécifiques basés sur le cloud.

Lorsqu'un secret doit être partagé entre plusieurs services (par exemple, les identifiants OTEL Collector ou un magasin de clés commun ), il peut être centralisé dans un référentiel de configuration par espace de noms. Les projets partageant cet espace de noms se coordonnent pour le mettre à jour selon les besoins, en gardant le contrôle sur les personnes autorisées à lire ou à modifier ces ressources.

En matière de sécurité des communications, le modèle dominant est le Zero Trust : rien n’est laissé au hasard, même si le trafic est « interne ». Tous les appels entre services, internes comme externes, doivent être authentifiés et autorisés, idéalement avec mTLS, des jetons JWT ou d’autres mécanismes équivalents. Les microservices ne délèguent pas aveuglément la sécurité au gestionnaire d’API ou au réseau ; ils effectuent également leurs propres contrôles.

Communication entre microservices, API et messagerie

Dans une architecture de microservices mature, la couche de communication est divisée en plusieurs cas. Pour le trafic des clients (navigateurs, applications mobiles, tiers) vers le serveur, des API publiques gérées par un gestionnaire d'API sont utilisées . Ces API sont généralement RESTful (souvent basées sur OpenAPI) ou, dans certains cas, gRPC exposées via une passerelle.

Les appels entre microservices situés dans le même espace de noms, voire entre plusieurs espaces de noms au sein d'un même projet, sont généralement gérés par des services Kubernetes internes utilisant un DNS interne . Ces appels contournent l'API Manager publique tout en respectant les politiques de sécurité, d'authentification et d'autorisation. Dans ces cas, un maillage de services ou des passerelles internes appliquant des politiques communes peuvent être utilisés.

Lorsque des microservices appartiennent à différents domaines fonctionnels ou projets , la communication est considérée comme « publique » au niveau de l'organisation. Dans ce cas, il est courant d'utiliser un gestionnaire d'API ou un bus d'interopérabilité, qui gère les contrats, les quotas, la sécurité, le versionnage et l'audit, empêchant ainsi le couplage direct entre les clusters ou espaces de noms indépendants.

Pour l'intégration avec des systèmes existants ou externes, qui n'exposent pas toujours d'API modernes, il est courant d'utiliser des connecteurs spécifiques via un bus d'interopérabilité . Ainsi, les microservices communiquent via un langage commun (par exemple, des événements ou des API REST internes), et le connecteur assure la traduction entre les systèmes existants et le système existant, le tout avec une sécurité renforcée.

Outre la communication synchrone, la messagerie asynchrone joue un rôle essentiel . Elle permet de découpler les processus, d'absorber les pics de charge, de propager les événements métier entre les services et d'améliorer la résilience. Chaque événement possède généralement un schéma bien défini et versionné, avec des mécanismes de suivi pour prévenir les ruptures entre producteurs et consommateurs au fil de leur évolution.

Observabilité, collecteur OTEL et fonctionnement

Dans un système composé de nombreux microservices, diagnostiquer un problème sans une bonne visibilité est quasiment impossible. C'est pourquoi les métriques, la journalisation centralisée et les traces distribuées sont intégrées dès la conception , permettant ainsi de comprendre ce qui se passe au niveau des services et de la plateforme.

L'élément central de ce système est le collecteur OpenTelemetry (OTEL Collector) , déployé dans l'espace de noms ou de manière centralisée pour collecter les métriques, les journaux et les traces de tous les composants. Les microservices doivent simplement savoir qu'ils doivent envoyer leurs données de télémétrie au collecteur ; celui-ci les transmet ensuite aux systèmes d'observabilité (Prometheus, Grafana, Jaeger, Elastic, etc.) sans que le service n'ait besoin d'en connaître les détails.

Au niveau de l'infrastructure, des collecteurs et exportateurs au niveau des nœuds permettent de collecter les métriques CPU, mémoire, disque, réseau et de journalisation des pods, puis de les envoyer respectivement à Prometheus et Elasticsearch. Des outils comme Grafana et Kibana servent à visualiser ces informations, à créer des tableaux de bord et à définir des alertes avec des seuils intelligents et des procédures d'exécution associées.

Lorsqu'un projet nécessite un traitement très spécifique de ses métriques ou de ses traces, il peut déployer sa propre instance d'OTEL Collector dans son espace de noms, à condition d'avoir obtenu l'approbation opérationnelle et que le modèle de maintenance de la production soit clair.

Stratégie de test, contrats et expérience de développement local

Tester une architecture de microservices distribuée exige une stratégie de test plus sophistiquée que de tester une application monolithique. Les tests unitaires restent essentiels, mais les tests de contrat (pour les API et les événements), les tests d'intégration entre les services et les tests de bout en bout couvrant l'intégralité des flux deviennent de plus en plus importants.

Pour éviter les problèmes de compatibilité, on utilise des techniques comme les tests de contrats orientés client , où les clients définissent leurs attentes en matière d'API et les fournisseurs de services y répondent. Chaque modification de contrat fait l'objet de tests automatisés au sein des pipelines d'intégration continue, empêchant ainsi les déploiements qui perturberaient le fonctionnement des clients connus.

Lorsque le nombre de services dépasse la centaine, la réplication locale de l'intégralité du système devient impraticable. Le développement s'appuie alors sur la simulation des services dépendants ou sur l'accès à des environnements distants . Les développeurs lancent généralement un sous-ensemble de microservices et simulent les autres à l'aide de mocks, de fakes ou de simulateurs, ou redirigent certains appels vers un environnement d'intégration partagé.

Les tests de bout en bout s'appuient de plus en plus sur des environnements éphémères ou « aperçus » créés à partir de branches de fonctionnalités . Ces environnements isolés contiennent les services nécessaires à la fonctionnalité concernée. Cela minimise les frictions entre les équipes, réduit l'effet « ça marche sur ma machine » et détecte les problèmes d'intégration avant d'atteindre des environnements plus coûteux comme la préproduction.

Modèles de déploiement de microservices en production

Au-delà de Kubernetes, plusieurs modèles de déploiement de microservices en production méritent d'être connus, car ils répondent à différents besoins en matière d'isolation, de coût et de maturité . L'un des plus anciens consiste à déployer plusieurs instances de service par hôte : un seul hôte physique ou virtuel exécute plusieurs instances de services différents, généralement sur un serveur d'applications partagé.

Dans le modèle d'instance de service par machine virtuelle , chaque service est conditionné sous forme d'image de machine virtuelle (par exemple, une AMI EC2) et s'exécute sur sa propre instance. Ce modèle offre une isolation renforcée, mais au prix d'une consommation de ressources plus élevée et de temps de démarrage plus longs. Des outils comme Packer ou les solutions spécifiques aux fournisseurs de cloud facilitent la génération d'images de machines virtuelles prêtes pour la production.

Le modèle le plus répandu aujourd'hui est celui des instances de service par conteneur , où chaque microservice est construit sous forme d'image conteneur et déployé sur un orchestrateur (Kubernetes, OpenShift, etc.). Les conteneurs sont plus légers que les machines virtuelles, démarrent très rapidement et permettent d'intégrer tout le nécessaire au service, simplifiant ainsi les déploiements et autorisant la mise à l'échelle automatique.

Enfin, les approches sans serveur, telles qu'AWS Lambda , ont gagné en popularité. Elles proposent des fonctions qui répondent aux requêtes HTTP ou aux événements provenant d'autres services (S3, DynamoDB, files d'attente, etc.), les utilisateurs ne payant que pour ce qu'ils consomment. Ce modèle est particulièrement adapté aux microservices de très petite taille ou aux tâches événementielles de courte durée, bien qu'il soulève des questions supplémentaires concernant l'observabilité, les démarrages à froid et les limites d'exécution.

En pratique, de nombreuses organisations finissent par adopter un écosystème hybride : la partie centrale du système fonctionne sur des conteneurs et des orchestrateurs, tandis que certains composants auxiliaires sont implémentés sous forme de fonctions sans serveur ou de machines virtuelles spécialisées, toujours avec des interfaces claires et des protocoles bien définis pour les intégrer à l’ensemble.

Pour la mise en production de cette architecture, la différence ne réside pas seulement dans la technologie choisie, mais aussi dans la mise en place d'une architecture tolérante aux pannes, évolutive selon les besoins, déployable automatiquement et observable . Grâce à des équipes alignées sur le produit, des contrats bien gérés, des données décentralisées et une plateforme cloud robuste, les microservices passent du statut de promesse à celui de solution efficace et durable pour faire évoluer des applications complexes sur le long terme.