Event-driven ; est ce que je suis prêt ? – Compte-rendu du talk de Wassel Alazhar à La Duck Conf 2019

Dans ce talk, Wassel nous propose de nous interroger sur les architectures event-driven en nous posant trois questions :

• Quelle est la promesse des architectures event-driven ?
• Qu'est ce que ca signifie pour nous, quelles sont les implications concrètes pour notre SI ?
• Est-ce que je suis prêt ?

La promesse

Les études qui nous parlent des tendances Tech comme le "Garner Top 10 Strategic tech trends" présentent le real time event-sourcing combiné avec l**'IA et le machine learning** comme une tendance incontournable qu'il sera nécessaire d'adopter dès 2020.

Le speaker nous fait alors remarquer que l'event driven n'a cependant rien de nouveau, dans les années 90 les middleware de messaging s'imposaient déjà dans les architectures de SI et le concept d'événement était déjà utilisé en programmation au moins une décennie plus tôt.

En fait, ce qui à changé ces dernières années, c'est la perspective. L'événement n'est plus simplement un moyen de mettre à jour les états de nos entités stockées en base de données, mais il est désormais devenu le composant principal de notre SI, qui grâce à son traitement en temps réel, nous permet de détecter des opportunités de business plus facilement.

En outre les architectures even-driven sont par nature découplées du fait de l’utilisation d’un broker de messages.

Ce découplage est un atout qui va permettre au système d’évoluer et de s’adapter aux besoins métiers à mesure que sont découvertes de nouvelles utilisations de ces événements.

Les implications concrètes pour notre SI

Les promesses de l’event-driven sont séduisantes, mais me suffit il d’acheter la bonne techno pour que mon SI soit event-driven ?

He bien non ! Avant de vouloir faire du “real time event sourcing” partout dans notre SI essayons d’abord de comprendre ce que ça implique.

Pour cela le speaker nous présente quatre patterns impliquant des événements.

1. La notification par événement

L’introduction d’un broker de message inverse les dépendances traditionnelles, ici la facturation et la livraison observent certains types d’événements sur le broker pour pouvoir commencer leur traitements.

La nature de l’information transmise par l’application vente à changé par rapport à une application traditionnelle.

Ce n’est donc pas parce ce qu’on utilise un broker de message, que l’on est event-driven, la notion d’événement  vient de ce que l’on met dans le message et son sens.

Voir la présentation complète sur slideshare.

2. Le transfert d’état

Les contextes facturation et livraison, dans le cas de la notification par événement, consultent le broker d’événements pour démarrer le traitement. Afin de préserver la nature découplée d’un système basé sur les événements, les contextes facturation et livraison doivent être indépendants du contexte vente.

D’un côté l’événement publié par le contexte vente doit contenir toutes les données liées à ce changement d’état. De l’autre côté chaque contexte doit disposer d’une version propre de l’historique de cet état, ici en l’occurrence l’ordre d’achat.

Une fois que l’on a des services indépendants qui savent communiquer de manière découplée, traiter et émettre des messages de  manière autonome, on est sur la bonne voie pour faire de l’event-driven en 2019.

Le principal challenge souligné ici est d’avoir des services centrées sur une seule problématique et qu’ils soient autonomes pour le faire.

3. Le pattern CQRS

Souvent associé aux architectures event-driven, le pattern Command Query Responsibility Segregation repose sur une séparation entre un modèle d’écriture et un modèle de lecture.

Ces modèles sont optimisés en fonction de leurs besoins respectifs qui sont par nature souvent différents. Par exemple : une mise à jour (écriture) pour des millions de lectures.

Dans ce type de système, on se base sur la notion d’événements pour maintenir la cohérence entre ces deux mondes, celui du modèle d’écriture et celui du modèle de lecture.

4. L’event-sourcing

Le principe fort de l’event sourcing est que l’événement est notre source de vérité, on ne le supprime pas, on ne le met pas à jour.

Dans une architecture event-sourcing on ne fait que sauvegarder les événements dans un event-store qui devient la seule source de vérité.

Si vous faite de l’event sourcing, vous êtes capable de reconstruire l’état de votre système uniquement à partir de l’historique des événements que vous gardez dans votre store.

Après cette série d’exemples qui nous ont permis d’appréhender les différentes utilisations des événements dans nos applications, le speaker nous présente un top 5 des challenges à prévoir dans notre transition vers l’event-driven au sein de notre SI

• Difficile de prédire le comportement global
• Complexité
• Asynchronisme
• Duplications
• Eventual consistency

S’il est possible de répondre plus ou moins facilement à la plupart de ces challenges, il en est toutefois un avec lequel on ne peut pas transiger, et c’est le premier.

Il faut être conscient que le prix à payer pour passer en event-driven, c’est qu’il faut accepter le fait qu’on ne peut pas savoir avec certitude ce qui peut se passer quand un événement a lieu.

En d'autres termes, l'event-driven nous ouvre des perspectives de souplesse et de scalabilité au détriment du contrôle.

Est-ce que je suis prêt ?

Maintenant que l’on a compris que l’on ne peut pas tout contrôler et qu’on l’accepte, est-ce que l’on est prêt pour autant ?

La réponse est simple.

On est prêt, si on arrive à raisonner en terme d’événements et que l’on est capable d’exprimer notre besoin métier avec des événements !

Les technos ne sont pas le problème. Aujourd’hui, on a des technos qui nous permettent de faire beaucoup plus de choses. On dispose de plateformes avec des capacités de streaming temps réel et techniquement cela peut nous rapprocher de cette promesse du SI moderne intelligent.

Néanmoins, si on ne fait pas la transition métier ce qui risque très probablement de se passer c’est que l’on va avoir cette nouvelle plateforme qui devient le point de passage obligé pour tous nos événements mais qu’on n’arrive plus à la maîtriser.

La démarche que le speaker préconise c’est d’aller vers des pratiques qui vont aider à maintenir un alignement constant entre le métier, la tech et le code.

Dans une équipe de développement, pour créer et maintenir un modèle mental aligné, on utilise des pratiques comme le pair programming, le mob programming, les code reviews. L'enjeu dont il est question ici est d'aligner les acteurs techniques ainsi que les acteurs métiers. C'est à dire, les dev, les archi, les PO, enfin tout le monde

La notion de modèle mental partagé est l’un des concepts importants du Domain Driven Design qui regroupe diverses pratiques qui vont dans ce sens, notamment le vocabulaire métier utilisé, la modélisation des concepts métiers et d’autres outils comme l’event storming.

L’event Storming est une série de workshops où il y a des développeurs, des experts métiers et peut être des archis.

Bref, des personnes qui vont avoir des questions et d’autres qui vont avoir une partie des réponses.

Ils vont s’intéresser aux problèmes qu’ils  cherchent à résoudre avec la tech.

En revanche, ils ne parleront pas de techno, ils ne parleront pas de Kafka, au début ils ne parlent même pas d’application.

Ils s’intéressent seulement aux événements qui vont avoir lieu dans le système.

Take Away

L’event-driven n’est pas nouveau mais les nouvelles technos permettent de nouveaux cas d’utilisation.

Mal utilisées, ces mêmes technos peuvent accélerer l’endettement du SI.

Il n’existe pas de solution “silver bullet”.

Voyez grand, commencez simple !

Faites de l’Event Storming !

Lien Youtube