Architecture de microservices : définition, fonctionnement et limites

Une architecture de microservices découpe une application en plusieurs petits services indépendants, chacun chargé d’une fonction métier précise (catalogue, paiement, facturation…), avec son propre code, ses propres données et son propre déploiement. Les services communiquent entre eux par des API ou des messages. Ce style permet de faire évoluer et de déployer chaque partie séparément, au prix d’une complexité technique et organisationnelle nettement plus forte qu’une application monolithique.

On reprend ici la définition de référence, le fonctionnement concret, la différence avec une API, les avantages et les inconvénients réels, puis la question que se pose tout dirigeant ou chef de projet : est-ce adapté à mon application ?

• Que sont les microservices ?
• Comment fonctionne une architecture de microservices ?
• Quelle différence entre microservices et API ?
• Quelles idées reçues faut-il oublier ?
• Quels sont les avantages des microservices ?
• Quels sont les inconvénients ?
• Microservices ou monolithe : que choisir ?
• Questions fréquentes
• Sources

Que sont les microservices ?

La définition la plus citée vient de l’article publié en mars 2014 par James Lewis et Martin Fowler. En substance : le style d’architecture microservices est une façon de développer une application unique sous la forme d’un ensemble de petits services, chacun tournant dans son propre processus et communiquant par des mécanismes légers, souvent une API HTTP. Ces services sont construits autour des capacités métier et déployables indépendamment grâce à un déploiement entièrement automatisé. Leur gestion centralisée est réduite au strict minimum, et ils peuvent être écrits dans des langages différents et utiliser des technologies de stockage différentes.

Chris Richardson, auteur du site de référence microservices.io, résume les propriétés attendues d’un tel découpage. Les services sont :

• faiblement couplés : modifier l’un ne doit pas obliger à modifier les autres en même temps ;
• déployables indépendamment : chaque service peut être mis en production seul ;
• organisés autour de domaines métier (un service « commandes », un service « stock ») plutôt qu’autour de couches techniques ;
• détenus par une petite équipe responsable de bout en bout, du code à la production ;
• faciles à maintenir et à tester, parce que chacun reste de taille raisonnable.

L’objectif affiché est de livrer des changements rapidement, fréquemment et de façon fiable sur une application volumineuse et complexe, avec plusieurs équipes qui avancent en parallèle sans se marcher dessus.

Comment fonctionne une architecture de microservices ?

Prenons une boutique en ligne. Dans une architecture monolithique, le catalogue, le panier, le paiement, la gestion des comptes et les expéditions vivent dans une seule application, avec une seule base de données, déployée d’un bloc. En microservices, chacune de ces fonctions devient un service à part :

Pour que l’ensemble fonctionne, plusieurs briques reviennent presque toujours :

• Une passerelle d’API (API gateway) : point d’entrée unique pour le site, l’application mobile ou les partenaires. Elle redirige chaque requête vers le bon service, ou en interroge plusieurs pour composer une réponse.
• Une base de données par service : chaque service garde ses données privées et ne les expose que via son API. Aucun service ne va lire directement la base d’un autre.
• Une communication synchrone ou asynchrone : appels HTTP (REST, gRPC) quand une réponse immédiate est nécessaire, messages et événements (file de messages, bus d’événements) quand un service doit simplement prévenir les autres qu’il s’est passé quelque chose, par exemple « commande payée ».
• Des transactions distribuées : comme une commande touche plusieurs bases, on remplace la transaction unique par une suite de transactions locales coordonnées (le modèle « saga »), avec des actions de compensation en cas d’échec.
• Des conteneurs et un orchestrateur : chaque service est généralement empaqueté dans un conteneur et piloté par une plateforme comme Kubernetes, qui gère le déploiement, la montée en charge et le redémarrage.
• De l’observabilité : journaux centralisés, métriques et traçage des requêtes d’un service à l’autre, sans quoi diagnostiquer une panne devient très difficile.

Un microservice n’a donc pas de raison d’exister seul : il fait partie d’un écosystème de services qui, ensemble, rendent le service de l’application. Tout l’enjeu est de bien choisir les frontières entre eux, pour que la plupart des opérations restent locales à un service.

Quelle différence entre microservices et API ?

Les deux notions sont souvent confondues parce qu’elles vont ensemble, mais elles ne sont pas du même ordre :

• Un microservice est une façon de découper et d’organiser une application : c’est un choix d’architecture.
• Une API (Application Programming Interface) est une interface : un contrat qui décrit comment un logiciel peut demander des données ou déclencher une action auprès d’un autre.

Chaque microservice expose en général une API, et c’est par elle que les autres services (ou la passerelle) l’utilisent. Mais une API existe aussi très bien sans microservices : un site WordPress monolithique expose une API REST, un logiciel de facturation propose une API pour récupérer les factures. Pour aller plus loin sur ce sujet, notre article Qu’est-ce qu’une API reprend les bases.

Quelles idées reçues faut-il oublier ?

« Micro » veut dire minuscule. Faux. Le préfixe ne décrit pas le nombre de lignes de code mais le périmètre : un service couvre un domaine métier cohérent. Il peut être simple (envoi d’e-mails) ou très complexe (moteur de paiement, calcul de tarifs).

Les microservices sont un protocole ou une technologie. Faux. C’est un style d’architecture. Il s’appuie sur des technologies existantes : HTTP et REST, gRPC, files de messages (AMQP avec RabbitMQ, par exemple), bus d’événements comme Kafka.

Plus il y a de services, mieux c’est. Faux. Un découpage trop fin multiplie les appels réseau, les pannes possibles et les transactions distribuées. On parle alors de « monolithe distribué » : tous les inconvénients des microservices sans leurs avantages, parce que les services doivent quand même être modifiés et déployés ensemble.

