Modèles de chorégraphie ou d’orchestration

Lorsque des microservices doivent collaborer pour mener à bien un processus métier, il existe deux modèles fondamentaux de coordination. L'Orchestration utilise un coordinateur central (tel que Step Functions) qui donne explicitement des instructions à chaque service. La Choreography ne possède aucun coordinateur central : les services écoutent les événements et y réagissent indépendamment. Comprendre lequel utiliser et quand les combiner est une compétence d'architecture essentielle évaluée à l'examen SAA-C03.

Dans l'orchestration, un service central (l'orchestrator) contrôle la séquence des opérations. Il appelle le service A, attend la réponse, puis appelle le service B, et ainsi de suite. L'orchestrator dispose d'une visibilité complète sur l'état du processus, gère les erreurs et les nouvelles tentatives, et peut prendre des décisions en fonction des résultats intermédiaires. Sur AWS, Step Functions est l'orchestrator de référence : il définit l'ensemble du flux de travail sous forme de machine à états et pilote chaque étape.

Dans la chorégraphie, les services communiquent par l'intermédiaire d'événements sans coordinateur central. Le service A termine sa tâche et publie un événement (par exemple, OrderValidated) sur un bus d'événements ou une rubrique. Le service B écoute les événements OrderValidated et traite le paiement, puis publie PaymentCharged. Le service C écoute PaymentCharged et expédie la commande. Chaque service est autonome et découplé : il ne connaît que les événements qu'il consomme et produit, et non les autres services.

Sur AWS, Step Functions est l'outil principal d'orchestration. Pour la chorégraphie, les principaux outils sont Amazon EventBridge (pour acheminer les événements entre les services avec un filtrage basé sur le contenu), Amazon SNS (pour une diffusion simple) et Amazon SQS (pour la transmission de messages de point à point entre les services). Vous pouvez combiner les modèles : utilisez EventBridge pour la chorégraphie entre domaines et contextes délimités, et Step Functions pour orchestrer les étapes au sein d'un même domaine.

L'orchestration fournit une visibilité centralisée : l'historique d'exécution de Step Functions indique précisément où se trouve un flux de travail, combien de temps chaque étape a pris et ce qui a échoué. Le débogage est simple. La chorégraphie répartit la visibilité entre plusieurs services et bus d'événements : le suivi d'une seule transaction métier nécessite de corréler les journaux et les événements de nombreux services. C'est pourquoi les systèmes fondés sur la chorégraphie s'appuient fortement sur les ID de corrélation et le suivi distribué (AWS X-Ray) pour obtenir une visibilité de bout en bout.

La chorégraphie offre un couplage plus faible : l'ajout d'un nouveau service qui écoute des événements existants ne nécessite aucune modification des services existants. Par exemple, l'ajout d'un service d'analyse qui écoute les événements OrderPlaced n'a aucun impact sur le service de commande ou de paiement. L'orchestration introduit un couplage plus étroit entre l'orchestrator et tous les services qu'il appelle : l'ajout d'une nouvelle étape nécessite de modifier la définition de la machine à états, même si les services individuels restent isolés.

L'orchestration rend la gestion des erreurs explicite : les blocs Catch de Step Functions définissent des états de secours pour chaque type d'erreur, et l'historique complet du flux de travail affiche le contexte de l'échec. Dans la chorégraphie, la gestion des erreurs est répartie : chaque service doit gérer ses propres échecs et peut éventuellement publier un événement d'échec auquel les autres services peuvent réagir. La mise en œuvre de sagas (transactions compensatoires qui annulent le travail effectué lorsqu'une étape échoue) est beaucoup plus complexe avec la chorégraphie qu'avec l'orchestration.

Privilégiez l'orchestration lorsque : le processus métier suit une séquence linéaire ou conditionnelle claire, avec des résultats explicites de réussite ou d'échec ; vous avez besoin d'une visibilité centralisée sur l'état du processus pour l'exploitation ou la conformité ; la gestion des erreurs implique une logique de compensation complexe ; ou le flux de travail est de longue durée et doit survivre aux redémarrages des services. Exemples : traitement des commandes, intégration de patients, traitement des demandes d'indemnisation, autant de flux de travail avec des exigences claires de début, de fin et d'audit.

Privilégiez la chorégraphie lorsque : les services appartiennent à des équipes différentes qui ne doivent pas être étroitement coordonnées ; le système doit pouvoir être étendu par de nouveaux services sans modifier les services existants ; les événements représentent des faits plutôt que des commandes (par exemple, « OrderShipped » et non « ShipOrder ») ; ou vous recherchez une évolutivité maximale, puisqu'il n'existe aucun goulot d'étranglement central. Exemples : ingestion de données analytiques, diffusion de notifications, journalisation d'audit, autant de situations où plusieurs consommateurs indépendants réagissent au même événement.

La plupart des architectures AWS du monde réel utilisent les deux modèles à différents niveaux de granularité. Un modèle hybride courant consiste à utiliser la chorégraphie EventBridge pour découpler les contextes délimités (par exemple, le domaine Order émet des événements, tandis que les domaines Inventory, Payment et Shipping répondent chacun indépendamment), puis, au sein du domaine Payment, à utiliser l’orchestration Step Functions pour coordonner les étapes du processus de paiement interne (débit, vérification de fraude, autorisation, règlement). Vous obtenez ainsi un couplage réduit entre les domaines et une vue claire des processus internes.

Lors de l’examen, recherchez ces signaux. Mots-clés de la chorégraphie : 'loosely coupled', 'services react to events', 'teams own independent services', 'fan-out to multiple consumers', 'add new service without changing existing ones'. Mots-clés de l’orchestration : 'coordinate steps in sequence', 'track workflow state', 'handle partial failures with compensation', 'human approval step', 'long-running process with error handling'. Une question décrivant un coordinateur central qui dirige d’autres services relève toujours de l’orchestration.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’orchestration utilise un coordinateur central (Step Functions) pour contrôler explicitement et visiblement le flux de travail, que la chorégraphie utilise des événements (EventBridge) pour assurer un couplage réduit et favoriser l’extensibilité, et que la plupart des architectures de production combinent les deux modèles à différents niveaux de granularité. Nous allons maintenant étudier le format de l’examen SAA-C03 et la stratégie de pondération des domaines.