Que sont les microservices ?
Les microservices sont un style d'architecture logicielle dans lequel une application est construite comme un ensemble de petits services, chacun tournant dans son propre processus et communiquant par des mécanismes légers, souvent une API HTTP. C'est la définition que donnent James Lewis et Martin Fowler dans leur article de référence publié le 25 mars 2014, en précisant que ces services sont organisés autour des capacités métier et déployables indépendamment grâce à des outils automatisés.
Le terme est récent. D'après le même article, « microservice » a été discuté lors d'un atelier d'architectes logiciels près de Venise en mai 2011, et le groupe a retenu « microservices » comme nom le plus approprié en mai 2012. Les auteurs rapportent qu'Adrian Cockcroft, chez Netflix, décrivait alors l'approche comme une SOA « à grain fin ». Le contraire d'une architecture microservices s'appelle un monolithe : une seule application, une seule base de données, déployée d'un bloc.
Comment fonctionne une architecture microservices ?
Une architecture microservices fonctionne comme une brigade de restaurant plutôt que comme un cuisinier seul. Chaque poste (garde-manger, poissonnier, pâtissier) a son plan de travail et sa chambre froide, et reçoit ses commandes sous forme de bons. Si le poisson prend du retard, les desserts continuent de sortir ; le samedi soir, on ajoute un commis au poste le plus chargé sans toucher aux autres. En contrepartie, il faut quelqu'un pour annoncer les commandes et synchroniser les envois, sans quoi les assiettes d'une même table partent en ordre dispersé.
Transposé au logiciel :
- chaque service gère ses propres données : Lewis et Fowler notent que les microservices préfèrent laisser chaque service gérer sa propre base de données ;
- les services se parlent par API ou par messages ;
- chaque service se déploie seul, ce qui suppose une chaîne de CI/CD automatisée ;
- les services peuvent tourner dans des conteneurs gérés par un orchestrateur comme Kubernetes, que sa documentation définit comme une plateforme open source pour gérer des charges de travail et des services conteneurisés.
Monolithe ou microservices : quelles différences ?
| Monolithe | Microservices | |
|---|---|---|
| Déploiement | Toute l'application d'un bloc | Chaque service séparément |
| Données | Une base commune, cohérente par construction | Une base par service, cohérence à organiser entre services |
| Panne d'un module | Peut bloquer l'ensemble | Peut rester limitée au service touché, si l'architecture le prévoit |
| Montée en charge | On renforce toute l'application | On renforce seulement le service sollicité |
| Exploitation | Un serveur, un journal, une supervision | Réseau, supervision et journaux de chaque service |
| Organisation adaptée | Une équipe | Plusieurs équipes, chacune propriétaire de ses services |
Pourquoi tant de projets en microservices déçoivent-ils ?
Les microservices déçoivent quand on les choisit pour leur image de modernité plutôt que pour un besoin. Martin Fowler l'a formulé dès 2015, dans deux textes courts :
- dans « Microservice Premium » (13 mai 2015), il explique que les microservices introduisent leur propre complexité, une prime qui alourdit le coût et le risque d'un projet et le met souvent en difficulté ;
- dans « Monolith First » (3 juin 2015), il constate que presque toutes les réussites sont parties d'un monolithe devenu trop gros puis découpé, et que presque tous les systèmes construits en microservices dès le départ ont fini en grande difficulté.
Autre idée reçue : découper le code suffit. Lewis et Fowler citent la loi de Conway, énoncée par Melvin Conway en 1968 : une organisation qui conçoit un système en reproduit la structure de communication. Avec une seule petite équipe, dix services reviennent à confier dix postes de brigade au même cuisinier.
Quand les microservices se justifient-ils pour une entreprise ?
Les microservices se justifient quand une partie de l'application a des contraintes très différentes du reste :
- un module subit des pics de charge que le reste ne connaît pas, comme l'import nocturne des catalogues fournisseurs ;
- plusieurs équipes doivent livrer en parallèle sans s'attendre ;
- un traitement doit être isolé pour des raisons de sécurité ou parce qu'il utilise une autre technologie.
Pour un logiciel métier de PME, le point de départ le plus sûr reste une application unique découpée en modules nets (facturation, planning, stock), dont on n'extrait un service que lorsqu'un de ces critères apparaît. Un besoin de traitement parallèle ne suffit pas toujours : le SaaS VISIA, réalisé par YMHB Web, répartit ses analyses sur six processus en parallèle, derrière une application de 26 routes. L'offre est décrite sur la page API et microservices.
Termes voisins
- Middleware : la couche qui transporte les messages entre services, par exemple un courtier de messages.
- Dette technique : un monolithe mal entretenu en accumule, et la découper en services ne la fait pas disparaître.
- Monolithe modulaire : une application unique dont les modules ont des frontières strictes, prête à être découpée plus tard si besoin.
- SOA (architecture orientée services) : une approche plus ancienne. Lewis et Fowler jugent les microservices très proches de ce que défendaient certains partisans de la SOA, un terme qui recouvre toutefois des réalités très diverses.
Questions fréquentes
- Quelle est la différence entre un monolithe et des microservices ?
- Un monolithe est une application unique, avec une base de données commune, déployée d'un seul bloc. Une architecture microservices découpe la même application en services indépendants, chacun avec ses propres données, déployés séparément et reliés par des API. Le monolithe est plus simple à construire et à exploiter ; les microservices permettent de faire évoluer et de renforcer chaque partie séparément, au prix d'une exploitation plus lourde.
- Une PME a-t-elle besoin d'une architecture microservices ?
- Une PME a rarement besoin d'une architecture microservices pour son logiciel métier. Une application unique, bien découpée en modules, se construit, s'héberge et se maintient plus simplement, avec une petite équipe. Martin Fowler observait en 2015 que presque toutes les réussites en microservices partaient d'un monolithe devenu trop gros. Un service séparé se justifie quand une partie a des besoins de charge, de sécurité ou de technologie vraiment différents.
- Qui a inventé le terme microservices ?
- Le terme microservices n'a pas d'inventeur unique. Selon l'article de James Lewis et Martin Fowler publié en mars 2014, le mot « microservice » a été discuté lors d'un atelier d'architectes logiciels près de Venise en mai 2011, et le même groupe a retenu « microservices » comme nom le plus approprié en mai 2012. L'article de Lewis et Fowler a ensuite servi de définition de référence.
- Peut-on passer d'un monolithe à des microservices plus tard ?
- Oui, et c'est la stratégie que décrit Martin Fowler dans son texte « Monolith First » de 2015 : commencer par un monolithe, même si l'on pense avoir besoin de microservices plus tard. Il prévient toutefois qu'on ne peut pas découper n'importe quel système : les passages progressifs réussis dont il a entendu parler partaient d'une conception déjà bien modulaire, aux frontières nettes jusque dans le stockage des données.