Qu’est-ce que l’architecture orientée événements ?

L’EDA permet aux équipes d’identifier les événements du système (essentiellement, tout changement ou toute action qui se produit dans le système), d’y répondre et de réagir en temps réel (ou quasi réel).

La profusion des EDA dans les environnements cloud natifs illustre une transition majeure depuis les architectures informatiques traditionnelles (qui se concentrent sur le stockage de données statiques dans des référentiels tels que des data lakes) vers une approche dynamique qui suit les données à mesure qu’elles traversent une architecture. Les données restent précieuses dans un système orienté événements, mais les EDA mettent l’accent sur la réaction rapide aux événements, car la valeur de ces derniers est susceptible de diminuer au fil du temps.

Dans une architecture orientée événements, les producteurs d’événements (comme les microservices, les API et les appareils IdO) envoient des notifications d’événements en temps réel aux consommateurs d’événements qui activent ensuite des routines de traitement spécifiques. Par exemple, lorsque Netflix publie une nouvelle série originale, plusieurs services EDA attendent la notification de publication, ce qui déclenche une cascade de mises à jour pour informer les utilisateurs.

L’un des principaux avantages d’une architecture orientée événements est la relation découplée entre les composants front-end et back-end, ce qui permet aux systèmes de partager des informations sans se connaître. Les producteurs peuvent envoyer des événements sans savoir quel consommateur les recevra, et les consommateurs peuvent recevoir des événements sans envoyer de demandes aux producteurs. En d’autres termes, les EDA permettent aux systèmes de fonctionner indépendamment et de traiter les événements de manière asynchrone.

L’encombrement numérique des entreprises modernes et visionnaires est vaste, et la fonctionnalité en temps réel d’un système orienté événements leur permet d’assurer leur préparation opérationnelle sans activité et de réagir rapidement aux événements diffusés. Ainsi, les EDA aident les entreprises à automatiser toute une série de processus organisationnels, de l’optimisation de la chaîne d’approvisionnement à l’identification proactive des problèmes de qualité, et, en fin de compte, à améliorer leurs résultats financiers.

