Microservices : expliqué simplement.

Les microservices sont un style d'architecture où une application est découpée en petits services indépendants, chacun responsable d'une capacité métier (facturation, authentification, recherche), chacun avec sa propre base de code, sa propre base de données et son propre pipeline de déploiement, communiquant entre eux via le réseau, en général par API. C'est l'opposé d'un monolithe, où toutes les fonctionnalités vivent dans une seule base de code et sont déployées ensemble comme un bloc unique. Des entreprises comme Netflix ou Amazon ont popularisé cette approche pour permettre à des centaines d'équipes de livrer indépendamment sans se bloquer mutuellement.

L'objectif est autant organisationnel que technique : des bases de code plus petites et ciblées sont plus faciles à posséder, tester et déployer pour une seule équipe, selon son propre rythme, sans attendre que le reste de l'application soit prêt.

Les services se parlent en général via HTTP (REST ou GraphQL) ou via une file de messages asynchrone, de sorte que la panne d'un service n'entraîne pas forcément celle des autres. Un appel REST simple entre deux services peut ressembler à ceci :

// order-service appelle inventory-service
const response = await fetch('https://inventory.internal/api/stock/sku-123');
const { available } = await response.json();

if (!available) {
throw new Error('Rupture de stock');
}

En production, cet appel direct passe souvent par un gateway API qui gère l'authentification, la limitation de débit et la répartition de charge entre les instances d'un service, et chaque service monte en charge indépendamment selon son propre trafic.

• API gateway : un point d'entrée unique qui route les requêtes vers le bon service et centralise l'authentification et la limitation de débit.
• Service discovery : un registre qui permet aux services de se retrouver automatiquement sur le réseau au fil du démarrage et de l'arrêt des instances.
• Communication événementielle : les services publient des événements dans une file (par exemple un événement « commande passée ») au lieu de s'appeler directement, ce qui les découple davantage.
• Une base de données par service : chaque service possède son propre stockage, en évitant une base de données partagée qui recréerait un couplage entre services.

• Ne pas découper en microservices avant que l'équipe et le produit soient assez grands pour en avoir besoin ; un découpage prématuré ajoute de la latence réseau et de la complexité opérationnelle sans bénéfice réel.
• Concevoir chaque service autour d'une capacité métier claire, pas autour d'une couche technique, pour qu'une seule équipe puisse le posséder de bout en bout.
• Investir dans la supervision, le traçage et les logs dès le premier jour, car déboguer une requête qui traverse cinq services est bien plus difficile que déboguer un monolithe.
• Versionner soigneusement les API entre services ; un changement cassant dans un service peut casser silencieusement tous les services qui en dépendent.

Les microservices permettent aux grandes organisations de livrer plus vite en laissant les équipes déployer indépendamment, en ne faisant monter en charge que les parties du système réellement sollicitées, et en choisissant le meilleur outil ou langage pour chaque service plutôt que d'être enfermées dans une seule stack. La contrepartie est une complexité opérationnelle réelle : plus de composants, plus d'appels réseau, et un vrai besoin d'automatisation (CI/CD, conteneurs, orchestration) pour que tout reste fiable. Pour une petite équipe ou un produit en démarrage, un monolithe bien organisé reste en général le point de départ le plus rapide et le moins coûteux.

Nous démarrons la plupart des projets avec un monolithe bien structuré, et n'extrayons des microservices que lorsqu'un vrai goulot d'étranglement, technique ou organisationnel, justifie la complexité supplémentaire, par exemple pour isoler une tâche de fond lourde ou un service qui doit monter en charge indépendamment du reste de l'application. Le développement initial reste ainsi rapide, tout en laissant la porte ouverte à une architecture distribuée à mesure que le produit grandit. Voir notre service web apps pour savoir comment nous concevons ces systèmes back-end.