Les microservices rendent une application plus rapide. Pas en soi. Chaque appel entre services passe par le réseau, ce qui ajoute de la latence. Le gain porte sur la capacité à faire monter en charge une partie précise et sur la vitesse de livraison des équipes, pas sur la vitesse brute.

Quels sont les avantages des microservices ?

• Déploiement indépendant : corriger le module de paiement ne demande pas de redéployer tout le site. Les mises en production deviennent plus petites et plus fréquentes.
• Autonomie des équipes : chaque équipe développe, teste et livre son service sans attendre les autres.
• Montée en charge ciblée : on ajoute des instances du seul service sollicité (le catalogue pendant les soldes) au lieu de dupliquer toute l’application.
• Liberté technologique : un service peut utiliser un autre langage ou une autre base de données si son besoin le justifie, et être mis à jour à son rythme.
• Isolation des pannes : bien conçue, l’architecture permet à une partie du site de continuer à fonctionner quand un service tombe (on peut encore parcourir le catalogue si le service de recommandations est en panne).
• Code plus lisible : un service de taille raisonnable est plus facile à comprendre pour un nouveau développeur qu’un monolithe de plusieurs centaines de milliers de lignes.

Quels sont les inconvénients ?

L’architecture de microservices n’est pas une solution miracle. Martin Fowler parle d’une « prime » à payer (microservice premium) : un surcoût de complexité qui ne se justifie que pour des systèmes suffisamment complexes. Les principaux inconvénients :

• Complexité du système distribué : certaines opérations traversent plusieurs services, ce qui les rend plus difficiles à comprendre, à déboguer et parfois moins efficaces.
• Cohérence des données : sans base commune, il faut gérer des transactions distribuées et accepter une cohérence « à terme » (les données se synchronisent avec un léger décalage).
• Dépendances à l’exécution : si un service appelle trois autres services de façon synchrone, sa disponibilité dépend de la leur.
• Coût d’infrastructure et d’exploitation : conteneurs, orchestrateur, supervision, pipelines de déploiement par service. Il faut une vraie culture DevOps et des compétences dédiées.
• Tests de bout en bout plus lourds : vérifier qu’une commande passe correctement demande de faire tourner plusieurs services ensemble.
• Organisation : le modèle suppose plusieurs équipes autonomes. Avec deux ou trois développeurs, la répartition des services n’apporte pas grand-chose.

Microservices ou monolithe : que choisir ?

Le point de départ raisonnable reste l’architecture monolithique, qui convient à beaucoup d’applications. Martin Fowler l’a formulé dès 2015 dans son billet « Monolith First » : presque toutes les réussites en microservices qu’il a observées ont commencé par un monolithe devenu trop gros puis découpé, et presque tous les systèmes construits en microservices dès le départ ont connu de sérieuses difficultés.

Le « monolithe modulaire » est souvent le meilleur compromis : une seule application, un seul déploiement, mais un code découpé en modules métier aux frontières nettes. Si un module doit un jour être extrait en service indépendant, le travail est déjà à moitié fait.

Les questions à se poser avant de se lancer : combien d’équipes vont travailler sur l’application ? Certaines parties ont-elles des besoins de charge ou des rythmes de livraison très différents ? Avez-vous les compétences pour exploiter une plateforme de conteneurs ? Si la réponse est non à ces trois questions, un monolithe bien conçu vous fera gagner du temps et de l’argent.

Beaucoup de PME n’ont d’ailleurs pas besoin de réécrire leur application : elles ont besoin de faire communiquer des outils existants (CRM, ERP, boutique, facturation). C’est l’objet de notre service d’intégration d’API et d’automatisation. Et si vous avez un projet d’application métier, on peut vous aider à choisir l’architecture adaptée dans le cadre de nos applications web sur mesure.

Questions fréquentes

Quelle est la définition simple d’un microservice ?

Un microservice est un petit programme autonome qui s’occupe d’une seule fonction métier d’une application, avec ses propres données, et qui communique avec les autres par des API ou des messages.

Les microservices utilisent-ils forcément Docker et Kubernetes ?

Non, ce n’est pas une obligation, mais c’est le cas le plus courant. Les conteneurs simplifient le déploiement de nombreux services, et un orchestrateur comme Kubernetes automatise leur gestion.

Combien de microservices faut-il ?

Il n’y a pas de bon nombre. Le découpage suit les domaines métier et l’organisation des équipes. Mieux vaut peu de services aux frontières claires que beaucoup de services qui dépendent tous les uns des autres.

Peut-on passer d’un monolithe à des microservices ?

Oui, et c’est le chemin le plus sûr. On extrait progressivement une fonction à la fois (souvent celle qui pose un problème de charge ou d’évolution), en laissant le reste du monolithe en place.

Quelle différence avec une architecture SOA ?

L’architecture orientée services (SOA) découpait déjà les systèmes en services, mais s’appuyait souvent sur un bus d’entreprise central chargé de beaucoup de logique. Les microservices privilégient au contraire des services autonomes et des canaux de communication simples : l’intelligence est dans les services, pas dans le tuyau.

Sources

• James Lewis et Martin Fowler : Microservices, a definition of this new architectural term (mars 2014)
• Martin Fowler : Monolith First (juin 2015)
• Martin Fowler : Microservice Premium (mai 2015)
• Chris Richardson, microservices.io : Microservice architecture pattern
• microservices.io : API gateway pattern
• microservices.io : Database per service
• Documentation Kubernetes : présentation