Êtes-vous prêt à passer à l’event-driven architecture ?

L’architecture microservices améliore grandement la gestion d’une application pour les équipes qui en ont la responsabilité dans l’entreprise. L’event-driven architecture (EDA) représente, quant à elle, un gain de robustesse ​​​pour le​ système d’information. Beaucoup d’entre vous peuvent envisager la migration vers une EDA, pour autant, tous n’en tireront pas un réel bénéfice. Pour distinguer l’envie du besoin et savoir si vous êtes prêt à passer à l’event-driven architecture, ​mieux vaut ​être guidé et conseillé. Retrouvez dans notre article l​es spécificités de l’EDA​ indispensables à connaître. 

Qu’est-ce qu’une architecture event-driven ? 

L’event-driven architecture (EDA) est une architecture orientée événements : ils sont au cœur de son fonctionnement. Ici, il faut comprendre « événement » comme ce qui résulte d’un changement d’état quelconque dans une application et qui est généré — habituellement — par les utilisateurs de celle-ci, l’équipe gestionnaire, ou l’application elle-même, en interne.  

La particularité de cette architecture est qu’elle est basée sur un système de communication asynchrone qui permet, entre autres, un couplage faible. Ainsi, des messages (des événements) peuvent être envoyés simultanément sans que réponse ou traitement immédiat soient nécessaires. Cette asynchronicité, renforcée par le principe du « Fire and Forget » (en français, tire et oublie) — qui établit que, quelle que soit sa nature et son volume, l’événement est envoyé et l’on ne s’en soucie plus — permet à l’événement de ne jamais être bloqué dans son traitement. À l’inverse, une communication synchrone nécessite une réponse directe et instantanée à chaque requête lancée.  

Le message queuing (file d’attente des messages) constitue également un élément crucial dans le fonctionnement de l’event-driven architecture. En effet, cette brique logicielle permet la communication entre les microservices en plaçant chaque événement dans une file d’attente. Les événements en attente seront alors découpés pour faciliter leur traitement.  

Le producer (producteur/expéditeur) crée un événement qu’il envoie. Celui-ci est directement intégré à une file d’attente, puis distribué à chacun des microservices abonnés à la file d’attente (​s’​ils sont abonnés, ils sont donc intéressés par le traitement de ce type d’événement). Ces abonnés sont dits « consumers » (consommateurs). C’est ensuite le broker (un agent de messages médiateur) qui gère la file d’attente et la distribution des messages, rendant ainsi possibles ces fluidité et asynchronicité ​spécifiques​​ à l’EDA.  

Kafka et RabbitMQ sont les brokers les plus connus dans le domaine, le premier grâce à ses performances démontrées et sa robustesse, le second pour sa simplicité d’utilisation. 

Pour une utilisation optimale de l’event-driven architecture, il existe un ensemble de design pattern​s​ qui garantissent son bon fonctionnement. En voici quelques-uns : 

• CQRS (Command and Query Responsibility Segregation). L’implémentation de ce design pattern permet de séparer les requêtes de lecture de celles d’écriture. Ainsi, le stockage des données s’opère sur deux bases de données différentes afin d’optimiser les performances de l’application, mais également de logguer chaque action (tout événement du système est loggué) pour pouvoir les rejouer au besoin. 
  

• Event Sourcing : chaque nouvel événement est stocké sur la base, ce qui permet une compilation de l’ensemble des événements. Par exemple, dans le cadre d’une application bancaire, si un utilisateur réalise un virement, une nouvelle entrée est ajoutée dans la base de données ; c’est un virement, l’entrée correspond donc à une opération de soustraction (-200 €). Grâce à l’Event Sourcing, une « compilation » entre le solde actuel et le virement permet de ne perdre aucune information. Toute la séquence d’événements menant au solde actuel est enregistrée, et tous les événements peuvent être rejoués. Évidemment, cela implique une problématique de stockage importante : la base de données utilisée pouvant vite être saturée.

• Event Notification correspondant au principe du « Fire and Forget ». L’expéditeur envoie son message sans rien attendre en retour.

L’architecture orientée événements répond aujourd’hui à des besoins grandissants d’échanges, par les applications, de gros volumes de données. L’implémentation — complexe — de cette architecture peut nécessiter un accompagnement expert auprès des entreprises qui en manifestent le souhait. 

Comment le broker facilite-t-il le fonctionnement de l’event-driven architecture ? 

La mise en place de l’event-driven architecture exige l’utilisation d’un broker. Pour que l’entreprise bénéficie de toute l’efficacité de ce système, celle-ci doit absolument : 

• maîtriser toutes les fonctionnalités du broker ;
• s’assurer que le broker fait partie intégrante de la mise en place de l’EDA et qu’il permet de gérer les files d’attente pour faciliter la transmission des événements.

