00 - C'est quoi un microservice (et pourquoi tu n'en as peut-etre pas besoin)
Ce que tu vas apprendre
- Ce qu'est réellement un microservice (pas la version marketing)
- Pourquoi un monolithe bien structure suffit dans la majorite des cas
- Quand les microservices deviennent pertinents
Prerequisites
Aucun. C'est le point de depart.
La définition vraie
Un microservice, c'est un processus autonome qui gere une seule capacité métier. Il a sa propre base de donnees, il se deploie indépendamment, et il communique avec les autres services via le réseau (HTTP, gRPC, messages).
C'est tout. Pas besoin de Kubernetes, pas besoin de 47 services, pas besoin d'une équipe DevOps de 8 personnes. Un microservice, c'est un programme qui fait un truc et qui le fait bien, sans partager son état avec les voisins.
Trois regles non negociables :
- Une capacité métier : un service gere les commandes, un autre gere les paiements, un autre gere les notifications. Pas "un service par endpoint".
- Sa propre base de donnees : si deux services partagent une table SQL, c'est pas des microservices. C'est un monolithe distribue (j'y reviens dans l'article sur les erreurs classiques).
- Déploiement independant : tu peux mettre à jour le service de notifications sans toucher au service de paiements. Si tu dois déployer 5 services en meme temps, tu as un problème.
Le hype vs la réalité
Depuis 2014 et les talks de Netflix sur leur migration en microservices, tout le monde veut en faire. Le problème : Netflix avait 1000 ingenieurs et des millions d'utilisateurs avec des pics de charge énormes. Toi, tu as une équipe de 3 personnes et 500 utilisateurs.
J'ai vu une startup de 3 développeurs qui avait decoupe son application en 12 microservices. Résultat : la moitie du temps de dev passait a gerer l'infrastructure. Debug distribue, Docker Compose avec 15 containers, des problèmes de réseau en local, des déploiements qui prenaient 40 minutes. Le produit avancait a peine. Ils ont fini par tout remettre dans un monolithe. En deux semaines, leur vitesse de livraison a triple.
Ce n'est pas une anecdote isolee. C'est le scénario le plus courant.
Pourquoi paltemps.fr est un monolithe
Sur paltemps.fr, l'architecture est simple : un container Bun/Elysia qui sert plusieurs sous-domaines, un reverse proxy Caddy, le tout orchestre avec Docker Compose. Un seul processus, un seul déploiement, un seul endroit ou regarder les logs.
Est-ce qu'on pourrait extraire le scraping RSS dans un service séparé ? Techniquement, oui. Est-ce que ca apporterait quelque chose ? Non. Le scraping tourne dans le meme processus, il accede a la meme base de donnees, et il n'a pas de contrainte de scaling différente du reste. Le séparer ajouterait de la complexité pour zero gain.
Un monolithe bien structure -- avec une séparation claire entre les domaines métier, des modules bien delimites, des interfaces propres -- ca vaut mieux que 10 microservices mal decoupes. Si tu veux comprendre comment bien structurer un monolithe, la serie sur l'architecture hexagonale couvre exactement ca.
Quand les microservices deviennent pertinents
Il y a des situations ou le monolithe atteint ses limites. Ca arrive quand :
- L'équipe dépassé 10-15 développeurs : les conflits de merge deviennent constants, les deployments sont risques parce que tout le monde touche au meme code. Des équipes autonomes sur des services independants resolvent ce problème.
- Les besoins de scaling divergent : ton module de recherche prend 10x plus de CPU que ton module de facturation. Avec un monolithe, tu scales tout pour scaler un morceau.
- Tu as besoin de polyglottisme : ton moteur de recommendation tourne mieux en Python avec TensorFlow, mais le reste de l'app est en TypeScript. Des services separes permettent le bon outil pour le bon job.
- La resilience l'exige : si le module de génération de PDF plante, il ne devrait pas emporter le checkout avec lui.
Si aucun de ces critères ne te parle, reste sur un monolithe. C'est pas un échec, c'est du pragmatisme.
Ce que couvre cette serie
| # | Article | Contenu |
|---|---|---|
| 01 | Monolithe vs micro | Le vrai comparatif honnete |
| 02 | Decouper un monolithe | Bounded contexts, strangler fig |
| 03 | Communication | REST, gRPC, messaging |
| 04 | Infrastructure | Docker, orchestration, observabilité |
| 05 | Erreurs classiques | Les 7 pièges a éviter |
Les exemples s'appuient sur TypeScript et l'ecosysteme Node.js/Bun. Si tu veux plonger dans la communication inter-services, la serie gRPC : communication inter-services est le complement direct.
Résumé
- Un microservice = une capacité métier, sa propre base, un déploiement independant
- La majorite des projets n'ont pas besoin de microservices
- Un monolithe bien structure (comme paltemps.fr) est souvent le meilleur choix
- Les microservices se justifient quand l'équipe grandit, que le scaling diverge, ou que le polyglottisme est nécessaire
Article suivant : 01 - Monolithe vs microservices : le vrai comparatif