Grâce à l’utilisation de composants basés dans le cloud, les micro-services ont pour avantage de présenter une grande souplesse de déploiement. Déployés en tant qu’entités autonomes, ils ont l’avantage d’interagir entre eux, en fonction des besoins de l’entreprise. Afin d’illustrer le propos, prenons l’exemple d’une banque qui offrirait à ses clients, à l’occasion d’un acte d’achat via une application mobile, un crédit promotionnel pour les remercier d’utiliser l’application en question. Il va de soi que cette banque au travers de cette action, est à la recherche de nouvelles opportunités de ventes et de fidélisation clients. Mais pour le client, cela implique plusieurs étapes d’interactions avec sa banque : de l’achat du produit, en passant par la réception du crédit pour un futur achat, jusqu’à l’utilisation de ce crédit pour un autre achat.
Au niveau de l’application, chacune de ces transactions peut facilement être traitée en utilisant la chorégraphie des micro-services. Lorsque cela fonctionne, c’est formidable ! Mais que se passe-t-il en cas d’erreur ? En effet, il est bien souvent difficile de déterminer où se situe l’erreur quand les interventions ne s’inscrivent pas dans un processus global et tous les cas de figure peuvent alors être envisagés : l’erreur se situe-t-elle au niveau de l’interaction de l’achat ? Le système de vente au détail en ligne est-il temporairement indisponible ? L’appel n’arrive-t-il pas à atteindre le fournisseur de services ? Le fournisseur de services a-t-il eu une défaillance ? Votre système n’a-t-il pas reçu le rappel ?
Orchestration : une complexité accrue liée à la démultiplication des services
Avec l’augmentation de la complexité liée à la création régulière de services, les pionniers des micro-services tel que Netflix ont peu à peu découvert les limites de la chorégraphie : "Avec la chorégraphie des tâches de poste à poste, nous avons trouvé qu’il était plus difficile de redimensionner pour suivre l’augmentation des besoins métiers et de la complexité" - Netflix Conductor: A microservices orchestrator, Netflix Technology blog.
Il est donc intéressant de se pencher sur leur expérience et de comprendre quelles sont les difficultés qu’ils ont rencontrées dans leur approche de la chorégraphie. Celles-ci se concentrent apparemment sur deux points :
- Une liaison et des hypothèses étroites autour de l’entrée/sortie, des accords sur les niveaux de services, etc. dans les services individuels qui rendent plus difficile l’adaptation à l’évolution des besoins.
- En l’absence de suivi global, la difficulté de répondre systématiquement à la question : "Où en est-on avec le processus X ?"
Fort de ce constat, Netflix a, contre toute attente, décidé que l’utilisation d’un moteur d’orchestration pour gérer le processus global était une approche plus flexible et donc plus séduisante que la chorégraphie. Leurs développeurs ont ainsi construit une plateforme open source, appelée Conductor, capable de fournir la logique globale pour orchestrer les flux de processus basés sur les micro-services.
Orchestration : à quoi sert un moteur BPM ?
Outre Conductor, il existe également de nouvelles structures d’orchestration comme Cadence, Apache Airflow et Google Cloud Composer, qui aident les développeurs à traiter les interactions entre les micro-services. Et les fans de la chorégraphie bénéficient désormais de nouvelles options avec des structures telles que Istio qui apportent une couche d’infrastructure dédiée, construite directement dans une application pour gérer la communication de service à service.
Mais qu’en est-il d’un moteur BPM ? En tant qu’expert de la gestion des processus, je sais que beaucoup d’acteurs seraient réticents à ce type de solution, décrétant qu’un BPM est d’abord conçu pour gérer les flux les plus importants et les plus complexes, alors que leur démarche vise d’abord à simplifier leur approche micro-services.
Pourtant, aucune règle ne stipule qu’un processus doit être complexe. Car un processus complexe peut être composé de nombreux processus plus petits et plus simples, chacun gérant le workflow d’un micro-service individuel.
Aujourd’hui, la plupart des moteurs BPM prennent en charge la norme BPMN, c’est-à-dire qu’ils utilisent la notation graphique pour définir la logique d’orchestration afin qu’il soit plus facile de comprendre la vue d’ensemble.
Pour illustrer ce point, nous pouvons comparer la logique décrite dans cet exemple de Conductor (un workflow simple qui additionne des vidéos courtes dans une émission Netflix) avec la même logique traitée par un modèle de processus dans un moteur compatible BPMN (dans cet exemple, j’utilise le projet open source Bonita pour créer le schéma) :
Et voici quelques avantages visibles de cette approche :
- Les erreurs peuvent être traitées automatiquement exactement là où elles se produisent en utilisant des chemins d’exception, des timers et d’autres éléments BPMN. Si une intervention humaine est nécessaire, elle peut également être incluse dans la logique.
- Le BPMN permet de définir des règles pour le routage des données et le traitement des données - comme dans la logique d’affectation des tâches aux bons services, aux bonnes personnes, etc.
- Des données sur les cas et l’exécution des processus sont compilées à des fins de création de rapports, de suivi et d’analyse.
Orchestration : à quoi sert un moteur de workflow ?
À présent, je souhaiterais expliquer en quoi un moteur BPM est capable d’offrir bien plus qu’une simple orchestration des micro-services. Il permet l’orchestration - et l’automatisation - de tout service : opérations gérées via des API, intégration dans des systèmes hérités et des systèmes spécialisés exclusifs, intégration dans des ‘monolithes’ tels que SAP et d’autres opérations de plateforme ERP, intégration IdO et autres.
Puis, il y a ces tâches affectées aux personnes que j’ai mentionnées plus haut. La modélisation BPMN est spécialement conçue pour l’orchestration des tâches humaines et des tâches des systèmes d’information automatisées, créant un mélange des éléments sur lesquels les personnes doivent agir dans un processus.
Un nouveau groupe d’acteurs entre maintenant en scène : les robots logiciels. Les tâches mécaniques, répétitives et effectuées par les humains, constituent des candidates idéales pour la délégation au RPA (automatisation des processus robotisés). Heureusement, les moteurs BPM peuvent s’intégrer facilement avec le RPA. Dans le premier exemple relatif à MobileBank, les assistants robots peuvent collecter, extraire et rassembler des informations utiles sur les clients, afin de leur proposer une offre spéciale en temps réel.
