Les microservices sont-ils vraiment la meilleure approche pour la scalabilité d'une appli ?

07 Eki 17:18

Les micro‑services se rapprochent beaucoup du modèle « service‑oriented » d’une plateforme SaaS : chaque composant possède son propre cycle de vie, son propre stockage et peut être redimensionné indépendamment. Cette approche montre tout son intérêt quand le produit possède des sous‑domains clairement séparés (paiement, messagerie, recommandation, etc.) et que le trafic de chaque domaine varie de façon très différente. Par exemple, sur une marketplace, le service de recherche subit des pics massifs pendant les soldes, tandis que le module de facturation reste stable. En découpant ces parties, on peut scaler uniquement le moteur de recherche avec des pods dédiés, sans gonfler inutilement l’ensemble de l’application. En revanche, un monolithe bien structuré, empaqueté dans un conteneur unique et déployé via un pipeline CI/CD fiable, reste très compétitif lorsqu’on a peu de frontières métier, que le volume de trafic est modéré ou que les exigences de latence entre les composants sont critiques. Un bon comparatif est le modèle serverless : il offre une scalabilité granulaire sans que vous ayez à gérer l’infrastructure, mais il impose des limites de temps d’exécution et de taille de paquet. Si votre logique d’affaires est simple et que les appels inter‑services sont fréquents, un monolithe ou une fonction serverless unique sera plus simple à monitorer et à sécuriser. Les critères que j’utilise pour choisir le niveau de granularité sont : 1. **Domaine de responsabilité** : chaque micro‑service doit couvrir un business capability autonome, pas seulement une couche technique. 2. **Variabilité du trafic** : si la charge de certaines fonctions est imprévisible, elles méritent d’être isolées. 3. **Couplage des données** : les services qui partagent la même base de données sans besoin de partition forte sont souvent de bons candidats à rester dans le même module. 4. **Coût de l’opération** : complexité de CI/CD, besoin en observabilité (tracing, logs) et exigences de conformité. 5. **Équipe et culture** : chaque service nécessite une petite équipe capable de le gérer en autonomie. En pratique, je commence souvent par un monolithe modulaire, j’ajoute des points d’extension (API, queues) puis, dès que l’un des modules montre une charge ou une indépendance fonctionnelle suffisante, je le fais migrer vers un micro‑service dédié. Cette évolution incrémentale permet de limiter la dette technique tout en gardant la porte ouverte à la scalabilité granulaire quand le besoin devient réel.