urbanisation-si.com

Pas de monolithe non plus dans la modélisation !

Image by Gerd Altmann from Pixabay

Il n’est pas question de vouloir reproduire en modélisation ce que l’on souhaite désormais éviter en architecture applicative : le monolithe. Pas de modélisation d’un unique processus généralement long. Préférez à la place la modélisation de plusieurs processus courts, avec une règle très simple à appliquer (quand la décomposition en micro-services a déjà était faite préalablement) :

• • • 1 micro-service <==> 1 pool BPMN

Vous choisirez alors un diagramme BPMN de collaboration qui représentera les échanges entre les pools (micro-services) par des flux de messages.

Orchestration versus chorégraphie

Des micro-services autonomes et suffisamment intelligents pourraient, en communiquant directement entre eux, composer une chorégraphie d’apparence séduisante (bien que sans vision globale du processus). Ce serait sans compter sur la prise en charge des blocages qui pourraient survenir et des reconfigurations de processus métier, qui compliqueraient inévitablement cette chorégraphie.

Pour éviter les complications de la chorégraphie, il convient de privilégier la mise en place d’une orchestration de micro-services. Un processus principal, celui qui gère les interactions avec le Client (front-office) et nommé l’Orchestrateur, va commander les processus secondaires (micro-services en back-office), via des flux de messages adéquats. On comprend tout de suite que la reconfiguration d’un processus métier sera plus simple : seul l’ordre d’appel aux micro-services par l’Orchestrateur sera alors modifié ; aucun impact sur les micro-services eux-mêmes.

BPMN est souvent utilisé pour modéliser des processus métier relativement longs, mais les durées d’exécutions des tâches automatisées confiées à des micro-services peuvent être extrêmement courtes (mesurées en millisecondes). Cela ne pose pas de problème particulier : seule l’échelle du temps (non formalisée en BPMN) sera différente, plusieurs jours, mois, voire années, à l’échelle du processus métier en entier, contre quelques millisecondes à l’échelle de certaines tâches, celles exécutées par les micro-services.

Communications synchrones versus asynchrones

Les messages figurant sur un diagramme de collaboration peuvent représenter aussi bien des communications synchrones (protocole REST notamment) que des communications asynchrones (MQ par exemple). Ils semblent, par contre, peu adaptés pour représenter le data streaming (Kafka notamment). Mais l’éditeur Confluent notamment propose, sur sa plate-forme, l’API REST Proxy pour accéder au data streaming de Kafka.

Ce n’est pas l’objet principal de cet article, mais rappelons que les communications asynchrones entre les micro-services sont conseillées, afin de limiter le couplage et favoriser la mise à l’échelle d’une architecture micro-services.

La principale caractéristique du protocole de communication synchrone est d’attendre systématiquement un accusé de réception (bonne ou mauvaise). Mais il faut attendre cet accusé avant de continuer : cette attente peut durer longtemps dans certains cas (lors d’un pic de charge notamment) et bloquer la communication ; elle constitue l’exemple parfait d’un couplage fort. Le diagramme de collaboration simple ci-dessus représente des communications synchrones avec les micro-services.

Il existe toutefois des solutions, comme les modèles Circuit Breaker (disjoncteur) et Bulkheads (cloisons), pour limiter l’impact de ce couplage fort (pour aller plus loin, lire cet article de Rhona : https://www.urbanisation-si.com/solutions-sur-etagere-pour-la-gestion-des-defaillances-des-micro-services).

Par contre, avec un protocole de communication asynchrone, cet accusé de réception sera envoyé plus tard (lors d’une prochaine session de communication). L’attente de cet accusé ne sera donc pas bloquante. On imagine ici la difficulté de représentation dans un diagramme BPMN… Cet accusé est toutefois optionnel : on peut considérer par exemple qu’il n’y aura jamais de problème à déposer un objet métier dans une file d’attente, qui absorbera sans difficulté un pic de charge, et se dispenser alors de demander un accusé de réception, toujours bonne. Dans ce cas, le couplage n’en sera qu’encore plus faible. Mais l’accusé de réception n’est pas le résultat de l’appel au micro-service, qu’il faudra bien attendre.

BPMN pas seulement pour la modélisation !

Chaque micro-service n’est pas seulement représenté par un pool dans un diagramme de collaboration. Outre le fait que chaque micro-service doit disposer de son propre magasin de données (Data Store), conformément à l’un des principes fondateurs de l’Architecture Micro-Services, on peut encore améliorer son autonomie en lui donnant son propre moteur d’exécution (un moteur différent par micro-service, donc). C’est désormais possible avec des moteurs poids légers, comme le Camunda Workflow Engine.

Thierry Biard