La transmission d’événements en continu s’articule autour du flux sans limites, séquentiel et en temps réel d’enregistrements de données, appelés « événements », des structures de données fondamentales qui enregistrent toute occurrence ou tout changement dans le système ou l’environnement. Il peut s’agir par exemple d’un utilisateur qui ajoute un article à son panier sur un site de commerce électronique, qui demande à réinitialiser son mot de passe ou d’une modification de l’état d’une application. Il s’agit d’un terme qui fait référence essentiellement à chaque point de données du système, tandis qu’un « flux » ((également appelé flux de données ou données en streaming) désigne la distribution continue de ces événements.

Chaque événement comprend généralement une clé qui identifie l’événement ou l’entité à laquelle il se rapporte, une valeur qui contient les données réelles de l’événement, un horodatage qui indique le moment où l’événement s’est produit ou a été enregistré, et parfois des métadonnées sur la source de l’événement, la version du schéma ou un autre attribut. Elles peuvent soit contenir des données d’état (l’article acheté, son prix et une adresse de livraison, par exemple), soit servir d’identifiants (notification d’expédition).

Des moteurs de traitement de flux spécialisés permettent de soumettre les événements à différents processus au sein d'un flux. Les « agrégations » effectuent des calculs sur les données, comme les moyennes, les sommes et l'écart type. L'ingestion consiste à ajouter des données en flux aux bases de données. Le traitement analytique identifie des tendances dans les données en flux pour prédire les événements futurs, et le traitement d'enrichissement associe les points de données à d'autres sources de données pour fournir du contexte et créer du sens.

Les événements sont souvent liés aux opérations métier ou aux parcours utilisateurs et déclenchent généralement une autre action, un autre processus ou une série d'événements. Prenons l’exemple de la banque en ligne. Lorsqu’un utilisateur clique sur « transférer » pour envoyer de l'argent d'un compte bancaire à un autre, le transfert de fonds est effectué, des notifications par e-mail ou SMS sont envoyées à l'expéditeur et au destinataire, et si nécessaire, des protocoles de sécurité et de prévention des fraudes sont déployés.

Outre les événements, les EDA s’appuient sur trois principaux composants pour déplacer les données d’événements dans l’architecture.

• Producteurs d’événements (ou éditeurs) : les producteurs désignent les sources d’événements, qui génèrent des événements et les envoient au reste du système. Un producteur peut être une interface utilisateur, un capteur, un service ou tout autre système capable de détecter ou de produire un changement d’état intéressant d’autres parties du système. Bien que les producteurs soient responsables de la création d’événements, ils ne disposent d’aucune fonctionnalité de traitement des événements.

• Consommateurs d’événements (ou abonnés) : les consommateurs gèrent les tâches de traitement des événements dans un EDA. Ils écoutent les canaux événementiels et réagissent lorsqu’un événement qui les intéresse est publié. La réaction peut prendre de nombreuses formes : mise à jour d’une base de données, déclenchement d’un processus en aval ou simplement enregistrement d’informations, entre autres.

• Routeurs d’événements (ou orchestrateurs d’événements) : les routeurs, ou orchestrateurs, sont les courtiers qui dissocient les producteurs d’événements front-end des consommateurs d’événements back-end ; ils servent de conduits par lesquels les événements sont distribués, assurant leur transmission sans nécessiter de connexion directe entre les entités. Les routeurs peuvent être basés sur des composants conventionnels (middleware orienté message, comme un SaaS, par exemple) et être utiles dans une série de systèmes de messagerie (files d’attente de messages, modèles de publication/abonnement, flux d’événements, et plus encore).

Dans un EDA, les applications orientées événements agissent en tant que producteurs ou consommateurs (et parfois les deux).

Lorsqu’un service ou une application effectue une action susceptible d’intéresser une autre application ou un autre service, il publie un nouvel événement (un enregistrement de cette action ou de ce changement) qu’un autre service peut utiliser et traiter pour effectuer d’autres actions.

Le producteur de l’événement transmet ensuite l’événement, sous la forme d’un message, à un courtier ou à un autre type de routeur d’événements, qui conserve l’ordre chronologique de l’événement par rapport aux autres événements. Un consommateur d’événements ingère le message en temps réel (à mesure qu’il se produit) ou dans une instance pertinente ultérieure et traite le message pour déclencher une autre action, un autre workflow ou un autre événement qui lui est propre.

Prenons un exemple simple : un service bancaire transmet un événement « dépôt », qu’un autre service bancaire consomme et auquel il répond en effectuant un dépôt sur le relevé du client.

Les intégrations orientées événements peuvent également déclencher des réponses en temps réel basées sur des analyses complexes d’énormes volumes de données, par exemple lorsqu’un client clique sur un produit sur un site de commerce électronique et que le système génère des recommandations instantanées de produits basées sur les achats d’autres clients.

L’architecture orientée événements maximise le potentiel des applications cloud natives et permet d’exploiter des technologies d’applications puissantes, comme l’analytique en temps réel et l’aide à la prise de décision. Dans l’ensemble, elles remplacent l’architecture traditionnelle de « demande/réponse », où une application doit demander des informations spécifiques à une autre et attendre une réponse avant de passer à la tâche suivante.

Cependant, « EDA » est un terme qui comprend plusieurs modèles d’architecture, qui peuvent tous être utiles à des fins différentes :

Dans le modèle pub/sub, défini par une dépendance « un à plusieurs » entre les objets et une relation asynchrone découplée entre l’éditeur (producteur d’événements) et le consommateur, l’éditeur n’a pas besoin de connaître les abonnés. Il publie simplement l’événement sur un canal d’événement partagé où les abonnés écoutent et réagissent à l’événement de manière indépendante, en temps réel.

En règle générale, un courtier de messages (routeur) gère la transmission des messages d’événements entre les éditeurs et les abonnés. Le courtier reçoit chaque message d’événement, le transforme (si nécessaire), conserve son ordre par rapport aux autres messages, le met à la disposition des abonnés pour qu’ils l’utilisent, puis le supprime une fois qu’il a été consommé (pour prévenir une nouvelle consommation).

Les modèles de messagerie publication/abonnement sont idéaux pour les entreprises disposant de grandes bases de code, mais aussi pour diffuser des informations à plusieurs consommateurs (pour les systèmes de notification et les flux de données en temps réel, par exemple).

Tout comme le modèle pub/sub, la transmission d’événements en continu dissocie les éditeurs et les consommateurs pour permettre une communication asynchrone. Cependant, dans le modèle de transmission d’événements en continu, les consommateurs d’événements n’ont pas besoin de s’abonner aux flux ; au lieu de recevoir et de consommer des flux d’événements dans un journal de courtage, les consommateurs peuvent accéder à chaque flux à tout moment et consommer uniquement les événements qu’ils souhaitent consommer (au lieu de recevoir et de consommer chaque événement publié).

Contrairement au modèle pub/sub, les courtiers en transmission d’événements en continu conservent les événements même après réception par les consommateurs.

Les consommateurs pouvant traiter les événements à tout moment après leur publication, les enregistrements de transmission d’événements en continu sont persistants. Cela signifie qu’ils sont conservés pendant une durée configurable (de quelques fractions de seconde à une durée indéterminée). Les consommateurs peuvent accéder au flux à tout moment pour lire les messages récents, traiter par lots une série de messages à partir de leur dernier accès au flux ou faire référence à des messages pertinents du passé récent.

Les technologies de transmission d’événements en continu (comme Apache Kafka, Amazon Web Services (AWS) Kinesis et IBM Event Automation) comprennent également deux modèles : le modèle « pull » (où les courtiers envoient uniquement les données des consommateurs lorsque les consommateurs indiquent qu’ils sont ouverts aux événements) et le modèle « push » (où la logique métier du courtier dicte quels consommateurs reçoivent les événements).

Les modèles de transmission d’événements en continu sont les plus utiles pour les applications qui ont besoin de mises à jour d’événements en temps réel et d’un accès aux événements passés (comme par exemple les systèmes de détection des fraudes pour les institutions financières).

Outre les deux principaux modèles architecturaux EDA, trois modèles de conception régissent la façon dont les événements sont traités une fois qu’ils atteignent l’abonné.

• Traitement simple des événements : les consommateurs traitent les événements exactement comme ils sont reçus des éditeurs, ce qui déclenche une action immédiate.

• Traitement de flux d’événements (ESP) : où les plateformes de diffusion en continu de données ingèrent des événements et construisent un pipeline pour les processeurs de flux, qui traitent et transforment ensuite le flux.
  
  
• Traitement des événements complexes (CEP) : processus qui permet aux consommateurs de traiter une série d’événements pour identifier les tendances et les modèles dans les données.

Les trois modèles de traitement (entre autres) peuvent être utilisés dans les modèles architecturaux de publication/abonnement et de transmission d’événements en continu, mais l’ESP est (naturellement) le plus courant dans le modèle architectural de transmission d’événements en continu.

Les EDA peuvent s’avérer utiles pour les entreprises opérant dans une multitude de secteurs, mais elles sont particulièrement intéressantes pour les entreprises disposant de vastes environnements informatiques complexes.

Les entreprises qui tentent d’intégrer des systèmes fonctionnant dans différentes piles technologiques, par exemple, peuvent utiliser les fonctionnalités de découplage des architectures orientées événements pour conserver l’indépendance vis-à-vis des systèmes de données d’événements et améliorer l’interopérabilité. Les multinationales peuvent utiliser une EDA pour coordonner les systèmes entre les comptes et les régions, facilitant ainsi la mise à l’échelle indépendante des différentes parties de l’architecture. Et pour les entreprises qui exécutent des systèmes qui traitent différentes parties d’un événement, les fonctionnalités de déploiement des EDA peuvent transmettre les événements à chaque consommateur, sans avoir besoin d’un nouveau code, pour un traitement parallèle sur l’ensemble du système.

Dans le domaine du commerce électronique, une architecture orientée événements peut filtrer et acheminer les événements en temps réel pour s’assurer qu’ils ne parviennent qu’aux abonnés intéressés par leurs données. Les nouveaux achats sont acheminés directement vers les consommateurs qui traitent les commandes, les problèmes de commande sont acheminés directement vers les canaux du service client, et ainsi de suite.

Les architectures orientées événements deviennent essentielles pour permettre aux entreprises d’aujourd’hui de rester en phase avec le marché et de se projeter vers l’avenir. En effet, 26 % des organisations prévoient d’adopter des EDA pour répondre à leurs besoins métier, alors que près de 37 % en possèdent déjà. ¹ Le secteur des logiciels EDA devrait doubler de taille et atteindre un chiffre d’affaires de plus de 16,5 milliards de dollars USD d’ici 2027.² 

Des milliers d’événements métier transitent chaque jour par chaque partie des organisations, et ces événements fournissent une mine d’informations sur ce qui se passe dans une entreprise à tout moment. Cependant, sans technologie appropriée, de nombreuses entreprises ne sont pas en mesure de traiter et d’utiliser ces données pour prendre des décisions éclairées concernant leurs clients, leurs produits ou leurs activités.

C’est là que les plateformes EDA sont inestimables, car elles permettent l’automatisation des processus à haut débit et à faible latence et fournissent des outils avancés pour un éventail de cas d’utilisation, notamment :

Les architectures orientées événements tirent parti des événements commerciaux en permettant aux utilisateurs de détecter les situations critiques émergentes, d’agir en temps réel, d’automatiser la prise de décisions et de maximiser leur potentiel de revenus. Les EDA peuvent également aider les entreprises à soutenir et à accélérer leur croissance en fournissant les capacités suivantes :

Les EDA permettent de dimensionner les systèmes en ajoutant davantage d’instances de services pour faire face à l’augmentation des workloads.

Les EDA permettent aux composants de communiquer de manière asynchrone ; les producteurs publient des messages d’événements selon leur propre calendrier, sans attendre que les consommateurs les reçoivent (et sans même savoir si les consommateurs les ont reçus), ce qui simplifie à la fois l’intégration et l’expérience utilisateur.

Les services peuvent être ajoutés, supprimés ou modifiés indépendamment, ce qui facilite les pratiques de développement et de déploiement agiles.

Les EDA sont découplées dans le temps et la synchronisation, de sorte que les producteurs d’événements et les consommateurs interagissent via les événements (plutôt que via des appels d’API directs), ce qui réduit les dépendances et augmente la résilience globale du système.

L’EDA est intrinsèquement conçue pour traiter et répondre en temps réel, permettant ainsi aux équipes de réagir de manière plus proactive et facilitant des actions et des automatisations plus intelligentes.