Orchestration des processus et chorégraphie dans les micro-services

Lorsque vous envisagez une architecture logicielle, vous avez probablement rencontré et expérimenté des micro-services dans l'orchestration de processus qui est devenue la méthode par défaut pour construire des applications.

Le style architectural des micro-services se concentre sur le développement d'applications singulières qui fonctionnent comme une suite de "micro-services", chacun exécutant ses propres processus et communiquant avec des mécanismes tels qu'une API de ressources HTTP. Les applications sont conçues pour être déployées indépendamment et conçues autour de capacités commerciales avec une exécution automatisée. La gestion centralisée est une composante, mais elle n'est nécessaire que de façon minimale.

Lorsqu'on parle de micro-services, il est utile de les comparer au style monolithique de développement d'applications où il y a une interface utilisateur côté client, une base de données et une application côté serveur. Du côté serveur, l'application gère les requêtes HTTP, déploie la logique de domaine, reçoit et met à jour les informations de la base de données, puis sélectionne et affiche les vues HTML par le biais du navigateur. En tant que monolithe, il s'agit d'un exécutable unique. Si des modifications sont nécessaires, une nouvelle version de l'application côté serveur doit être construite.

Le style monolithique a été l'approche "traditionnelle" du développement d'applications. L'application traite les demandes via un processus unique et utilise des fonctionnalités de base pour diviser l'application en classes, fonctions et espaces de noms. Si vous souhaitez exécuter plusieurs instances, vous pouvez faire évoluer le monolithe horizontalement derrière un équilibreur de charge.

Si le style monolithique du développement d'applications peut être une source de succès, il peut également constituer un obstacle au déploiement d'un grand nombre d'applications sur le cloud. Par exemple, comme les cycles de changement sont liés entre eux, toute modification d'application nécessite une reconstruction et un redéploiement complets. Avec le temps, le maintien d'une structure modulaire organisée devient beaucoup plus complexe et prend beaucoup plus de temps. Si votre organisation voulait faire évoluer les applications métier, vous devriez faire évoluer chaque application, une par une, au lieu de vous contenter d'un seul composant qui nécessite plus de ressources.

Du monolithe au microservice

La popularité des micro-services est due en partie aux frustrations associées au style monolithique. Sans oublier que le style des micro-services garantit que les services sont indépendamment évolutifs et déployables avec la possibilité d'écrire différents services dans différentes langues. Il peut également être géré par différentes équipes. Les racines du style de microservice remontent aux principes de conception d'Unix, et sont beaucoup plus efficaces à l'ère du cloud.

La propriété du produit tout au long de son cycle de vie

Dans le style monolithique, une fois qu'une application est développée, elle est considérée comme terminée. L'étape suivante consiste à en transférer la propriété à l'équipe de maintenance. En revanche, le style micro-service englobe la propriété à vie de l'équipe de projet qui l'a développée. Pensez au mantra d'Amazon qui dit : "tu le construis, tu le diriges". Ainsi, l'équipe de développement gère au quotidien le comportement de son application et s'occupe de certaines tâches de support. L'idée est qu'il existe une relation continue avec l'application afin de s'assurer qu'elle fournit constamment les capacités commerciales prévues.

En fait, les équipes de micro-services hésitent souvent à appliquer des normes strictes. Bien que cela puisse également dépendre de la manière dont les normes sont fixées et appliquées. Par exemple, dans le monde de l'entreprise, les normes sont souvent élaborées par des équipes ayant peu ou pas d'expérience en programmation. Une façon de voir les choses est d'utiliser le concept de "Domain-Driven Design of Bounded Context". La DDD compartimente un domaine complexe en de multiples contextes délimités avec une carte reliant les relations. Le processus DDD est bénéfique dans les architectures monolithiques et de micro-services car il aide à clarifier et à renforcer les séparations. Cependant, les micro-services décentralisent les décisions relatives au stockage des données, chaque service pouvant gérer sa propre base de données même s'il existe des instances différentes. Cette approche est appelée "Polyglot Persistence". Chaque service a une fonction spécifique et utilise un moyen d'interaction et de partage des données. Comment ? Soit par l'orchestration ou la chorégraphie.

Qu'est-ce que l'orchestration des processus ?

Tout comme un orchestre dépend du "chef d'orchestre" ou de l'"orchestrateur", une interaction de microservice utilise l'"orchestration de processus" pour gérer toutes les interactions en attente d'une réponse avant de demander le service suivant. L'orchestration suit un paradigme demande/réponse. L'orchestration présente plusieurs avantages :

• Facile à gérer grâce à la centralisation des processus d'entreprise
• Le flux des demandes est coordonné efficacement grâce à un traitement synchrone 

Quelles sont les limites ? Eh bien, l'orchestration crée aussi une sorte de dépendance puisqu'elle couple les services. Si le service A connaît un échec, le service B ne sera pas appelé. De plus, si l'orchestrateur tombe en panne, tout le traitement s'arrête et la visibilité est perdue.

Qu'est-ce que la chorégraphie ?

Si votre objectif est d'éviter les dépendances et de permettre à chaque service de travailler indépendamment, alors la chorégraphie serait la méthode optimale. Avec cette approche, les services n'ont pas besoin d'attendre des instructions - ils agissent de manière indépendante. En adoptant l'approche asynchrone, les services savent quoi et comment réagir aux événements. Voici quelques avantages : 

• Traitement rapide puisque les services n'attendent pas un orchestrateur. 
• Il est facile d'ajouter des services ou de faire des mises à jour à partir du flux d'événements. 
• Supprime tous les points d'échec.
• S'aligne sur un modèle de livraison agile où les équipes peuvent se concentrer sur des services spécifiques plutôt que sur l'application entière. 

