Orchestration versus Chorégraphie

Un petit article autour des Micro Services, sur lequel un point important et qui montre à quel point ce type d’architecture differt de ce que nous faisons habituellement: la "Chorégraphie".

Habituellement (ce n'est pas obligé, mais c'est très souvent le cas), nos programmes font ce que nous appelons du "Service Orchestration".

C'est une entité business (en l’occurrence, l'orchestrateur) qui va se charger de coordonner toutes les interactions entre nos différences services. L'orchestrateur va devoir alors invoquer tous les services nécessaires, les combinés si besoin, et procéder à l'ensemble des opérations.

L'avantage: c'est centralisé et la gestion de la transaction est plus aisé.

L'inconvénient majeur: l'évolutivité est plus restreinte et du coup le scaling est difficile à adapter (nous pourrions imaginer que nous faisons deux actions: l'une coûteuse en mémoire, l'autre non). De plus, cela ne favorise pas la parallélisme des actions.

Ce qui nous amène au "Service Choreography". Ce dernier, se reposant plus sur une approche "Event Driven Architecture" va permettre de complêtement découplé nos services, en passant par des appels de messages (souvent passés dans une "bus message tunnel".

La chorégraphie décrit les interactions entre les différents services.

Du coup, nous avons en avantage:

• Un découplage fort
• Un parallèlisme
• Une scalabilité découplée
• Une possibilité accrue d'étendre le workflow (en rajoutant un service qui va écouter les bons messages)

L'inconvénient majeur à mes yeux est la gestion des transactions. Mais à cela, il existe des pattern d'architecture de micro services qui permettent de répondre à ce problème.