Architecture microservices

Objectifs

Définir les caractéristiques d'un microservice et les distinguer d'un service SOA.
Expliquer pourquoi chaque contrainte architecturale existe et ce qui arrive si on la viole.
Appliquer les critères de découpage par domaine.
Choisir entre orchestration et chorégraphie selon le contexte.
Comprendre le pattern Saga et ses implications sur la cohérence.
Identifier les prérequis organisationnels et techniques.

1. Définition et caractéristiques

« Les microservices sont de petits services autonomes qui travaillent ensemble, chacun s'exécutant dans son propre processus et communiquant par des mécanismes légers. » — Sam Newman

Un vrai microservice doit réunir quatre caractéristiques simultanément :

flowchart TB
  MS["Microservice"]
  MS --> C1["Déployable indépendamment"]
  MS --> C2["Propriétaire de ses données"]
  MS --> C3["Organisé autour d'une capacité métier"]
  MS --> C4["Communicant par interface"]

Microservice vs service SOA

Critère	SOA (Service-Oriented Architecture)	Microservices
Taille	Grands services couvrant plusieurs domaines	Petits, focalisés sur une capacité
Communication	Via un ESB (Enterprise Service Bus)	HTTP/gRPC direct ou broker de messages
Base de données	Souvent partagée	Une par service
Déploiement	Coordonné (release train)	Indépendant
Gouvernance	Centralisée	Décentralisée

2. Les contraintes architecturales — pourquoi elles existent

Les microservices ne sont pas une liste de bonnes pratiques arbitraires. Chaque contrainte répond à un problème précisobservé dans les systèmes monolithiques à grande échelle. Comprendre le problème d'origine explique pourquoi la contrainte est non négociable.

2.1 — Déployabilité indépendante

Problème d'origine : le déploiement coordonné coûte trop cher.