Monolithe ou microservices : pourquoi ne pas commencer par les microservices

Faut-il construire votre application en plusieurs petits services indépendants, ou en un seul bloc ? Pour un produit qui démarre ou qui est encore petit, le bloc unique, appelé monolithe, est le plus souvent le bon départ. Les microservices répondent à des problèmes que vous n'avez probablement pas encore.

Deux façons d'organiser une application

Un monolithe est une application dont tout le code vit ensemble : comptes, paiements, notifications, tableau de bord. Elle se déploie en une seule fois, comme un seul programme.

Des microservices découpent l'application en plusieurs petits programmes, chacun responsable d'une tâche, qui se parlent par le réseau (souvent par des API). Un service pour les comptes, un pour les paiements, un pour les notifications.

L'analogie : un restaurant et une galerie de stands

Un monolithe, c'est un restaurant avec une seule cuisine : tout le monde se croise, se passe les plats, et si un cuisinier a un souci, il appelle son voisin à voix haute.

Des microservices, c'est une galerie de stands indépendants : chacun a son cuisinier, son matériel, sa caisse. Avantage, un stand peut fermer sans arrêter les autres, et chaque stand peut grandir à son rythme. Inconvénient, il faut organiser les livraisons entre stands, la facturation commune, les horaires, et réparer les mauvaises communications.

Quand vous servez dix couverts, la galerie de stands ne vous aide pas : elle ajoute du travail.

Ce que les microservices coûtent

Découper n'est pas gratuit. On échange des problèmes de code contre des problèmes de coordination :

• Le réseau devient une source de pannes. Un appel entre deux services peut être lent ou échouer, ce qui n'arrive pas quand deux parties du code se parlent dans le même programme.
• Les données se dispersent. Une opération qui touche deux services ne peut plus être validée d'un seul coup : il faut gérer le cas où une moitié réussit et pas l'autre.
• Le déploiement se multiplie. Chaque service a son environnement, sa surveillance, ses mises à jour.
• Comprendre un bug est plus long. Il faut suivre une requête à travers plusieurs services.
• Il faut du monde pour les faire vivre. Les microservices se justifient souvent par l'organisation d'équipes nombreuses qui ne doivent pas se marcher dessus.

Ce qu'un monolithe bien tenu permet

Un monolithe n'est pas un fouillis. Bien organisé, il a des modules clairement séparés (comptes, facturation, notifications) qui ne se mélangent pas.

• On avance vite : un changement touche un seul endroit, un seul déploiement.
• On teste facilement : tout est au même endroit.
• On peut se tromper de découpage et corriger sans douleur, ce qui est précieux quand le produit change chaque semaine.
• Si un jour une partie doit vivre seule, un module bien séparé s'extrait bien plus facilement qu'un nœud de code emmêlé.

Quand les microservices ont du sens

Il existe de vraies raisons de découper, par exemple :

• plusieurs équipes qui travaillent en parallèle et se bloquent mutuellement ;
• une partie précise qui a besoin de monter en charge bien plus que le reste ;
• des contraintes techniques ou de sécurité qui demandent d'isoler un morceau.

Si vous ne pouvez pas nommer une de ces raisons, la complexité n'a pas encore de contrepartie. Mieux vaut avancer en monolithe, garder le code en modules propres, et découper plus tard si un besoin réel apparaît.

Les signaux d'alerte

Si vous reprenez une application déjà découpée, quelques questions utiles :

1. Chaque service a-t-il une vraie raison d'exister seul ?
2. Les services se partagent-ils la même base de données, ce qui annule une partie de l'intérêt ?
3. Faut-il modifier trois services pour changer une seule règle ?

Trois « oui » ou « on ne sait pas » indiquent souvent une complexité qui ne rapporte rien, et qu'on peut simplifier. Pour d'autres signes de code qui freine, voir la dette technique.

À retenir

Commencez par un monolithe organisé en modules, et ne découpez que lorsqu'un besoin précis l'exige. La simplicité du départ n'est pas un défaut de jeunesse : c'est ce qui vous laisse changer de direction vite.

Et pour votre produit ?

Si votre application est déjà découpée en plusieurs services et que chaque changement devient pénible, ou si vous héritez d'un code dont vous ne savez pas s'il faut le regrouper ou le garder tel quel, c'est un cas typique de reprise de projet. Nous pouvons en discuter en 30 minutes, à partir de ce que vous avez sous les yeux.