Dans le process, le broker reçoit l’événement de la part du producer et le transmet dans l’exchange. Avec un logiciel comme RabbitMQ, celui-ci peut prendre plusieurs formes : 

• Direct : le message est envoyé dans la file d’attente via des clés d’association pour être transmis au consumer ;
• Topic : le message est traité par le routing pattern afin qu’il soit envoyé dans les files d’attente qui répondent à certaines conditions ;
• Fanout : le message va être envoyé dans toutes les files d’attente.

Selon le broker choisi, vous pourrez paramétrer la durée de rétention des messages (une heure, plusieurs années, à l’infini, etc.) grâce à l’outil d’administration du broker, l’intérêt étant de pouvoir rejouer les événements pendant le temps préalablement configuré.  

L’objectif d’un broker est de faciliter les échanges d’événements et d’éviter les blocages entre les microservices. Car non seulement les microservices ont besoin d’une diffusion rapide, mais ​celle-ci s’applique à​​​ de très gros volumes de données (des millions). Les process permis par les brokers mènent à un niveau de performance et de robustesse élevé. 

Quels sont les inconvénients de l’event-driven architecture ? 

L’implémentation d’une architecture telle que l’event-driven architecture n’est pas anodine et des obstacles à sa bonne utilisation peuvent rendre la tâche peu plaisante aux entreprises choisissant ce modèle.  

Il est donc, avant toute chose, indispensable de connaître précisément le public visé par l’application et les besoins que leurs comportements induisent. Sans cela, la complexité que représente le passage à l’EDA ne justifie pas la migration. Ce sont ensuite les moyens en matière d’infrastructure qui doivent être évalués : le passage à l’event-driven architecture est-il supportable techniquement ? 

Le broker est par ailleurs un élément déterminant dans la bonne prise en charge de l’EDA. Qu’il s’agisse de Kafka, de RabbitMQ ou d’une autre solution, les équipes en charge devront maîtriser ce système de gestion de file d’attente. 

Puis, le volume de données conservées — dont nous avons déjà fait mention — doit être pris en considération et évalué : le stockage sur le cloud représente un coût non négligeable, mais difficilement négociable avec une EDA. En effet, les événements sauvegardés peuvent occuper une place conséquente. Or, comme ces événements sont susceptibles d’être rejoués à des fins d’analyse et de debug, ils doivent être gardés.  

Enfin, le découplage de l’événement opéré par le broker dans la file d’attente apporte malgré tout de la complexité. Même s’il améliore et accélère la communication asynchrone, il rend le débogage et la maintenance plus difficiles. 

Ce sont tous ces enjeux auxquels devra faire face l’entreprise lors de sa réflexion sur l’event-driven architecture. 

Que peut apporter l’event-driven architecture à votre entreprise ?

Les entreprises ont aujourd’hui un besoin croissant d’architecture comme l’EDA, car la plupart d’entre elles ont une activité qui nécessite de gérer de plus en plus de données en un temps de plus en plus réduit. L’EDA répond à ce besoin (si les obstacles listés précédemment peuvent être adressés). 

Le recours à l’event-driven architecture apporte de l’évolutivité aux applications et améliore la résilience des entreprises. En effet, celles-ci peuvent elles-mêmes effectuer le débogage de leur application ou même anticiper une situation qui se dégrade. Elles peuvent rapidement circonscrire une erreur au seul microservice concerné et ainsi garder la disponibilité et la réactivité de leur application intactes (seul le microservice souffrant devient indisponible). Cette capacité de résilience leur confère une véritable autonomie. 

L’event-driven architecture améliore également la robustesse de l’entreprise, car elle peut alors traiter beaucoup plus de requêtes simultanément, ce qui signifie de plus gros volumes d’informations. Avec l’event-driven architecture, le temps de réponse est plus faible et, grâce au message queuing, votre entreprise ne perd aucune donnée. 

​​Vous vous sentez prêt à passer à l’event-driven architecture ? Chez ​Alter Solutions​, vous trouverez le conseil et l’accompagnement nécessaires à la réussite de vos projets de transformation numérique. ​Notre cabinet de conseil propose des audits dans le but d’améliorer la robustesse et la résilience des systèmes sans jamais perdre de vue la nécessaire identification des facteurs techniques, des besoins de compétences et la maîtrise des coûts. 

Par ailleurs, ​​n​ous possédons la certification PASSI, gage de confiance en matière d’audits de sécurité. Décernée par l’ANSSI (Agence nationale de la sécurité des systèmes d’information), cette qualification nous permet d’accompagner sereinement nos clients face aux enjeux de cybersécurité. Les vulnérabilités sont des menaces permanentes dans le fonctionnement normal d’une entreprise. ​La complémentarité de nos expertises vous permet​ de garder une balance « complexité-coût-bénéfice » équilibrée.

​Vous bénéficiez d’un accompagnement sans faille pour une implémentation​ et une gestion​ optimale​s​.