Orchestration ou chorégraphie

4 min —

En ce moment je travaille sur un projet en Event Driven Architecture (EDA) ; je caricature, mais grosso modo ça veut dire qu’on a plein de microservices qui se parlent entre eux de manière asynchrone via des topics Kafka. J’ai eu à implémenter une mécanique qui annule une action à travers tout le système. Chez nous c’est la chorégraphie qui prime entre tous ces services, et l’implémentation s’est révélée au final assez complexe ; je me suis dit qu’en orchestration ça aurait été beaucoup plus facile, et donc je me suis posé pour remettre sur papier le pour et le contre de chacune.

Une commande traverse cinq services : paiement, stock, facturation, expédition, notification. Le code de chacun est simple. Ce qui est difficile, c’est de répondre à ça : qui décide de la suite ?

Il y a deux réponses. Soit personne en particulier, chaque service écoute ce qui vient de se passer et en tire ses propres conclusions. Soit quelqu’un, un composant dont le seul métier est de connaître le process et de dire à chacun ce qu’il a à faire.

La première s’appelle la chorégraphie, la seconde l’orchestration.

Deux façons de faire avancer un process

En chorégraphie, chaque service publie un fait accompli, PaiementAccepté, StockRéservé, et les autres s’y abonnent. Personne ne connaît le process complet ; chacun connaît sa part. Le process existe bel et bien, mais il n’est écrit nulle part : il est la somme des abonnements.

En orchestration, un composant gère le process. Il déclenche le paiement, attend, déclenche la réservation du stock, attend, et décide de la suite selon la réponse. Les participants ne se connaissent pas entre eux ; c’est l’orchestrateur qui les connaît.

Chorégraphie Orchestration 1 2 3 4 chacun réagit à l'événement du précédent personne ne connaît le tout orchestrateur 1 2 3 4 un composant appelle chacun à son tour le process est écrit à un seul endroit
Fig. 1 — Le même process, deux formes. À gauche une chaîne décentralisée, à droite un composant qui la gère entièrement.

Ce ne sont pas de nouveaux concepts. La saga, une transaction longue découpée en étapes compensables, est décrite par Garcia-Molina et Salem en 1987 déjà, pour un problème de verrous en base de données, bien avant qu’on parle de microservices. L’orchestrateur, lui, porte un nom depuis 2003 : Hohpe et Woolf l’appellent Process Manager dans Enterprise Integration Patterns (une lecture importante pour toute personne travaillant sur des systèmes distribués).

Le catalogue EIP propose d’ailleurs un troisième terme qu’on oublie systématiquement : le Routing Slip, où la séquence des étapes voyage avec le message lui-même. Ni orchestrateur, ni abonnements : un itinéraire agrafé à la commande. Mais ça, personnellement, je ne l’ai jamais rencontré en production.

Ce que chacune coûte vraiment

Ce qu’on regardeChorégraphieOrchestration
Ajouter une étapeun abonnement de plus, sans toucher aux autresmodifier l’orchestrateur
Lire le processnulle part, il faut le reconstituerun seul fichier
Débugger un cas préciscorréler les traces de N servicesune instance, un état
Panne du coordinateuril n’y en a pastout s’arrête
Compenser un échecchaque service doit savoir défaire et prévenirpiloté depuis le centre
Ce qui grossit avec le tempsles cascades d’événementsl’orchestrateur lui-même

Le vrai coût de la chorégraphie n’est pas dans ce tableau, il est dans une phrase que Martin Fowler a écrite dès 2006 à propos de l’Event Collaboration : le flux de comportement devient implicite. Le système fait quelque chose que personne n’a écrit. Ça marche très bien jusqu’au jour où il faut expliquer pourquoi.

Le vrai coût de l’orchestration, lui, est plus simple : quelqu’un doit maintenir le chef d’orchestre, et il a tendance à absorber de la logique métier qui n’est pas la sienne.

Chorégraphie Orchestration 1 2 3 ✕ le retour arrière remonte la chaîne chacun doit savoir défaire et qui prévenir orchestrateur 1 2 3 ✕ le retour arrière part d'un seul endroit les services n'ont qu'à savoir défaire
Fig. 2 — L'étape 4 échoue. C'est au moment de défaire que le choix se paie, dans un sens comme dans l'autre.

Le malentendu sur le couplage

On présente presque toujours la chorégraphie comme « découplée » et l’orchestration comme « couplée ». C’est un mauvais raccourci.

En chorégraphie, le couplage est bien présent : il se déplace. Il quitte le code, où on le voyait, pour aller vivre dans les schémas d’événements et dans la carte des abonnements, c’est-à-dire dans un endroit que personne ne relit.

Et il ne va pas dans le sens qu’on croit : un service qui publie doit savoir ce qu’on attend de son événement, sans quoi il ne peut plus jamais le faire évoluer. C’est l’argument que défend Bernd Rücker dans « Why service collaboration needs choreography AND orchestration », et sa conclusion est vraiment intéressante :

Chorégraphie à l’échelle du système, orchestration à l’échelle de chaque service. Ce n’est pas un choix global.

Dans le même esprit, Software Architecture: The Hard Parts refuse de traiter la coordination seule : elle est liée à deux autres forces, le mode de communication (synchrone ou asynchrone) et le niveau de cohérence exigé.

On ne choisit pas l’une des trois sans déplacer les deux autres, exactement la logique des compromis dont je parlais dans Comprendre PACELC.

Comment choisir

Comme toujours, il n’y a pas de meilleure solution : c’est une histoire de compromis. La vraie question est celle-ci : est-ce qu’il y a un process, ou juste des conséquences ?

Quatre questions pour vous aider à trancher.

  • Est-ce que quelqu’un vous demandera un jour « où en est la commande 4712 ? » Si oui, il vous faut un endroit capable de répondre. C’est un orchestrateur, même si vous l’appelez autrement.
  • Y a-t-il un retour arrière à piloter quand ça casse au milieu ? Une compensation ordonnée se pilote mal en chorégraphie : chaque service doit connaître le chemin inverse, et ce chemin n’est écrit nulle part.
  • Les réactions sont-elles facultatives et indépendantes les unes des autres ? Envoyer un mail, alimenter un cache, incrémenter un compteur : rien de tout ça n’a besoin d’un chef d’orchestre. La chorégraphie est faite pour ça.
  • La liste des réactions va-t-elle grandir sans que le process, lui, change ? C’est le cas favorable à la chorégraphie : on ajoute un abonné, on ne touche à rien.

En pratique, la ligne de partage se dessine assez bien : la chorégraphie pour les conséquences, l’orchestration pour les transactions.

En résumé

Il n’y a pas de camp. Il y a un process, ou il n’y en a pas.

Si vous pouvez le nommer, s’il a un début, une fin, et quelqu’un pour vous demander où il en est, écrivez-le quelque part. C’est ce qu’est un orchestrateur : le process rendu lisible.

Si vous ne pouvez pas le nommer, si ce ne sont que des conséquences qui se déclenchent chacune de leur côté, ne fabriquez pas un chef d’orchestre pour quelque chose qui n’a pas de partition.

Le vrai piège n’est ni l’un ni l’autre : c’est de choisir par défaut. La chorégraphie est le choix par défaut de beaucoup d’équipes, parce qu’elle ne demande aucune décision : on branche un abonnement de plus et ça part. Jusqu’au jour où plus personne ne sait ce qui se passe quand un paiement échoue.

Sources