01 - Monolithe vs microservices : le vrai comparatif
Ce que tu vas apprendre
- Les vrais avantages et inconvenients de chaque approche
- Les coûts caches des microservices que personne ne mentionne dans les talks
- Comment choisir en fonction de ton contexte réel
Prerequisites
00 - C'est quoi un microservice
Le comparatif honnete
Oublie les slides de conference ou les microservices gagnent sur tous les critères. Voici la réalité.
| Critère | Monolithe | Microservices |
|---|---|---|
| Déploiement | Un artefact, une commande | Un pipeline par service, coordination nécessaire |
| Debug | Stack trace locale, breakpoint direct | Tracing distribue, correlation d'ID entre logs |
| Consistance des donnees | Transactions ACID natives | Saga pattern, eventual consistency |
| Performance inter-modules | Appel de fonction (nanosecondes) | Appel réseau (millisecondes) |
| Scaling | Tout ou rien | Granulaire par service |
| Autonomie d'équipe | Tout le monde dans le meme code | Chaque équipe possede son service |
| Onboarding | Un seul projet a comprendre | N services, N repos, N schemas |
| Complexite ops | Faible | Elevee (réseau, discovery, monitoring) |
Les avantages réels du monolithe
La simplicité, c'est pas un défaut. Un monolithe, c'est un processus. Un déploiement. Un endroit ou chercher les bugs. Quand ton service de commandes doit lire les donnees utilisateur, c'est un appel de fonction. Pas un appel HTTP qui peut échouer, timeout, retourner un 500, ou prendre 200ms au lieu de 2ms.
Les transactions ACID sont natives. Quand tu créés une commande et que tu decremente le stock, soit les deux passent, soit aucun. En microservices, tu geres ca avec des sagas -- un pattern ou chaque étape a une compensation en cas d'échec. C'est faisable, mais c'est 10x plus de code et de tests.
Le debug est direct. Tu poses un breakpoint, tu lances le debugger, tu vois tout le flow. En microservices, tu cherches dans les logs de 5 services avec un correlation ID en priant pour que le tracing soit bien configure.
Sur paltemps.fr, le monolithe Bun/Elysia gere les feeds RSS, le scraping, l'API, et le frontend. Un seul docker compose up et tout tourne. C'est pas parce que c'est simple que c'est mal fait.
Les avantages réels des microservices
Le scaling granulaire. Ton service de recherche consomme 80% du CPU ? Tu scales ce service a 10 instances pendant que le reste tourne sur une seule. Avec un monolithe, tu deploies 10 copies du tout.
L'autonomie d'équipe. L'équipe "paiements" deploie quand elle veut sans attendre que l'équipe "catalogue" ait fini ses tests. Chaque équipe possede son service, son backlog, son cycle de release. A grande échelle, ca change tout.
La liberte technologique. Le service de ML tourne en Python, l'API publique en Go, le backoffice en TypeScript. Chaque service utilise le bon outil. C'est pas du polyglottisme pour le plaisir -- c'est utile quand certains problèmes se resolvent mieux dans un langage spécifique.
L'isolation des pannes. Le service de génération de PDF plante ? Les utilisateurs peuvent toujours passer commande. En monolithe, si le module PDF fait un out-of-memory, tout le processus tombe.
Les coûts caches
Voici ce que les articles de blog ne disent pas assez fort.
La latence réseau. Un appel de fonction prend des nanosecondes. Un appel gRPC en local prend 1-5ms. Un appel HTTP/JSON prend 5-20ms. Multiplie ca par le nombre d'appels inter-services dans un seul request utilisateur. J'ai vu des architectures ou une page d'accueil declenchait 15 appels inter-services en cascade. Temps de réponse : 2 secondes. Pour la meme chose qu'un monolithe faisait en 50ms.
Le distributed tracing. Sans OpenTelemetry ou Jaeger, tu es aveugle. Et mettre en place du tracing distribue correctement, c'est des jours de travail. J'en parle dans l'article sur l'infrastructure.
L'eventual consistency. "Le stock a ete decremente mais la commande n'a pas ete créée." En monolithe, ca n'arrive pas grace aux transactions. En microservices, c'est ton mardi matin.
La complexité de test. Pour tester un flow complet, tu dois lancer N services. Docker Compose avec 12 containers, 8 Go de RAM en local, et des tests d'intégration qui prennent 10 minutes.
Deux exemples concrets
paltemps.fr : le monolithe qui marche
Une application avec un seul développeur, quelques centaines d'utilisateurs, un besoin de scaling uniforme. Bun/Elysia sert tout. Le code est structure en modules avec des frontieres claires (si tu veux voir comment, la serie sur les domaines et cycles de vie explique la demarche). Un monolithe, c'est le bon choix.
Un e-commerce a 50 développeurs : les microservices justifies
Imagine une plateforme avec : catalogue (10 devs), commandes (8 devs), paiements (5 devs), recherche (7 devs), recommandations ML (5 devs), notifications (3 devs), logistique (7 devs), backoffice (5 devs).
Ici, les microservices font sens. Chaque équipe a son propre cycle de release. La recherche scale a 20 instances pendant le Black Friday. Les recommandations tournent en Python. Le service de notifications peut tomber sans bloquer les commandes. La communication inter-services passe par gRPC pour les appels synchrones et par des messages asynchrones pour le reste.
Mon opinion
Commence par un monolithe. Toujours. Meme si tu penses que tu auras besoin de microservices plus tard.
Un monolithe bien structure avec des modules clairs et des interfaces propres -- ce qu'on appelle parfois un "monolithe modulaire" -- te donne 80% des benefices des microservices sans la complexité operationnelle. Et le jour ou tu as besoin d'extraire un service, les frontieres sont deja la.
Extraire un service d'un monolithe modulaire, c'est un projet de quelques semaines. Fusionner 12 microservices mal decoupes en quelque chose de coherent, c'est un projet de 6 mois.
L'article suivant montre justement comment découper un monolithe quand le moment est venu.
Résumé
- Le monolithe gagne en simplicité, debug, transactions et vitesse de dev
- Les microservices gagnent en scaling, autonomie d'équipe et isolation
- Les coûts caches (latence, tracing, consistency) sont souvent sous-estimes
- Commence par un monolithe modulaire, extrait des services quand la douleur est réelle
Article précédent : 00 - C'est quoi un microservice Article suivant : 02 - Decouper un monolithe : par ou commencer