Pour l’avenir de vos SI, faut-il recruter le génie intemporel de la musique Mozart ou le vertueux de la danse Béjart ?
Vous vous demandez certainement quel le rapport entre ces artistes et nos SI ?
Contextualisons : jadis, nos SI étaient composés d’un seul grand système/application, qualifié de Mono-lead, contenant tous les processus métiers et répondant à tous les besoins et traitements. Au fur et à mesure, ces processus métiers se sont complexifiés et les SLA sont devenus de plus en plus exigeants. Par conséquent, le SI s’est découpé en plusieurs applications indépendantes et hétérogènes.
L’action d’achat d’un t-shirt sur un site e-commerce, nécessite un processus métier qui commence d’abord par un utilisateur qui ajoute le t-shirt au panier, puis le paye. Ce t-shirt est ainsi retiré du stock et livré chez le client.
Nous avons alors évoqué plusieurs applications métiers (gestion de compte client, paiement, livraisons et stock) qui communiquent entre elles pour implémenter ce processus métier.
Un des patterns d’échanges qui ont été implémentés est la SOA, cette approche stipule que les applications doivent communiquer entre elles via des services qui permettent aux autres applications d’accéder à ses ressources ou d’exécuter des processus métier liés à son périmètre. Ce mode d'échange via un service, Request/Reply avec un contrat d’interface bien défini, garantissant un découplage entre les systèmes.
La SOA utilise des micro-services qui traduisent le service via une API CRUD, simple, exposant des ressources, sans aucune intelligence. C’est là que le rôle du chef d’orchestre révèle son importance.
Ce chef doit exposer l’API intelligente qui va permettre de déclencher ce processus métier complexe ; ensuite, l’implémenter en enchaînant les appels des requêtes /réponses vers les différentes APIs exposées par les différents Bounded Contexts.
Au fur et à mesure, les achats de t- shirts vont se multiplier et cet orchestrateur devra répondre à davantage de requêtes, dans un temps limité .
Si une application rate une note, le chef d’orchestre doit reprendre l’erreur sans casser l’harmonie en improvisant des processus métiers pour la traiter.
Ceci dit, le problème est la cohérence de la donnée dans le SI et donc pour cela le pattern de transactions distribuées et les 2 phases commit ont été mis en place.
Pour l’implémenter, les outils les plus fréquents sont les Business Process Managements (BPM), des outils de niche venus avec la promesse de désigner et mettre en production un processus métier via une interface graphique accessible au métier donc sans aucune compétence technique et avec le minimum de maintenance. Mais l’expérience a démontré que ça reste des outils techniques et qu’une expertise est nécessaire. En outre, ces outils ne sont pas adaptés techniquement à la culture devops (TDD, gestion de version, IaC…) et aux approches Agile.
On se retrouve donc avec des API anémiques, un orchestrateur que Sam Newman a qualifié de “service DIEU” parce qu’il est possible d’ajouter des processus métiers au fil de l’évolution. Mais le résultat qui en découle, un orchestrateur FAT et difficilement scalable; Et c’est là que la SOA et l’orchestration atteignent leurs limites.
Les patterns d’échanges continuent à évoluer : avec l’Event Driven Architecture, l’événement est représenté par des messages. Les événements s’échangent dans le SI et la réception d’un événement lance le traitement adéquat, déclenchant ainsi la chorégraphie.
Le processus métier d’achat de t-shirt, par exemple, devient une succession d’évènements dans le SI, qui déclenchent petit à petit un bout du processus dans le bon Bounded Context.
Chaque application est responsable et effectue un traitement à la réception, comme un groupe de danseurs réagissant harmonieusement.
Dans la chorégraphie, le code est éparpillé : on perd la gouvernance sur les applications et, au fur et à mesure que ces dernières se multiplient, on en apprend davantage sur laquelle réagit à tel ou tel évènement. La gestion des erreurs devient de plus en plus compliquée si la livraison échoue : nous ne pouvons pas prévoir la réaction du paiement, ni comment le faire évoluer sans entraîner des régressions.
La reprise d'erreurs est compliquée et devient de plus en plus difficile avec l’augmentation du nombre des services.
Aucun de ces deux génies, Mozart ou Béjart, n’a réussi à résoudre le problème, analysons les deux patterns !
Premier problème, en appliquant les principes du REST et du HTTP, on a donc exposé des APIs anémiques dépourvues de toute intelligence et délégué toute l’intelligence d’une application à l’orchestrateur, le composant transverse censé être technique.
Pour remédier à cela Martin FOWLER a énoncé un principe :
Les APIs n'exposent pas seulement des ressources : une API expose aussi l’intelligence et les processus de son Bounded Context. La gestion des erreurs, le retry et les comportements fonctionnels en cas d’erreurs doivent rester dans le Bounded Context.
Le pipe se limite à une machine à l’état simple qui contient le minimum d’intelligence possible. Il est l’orchestrateur, il se contente de coordonner les applications les unes après les autres et ne contient aucune complexité fonctionnelle. En appliquant ce principe, on peut mettre en place facilement la règle suivante...
La mise en place de ce principe permet celle d'un autre pattern Event sur les frontières workflow à l'intérieur ; l’idée est que les domaines métiers continuent à interagir via des événements. Mais à la réception d’un événement, un Bounded Context doit orchestrer un processus métier : on retrouve donc, à l’intérieur, notre chef d’orchestre qui guide un seul orchestre, joue une seule symphonie et expose un processus métier unique et lié au domaine du Bounded Context.
Pour la cohérence de la donnée dans le SI, SAGA pattern vient à la rescousse. Ce modèle stipule que pour chaque processus métier dans un Bounded Context, il faut prévoir un processus métier de compensation en cas d'erreur. Ce processus est responsable de notifier le client de la non-livraison dans le Bounded Context de gestion de client, de le rembourser dans le Bounded Context paiement et de remettre la base de stock dans le Bounded Context stock.
Pour maîtriser son SI, la solution est de tirer profit des deux patterns :