La chorégraphie semble être le choix logique pour une infrastructure de micro-services, mais elle présente certaines limites, notamment le fait que les processus sont étalés, ce qui rend plus difficile la gestion de l'ensemble du processus. En conséquence, la complexité est un problème retentissant. 

Si vous voulez comprendre la chorégraphie par rapport à l'orchestration, il peut être utile de les comparer d'abord à des exemples réels. Par exemple, pensez à acheter une barre de chocolat dans un distributeur automatique. Un flux de travail de base comprendrait les éléments suivants :

1. Mettez de l'argent dans la machine
2. Sélectionnez votre article
3. Le cabinet émet les bonbons
4. Retrouvez votre friandise
5. Prendre tout changement (si disponible)

On peut décomposer cela en trois éléments distincts :

1. Paiement
2. Passer votre commande 
3. Expédition des articles 

Maintenant, imaginons les aspects d'un orchestre de garage - il n'y aurait pas de chef d'orchestre. Avec le distributeur automatique, chaque événement déclenche une autre action prête à être exécutée. Lorsque vous insérez votre argent, il active la machine pour permettre une sélection d'options de collation. Une fois que vous avez appuyé sur le bouton de votre choix, le décaissement commence. Chaque élément fonctionne uniquement en fonction de l'événement qui s'est produit précédemment.

Contrairement à un orchestre de garage, un chef d'orchestre est nécessaire lorsqu'il s'agit d'un orchestre. Chaque note jouée, et la façon dont elle est jouée, sont guidées par le chef d'orchestre. Pour cette illustration, on peut parler d'orchestration avec un chef d'orchestre ou un responsable de processus qui enchaîne chaque événement. Le chef d'orchestre est donc conscient de l'ensemble du déroulement des opérations. Comme le chef d'orchestre sait tout, cette personne peut également proposer des mises à jour de statut - la musique se déroule toujours au bon moment. 

Comme dans l'exemple d'un groupe de garage, beaucoup de membres improvisent ; ils travaillent de manière indépendante et ne savent pas ce qui va se passer ensuite. Donc, si vous êtes une entreprise qui a besoin de mises à jour continues, l'orchestration fait l'affaire. En revanche, si votre organisation change continuellement, alors la chorégraphie serait plus logique. Cependant, elles ne doivent pas nécessairement s'exclure mutuellement, car elles peuvent travailler ensemble sur divers aspects de différents flux de travail.

Orchestration de processus vs. chorégraphie : Quels sont leurs deux modes d'interaction ? 

Lorsqu'un flux de travail suit un schéma d'orchestration de processus, il y a toujours un lien point à point entre les événements - il serait difficile de supprimer les événements requis car chaque lien est noté. En revanche, l'approche chorégraphique signifie que les événements ne se "parlent" pas entre eux, mais agissent plutôt de manière autonome. L'orchestration exige un contrôle actif, alors que la chorégraphie ne le fait pas.

Lorsque vous en arrivez à gérer des centaines ou des milliers de processus, il devient écrasant de "chorégraphier". À grande échelle, l'orchestration permet de contrôler plus facilement tous les processus en même temps. En outre, les interactions humaines peuvent être insérées facilement et rapidement.

Imaginez une équipe de danseurs se produisant lors d'un événement. Ils connaissent déjà leur chorégraphie, ils peuvent donc danser sans que personne ne leur dise où aller, quand se tourner ou quand se baigner. Ils font les bons pas et ne manquent pas un temps. Le spectacle est asynchrone : lorsqu'ils sont sur scène devant leur public, ils n'attendent plus le chorégraphe. La chorégraphie est le choix logique lorsque les tâches ne nécessitent pas des réponses et des demandes synchrones.

Alors, comparez l'équipe de danse aux processus. Même si un événement échoue, toutes les autres actions peuvent continuer à se dérouler comme prévu. Si un danseur rate un saut dans le même contexte, les autres danseurs peuvent continuer la représentation comme si elle n'avait jamais eu lieu. Par conséquent, il y a beaucoup moins de flux et d'agitation. Chaque tâche est connectée mais agit également de manière indépendante, ce qui permet de gagner du temps et de réduire les besoins en travail manuel. Les processus s'exécutent plus rapidement car ils ont déjà été programmés et ne nécessitent pas de gestion active. Les performances sont éprouvées et fiables. En substance, l'orchestration fonctionne mieux dans un un contexte limité où la chorégraphie fonctionne mieux entre des contextes délimités.

Comme les services peuvent tomber en panne à tout moment, il est essentiel de mettre en place des procédures permettant de déterminer rapidement les défaillances et d'automatiser le rétablissement des services. La surveillance des applications en temps réel, ainsi que la suivi sémantique pour recevoir des alertes d'alerte rapide en cas de problème. En outre, il est beaucoup plus important dans une architecture de micro-services puisque le micro-service favorise implicitement l'approche chorégraphique.

Dansons : Chorégraphie ou orchestration ?

Notre réponse est les deux. L'utilisation d'un hybride de blocs de processus synchrones et asynchrones - orchestration et chorégraphie combinées - signifie que le flux est distribué et protégé contre un seul point de défaillance. Les services peuvent être découplés, dans une certaine mesure. L'association de l'orchestration et de la chorégraphie vous permet d'obtenir des résultats optimisés et d'adapter chaque approche aux besoins de votre architecture.

Vous voulez en savoir plus sur la manière dont une approche équilibrée peut fonctionner pour votre organisation ? Contactez Processmaker dès aujourd'hui pour déterminer comment intégrer dynamiquement vos processus afin d'atteindre rapidement vos objectifs commerciaux.