L'architecture micro services découpe une application en services indépendants, chacun responsable d'une fonctionnalité métier précise. Cette approche offre scalabilité, déploiement indépendant et tolérance aux pannes. Mais elle introduit aussi une complexité distribuée significative. Voici quand et comment l'adopter.
Monolithe vs Micro-services
Un monolithe est une application unique avec tous les composants dans le même processus. Simple à développer initialement, mais difficile à scaler et à maintenir quand il grossit.
Les micro services divisent l'application en services autonomes : service utilisateurs, service commandes, service paiement, service notifications. Chaque micro service a sa propre base de données, son propre déploiement et sa propre équipe.
Ne commencez pas par les micro services : commencez par un monolithe bien structuré, identifiez les limites, puis extrayez progressivement quand la douleur est réelle.
Decomposition par domaine métier
La clé d'une bonne architecture micro services est la décomposition selon le Domain-Driven Design (DDD). Chaque service correspond à un "bounded context" métier clair avec ses propres données.
Plateforme e-commerce :
├── users-service → Auth, profils, adresses
├── catalog-service → Produits, categories, stock
├── orders-service → Commandes, panier
├── payments-service → Paiements, remboursements
├── notifications-service → Emails, SMS, push
└── api-gateway → Routage, auth, rate limiting
Communication entre services
Deux patterns principaux :
Synchrone (REST/GraphQL) : service A appelle directement service B via HTTP. Simple mais crée du couplage temporel (si B est down, A échoue).
Asynchrone (Message Queue) : service A publie un événement dans une queue (RabbitMQ, Kafka, Redis Streams), service B consomme quand il est disponible. Découplé mais plus complexe.
Commande passée → orders-service publie OrderCreated
→ payments-service traite le paiement
→ notifications-service envoie l'email de confirmation
→ catalog-service décrémente le stock
API Gateway
L'API Gateway est le point d'entrée unique de l'architecture micro services. Il gère : le routage vers les services appropriés, l'authentification centralisée, le rate limiting, la transformation des requêtes, et l'agrégation de réponses.
Outils populaires : Kong, Nginx (config manuelle), Traefik, ou AWS API Gateway.
Service Discovery
Dans un environnement dynamique (conteneurs qui démarrent/s'arrêtent), les services doivent se retrouver dynamiquement. Kubernetes gère cela nativement via ses Services et son DNS interne. Pour les autres environnements : Consul ou Eureka.
Défis des micro-services
La complexité distribuée introduit des problèmes nouveaux : latence réseau entre services, transactions distribuées (saga pattern), debugging plus difficile (tracing distribué avec Jaeger/Zipkin), et overhead opérationnel significatif.
Coûts réels : chaque micro service nécessite son propre pipeline CI/CD, son monitoring, ses logs centralisés (ELK Stack). C'est rentable au-delà d'une certaine taille d'équipe et de projet.
La documentation de Martin Fowler sur les micro-services est la référence absolue sur le sujet avec les patterns architecturaux détaillés.
Conclusion
Les micro services résolvent des problèmes réels à grande échelle mais introduisent une complexité distribuée significative. Pour la majorité des projets web de taille modeste à moyenne, un monolithe modulaire bien structuré est plus adapté. Adoptez les micro services quand vos problèmes de scalabilité ou de déploiement indépendant le justifient réellement.
L'architecture micro-services n'est pas une silver bullet : elle convient aux équipes capables de gérer la complexité opérationnelle supplémentaire. Avant de décomposer votre monolithe, assurez-vous d'avoir une observabilité solide : distributed tracing avec Jaeger, centralisation des logs avec l'ELK Stack, et métriques avec Prometheus et Grafana. Le pattern Saga gère les transactions distribuées, et le Circuit Breaker prévient les cascades de pannes entre micro-services. Commencez toujours par un monolithe modulaire bien structuré — il est plus facile à découper qu'à reconstruire. Consultez Microservices.io de Chris Richardson pour les patterns de référence incontournables en architecture distribuée.
Tests dans une architecture distribuée
Tester des micro-services demande une stratégie adaptée : des tests unitaires pour chaque service isolément, des tests de contrat (Pact) pour valider les interfaces entre services, et des tests end-to-end limités pour les scénarios critiques. Évitez les tests d'intégration qui dépendent de nombreux services démarrés simultanément : ils sont lents, fragiles, et difficiles à maintenir dans le temps. La pyramide des tests reste valide dans une architecture distribuée.
