En quoi le BPM est-il source de flexibilité dans les architectures micro-services ?
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 de 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 […..]
Source:: En quoi le BPM est-il source de flexibilité dans les architectures micro-services ?
