L’architecture « orientée événements » reçoit une attention grandissante, mais quel degré de nouveauté apporte-t-elle ? Ne s’agit-il pas simplement d’un modèle Pub/Sub ? Et quelle est sa place vis-à-vis de la diffusion d’événements, des microservices, de l’apprentissage automatique, des processus robotisés et des autres modèles modernes ?
Chez Chakray, nous possédons une expertise dans tout ce qui touche à l’intégration, du transfert de données traditionnel aux architectures orientées service et à l’ESB, en passant par les approches modernes en matière de microservices.
Dans cet article nous découvrirons ce qu’une architecture orientée événements signifie réellement dans le monde de l’intégration, nous vous aiderons à mieux comprendre si cette approche est à la hauteur de sa réputation et si elle vous conviendrait.
1. Scénarios et description d’une architecture orientée événements
1.1 Qu’est-ce qu’une architecture orientée événements ?
Une architecture orientée événements est traditionnellement un modèle d’architecture logicielle distribuée, asynchrone et hautement échelonnable
1.2 Scénarios d’architecture orientée événements
Jetons un œil à un scénario du monde réel dans lequel l’architecture orientée événements peut être appliquée :
« On vient de vous voler votre téléphone mobile »
Un tel scénario pourrait être traduit par la séquence d’événements suivante :
Signalement du téléphone manquant –> Réception du numéro d’identification du délit –> Communication avec la compagnie d’assurance –> Commande d’un nouveau téléphone –> Transfert des contacts vers le nouveau téléphone…
Cette perspective est simple, car elle omet de nombreuses étapes comme informer ses amis, changer les mots de passe sur les réseaux sociaux, remplacer les cartes SIM, etc.
Adoptons un point de vue différent sur ce scénario, inspirée d’une approche orientée événements :
Publication du téléphone manquant –> Message diffusé
- Police à l’écoute
- Compagnie d’assurance à l’écoute
- Famille à l’écoute
- Amis à l’écoute
- Fournisseur à l’écoute
Il s’agit bien entendu d’une simplification, mais le concept fondamental est clair : un événement survient, les parties intéressées sont à l’écoute et répondent de manière appropriée à cet événement. Ce modèle met en lumière la partie « orientée » du modèle orienté événements, qui constitue véritablement la différence clé avec les autres modèles.
La partie en lien avec l’architecture du modèle fait référence au fait que, dans ce concept, toutes les pièces mobiles du scénario ont été conçues de manière à soutenir l’« événement » ou le « flux d’événements » qui constitue le pilier de ce scénario.
2. Histoire des architectures orientées événements
Ce concept n’est-il pas déjà appliqué depuis des années ?
Et bien il se trouve que si, et du point de vue de l’intégration il s’agit d’un service publication-abonnement. L’« événement » est publié et les abonnés écoutent et réagissent.
Différents éléments ont toutefois conduit à un besoin croissant d’approches orientées événements ces dernières années.
- De plus grands volumes de données
- L’éminence des services et applications distribués
- L’échelonnage dynamique des systèmes et applications
- Les attentes de réponses et actions instantanées (expérience client)
- La prolifération des microservices
- Le besoin croissant d’intelligence et d’agilité commerciales en temps réel
- La montée en puissance de l’IoT et des objets et dispositifs « intelligents »
Cette liste n’est pas exhaustive et il existe un lien évident de cause à effet entre les éléments qui la composent.
Il semblerait même que la plupart de ces éléments découlent de la civilisation dirigée par les services et orientée clients. De manière générale, les clients s’attendent à ce que tout soit disponible sur demande avec un minimum de friction. De nos jours, des taxis sont à notre disposition en tout lieu et à tout moment, nous pouvons regarder la télévision ou des films à la demande, demander à Alexa d’éteindre la lumière. Ces fonctions pratiques et instantanées sont devenues la norme.
Les systèmes Pub/Sub existent déjà, pourquoi changer ?
Changeons notre perspective : focalisons notre attention sur les problèmes pour faire émerger de nouvelles perspectives. Il est possible d’exploiter l’approche orientée événements dans une mesure bien supérieure au simple concept de modèle publication-abonnement. C’est principalement à cette occasion que les concepts comme la diffusion d’événements entrent en jeu.
Traditionnellement, le modèle publication-abonnement consiste à « publier une fois puis espérer que les abonnés ont entendu ». Vous pouvez à présent tirer parti des nouvelles tentatives, des files d’attente et des autres mécanismes pour garantir que le message est bien reçu, mais la nature même du modèle signifie que le diffuseur (publisher) ne sait pas qui est abonné et si les abonnés essentiels ont bien reçu le message. En appliquant cela à l’analogie du téléphone volé, que se passe-t-il si la compagnie d’assurance ne reçoit pas le message ?
Avec la diffusion d’événements, les événements publiés sont stockés sous la forme d’un journal d’événements en cours. Cela signifie que toute l’histoire des événements est conservée et disponible. Si un abonné n’est pas disponible ou qu’il s’est désabonné temporairement au moment de la publication d’un événement, il pourra consulter l’événement, qui reste disponible, au moment où il s’abonnera de nouveau.
3. L’architecture orientée événements dans le paysage actuel de l’intégration
Nous possédons à présent des connaissances fondamentales sur l’architecture orientée événements, le modèle publication-abonnement et la diffusion d’événements. Abordons les points restants de cet article :
- Comment l’approche orientée événements recoupe-t-elle avec les modèles comme les microservices ?
- L’architecture orientée événements est-elle la réponse à tout ?
- Quels sont les freins à l’approche orientée événements ?
Une conception erronée commune définit cette approche comme une architecture pouvant suivre un modèle d’intégration ou l’autre. Certaines personnes peuvent déclarer « nous disposons d’une architecture d’intégration des microservices » ou « nous disposons d’une architecture ESB monolithique ». Différents styles d’architectures peuvent en effet s’y appliquer tout en restant des solutions viables.
Nous n’explorerons pas les connotations du mot architecture dans cet article, mais au bout du compte une architecture orientée événements peut co-exister mais, pour être efficace, cela nécessitera une architecture de microservices complémentaire. L’association de ces deux types peut être qualifiée d’architecture microservices orientée événements. De la même façon, il est possible de réaliser des profits en utilisant une architecture plus monolithique associée à une capacité de diffusion d’événements.
De nombreux facteurs avantageux et déterminants caractéristiques de l’architecture microservices se retrouvent dans une architecture orientée événements, qui permettent toutes les deux de relever des défis similaires.
Cependant, prenez une architecture microservices adoptant une approche d’intégration demande/réponse synchrone traditionnelle ; ce type d’architecture active un service atomique indépendant doté d’un cycle de vie indépendant et, par conséquent et de manière générale, une équipe indépendante qui en est responsable. Si ce service reposait une un flux d’intégration demande/réponse avec un autre microservice (sans raison spécifique), alors le service ne serait pas couplé de manière lâche et n’en serait pas véritablement indépendant. Vous ne pourriez pas mettre à niveau/faire évoluer le service sans vous préoccuper du service couplé.
Il n’est pas indispensable de disposer d’une architecture orientée événements pour surmonter ce problème, car un modèle asynchrone alternatif, comme une file d’attente de messages, constituerait une solution efficace dans cette situation. Cependant, cela démontre dans quelle mesure les caractéristiques d’une architecture orientée événements et la diffusion d’événements peuvent interagir de manière positive avec les microservices.
3.1 Occasions d’appliquer une architecture orientée événements
Jusqu’à présent, le point focal de cet article a largement adopté la perspective de l’intégration, dans laquelle l’approche orientée événements, le modèle publication-abonnement et la diffusion d’événements jouent un rôle prépondérant. Explorons à présent d’autres concepts modernes comme l’IA, l’apprentissage automatique et les processus robotisés.
Nous avons expliqué plus tôt que la diffusion d’événements permet de conserver de manière globale les événements passés et en cours. Il est possible de distribuer le flux dans de nombreux endroits et de le répliquer dans d’autres, c’est-à-dire de le concevoir de manière à ce qu’il gère d’importants volumes d’événements et, par conséquent, de données. Pour en revenir à l’analogie du téléphone volé, imaginons à présent un enregistrement de chaque événement, passé et présent, dans lesquels une personne a signalé le vol ou la perte d’un téléphone.
Pensez à toutes ces données : que pouvons-nous en apprendre et de quelle façon pouvons-nous les utiliser ?
- Moment de la journée/de la semaine/du mois/de l’année où la perte/le vol est le plus courant.
- Les endroits dans lesquels ces événements surviennent le plus ?
- Qu’en est-il des caractéristiques les plus courantes chez les personnes à qui ces événements surviennent le plus ?
Imaginez qu’un fournisseur d’assurances pour les téléphones portables pouvait accéder à ce flux d’événements et l’associer aux données enregistrées concernant les événements de personnes réalisant un achat de nouveau téléphone. Les données constituent aujourd’hui de l’intelligence, qui peut permettre au fournisseur d’assurance d’ajuster les prix de manière dynamique et de proposer des promotions et des efforts commerciaux en vue de maximiser les revenus.
Il ne s’agit que d’un exemple, mais imaginez les possibilités permises dans d’autres scénarios plus alignés avec votre secteur.
Aucun de ces résultats n’est particulièrement nouveau, car des projets d’optimisation et d’analyse du Big Data sont menés depuis des années, mais la diffusion d’événements garantit une meilleure mise à l’échelle, qui permet aux organisations dotées d’une certaine expertise en matière de science des données d’approfondir ce domaine, abaisser les barrières pour les entreprises qui ne pouvaient pas se permettre de réaliser un tel investissement auparavant.
3.2 Pièges à éviter lors de l’adoption d’une architecture orientée événements
Avant de conclure cet article, penchons-nous sur les points négatifs qui justifieraient qu’une approche orientée événements ne soient pas bénéfique.
Le problème majeur avec l’approche « orientée événements » est sa complexité, qui le plus souvent a un lien avec le coût. Les avantages d’une telle approche sont évidents, mais la configuration de journaux d’événements en temps réel, très disponibles et distribués n’est pas une mince affaire et nécessite une organisation rigoureuse.
Voici quelques pièges habituels à éviter lors de l’adoption d’architectures orientées événements :
- Capturer trop d’informations ou des données trop ambigües
Difficile ne pas se laisser emporter en créant des événements à tout va. On se dit parfois que ces événements « pourraient servir plus tard », mais ils participeront au lieu de cela à complexifier le processus et à nécessiter de nouvelles opérations de conception. Certaines choses ne nécessitent pas la création d’un événement, focalisez votre attention sur ce qui est « utile aujourd’hui ». Les événements doivent être faciles à comprendre et à expliquer pour toutes les équipes
- Utilisation inappropriée des événements
Cela peut paraître évident, mais tenter de tout faire rentrer dans l’approche orientée événements est une erreur commune. De par sa conception, l’architecture est couplée de manière lâche et asynchrone. Ainsi, dans des scénarios où une réponse est attendue de la part d’un destinataire connu, dans un délai spécifique, cette approche est-elle la meilleure ? Il existe de nombreuses situations dans lesquelles l’approche pourrait faire plus de mal que de bien.
Le retour sur investissement ou la valeur commerciale doivent être pris en considération dans l’évaluation de la conception pour un flux ou un scénario donné. Par exemple, le coût total imputable à la propriété d’un système de diffusion d’événements en lien avec les « demandes de vacances des employés » permet-il d’obtenir un retour sur investissement ? Il faut retenir que selon les circonstances, une approche pragmatique et basée sur la valeur est parfois la meilleure option.
- Propriété de la technologie
L’aventure orientée événements démarre souvent par un cas d’utilisation non essentiel à l’activité. L’approche peut par exemple être adoptée pour permettre de découpler une application. Dans ce scénario, on perçoit rapidement la technologie comme un facteur habilitant de l’application, qui utilise la conception d’application pour favoriser la propriété. Pour en tirer profit de la meilleure façon, l’approche requiert une conception des données et une approche de l’intégration solides pour être fructueuse en tant qu’outil habilitant de l’organisation.
- Tenter de lancer l’exécution trop tôt
C’est souvent le cas d’une organisation qui se focalise sur le but ultime de « devenir l’entreprise pharmaceutique intelligente la plus automatisée au monde » et qui essaye de résoudre chaque cas d’utilisation en utilisant une approche de choc. C’est le cocktail explosif parfait pour courir à la catastrophe, qui est susceptible d’augmenter la durée nécessaire pour atteindre un tel stade. Les meilleures mises en œuvre commencent petit à petit et grandissent avec le temps, la compréhension et l’expérience.
Pour mieux y parvenir, les leaders du marché Kafka Confluent™ ont élaboré cette courbe d’adoption :
- Attentes irréalisables
Orienté événements ne signifie pas que vous aurez réponse à tout. Si des équipes fonctionnent de manière incorrecte, elles continueront de le faire. Une capacité de déploiement et de test automatisée de manière incorrecte continuera d’exister et cette approche n’y apportera en aucun cas une solution. Une approche orientée événements permet de réaliser de nombreuses possibilités, mais elle ne résout pas tous les problèmes.
Du point de vue technique, les exemples évidents de scénarios dans lesquels l’utilisation d’un outil comme REST ou GraphQL serait préférable sont les suivants :
- Vous aurez besoin d’une interface demande/réponse dans un délai d’exécution spécifique, par exemple une vérification de solvabilité instantanée
- Une transaction pour laquelle il est facile de fournir une assistance est nécessaire
- Une API doit être rendue disponible au public
- Le projet/les exigences concernent un faible volume
Conclusion
En résumé, il est évident qu’une approche « orientée événements » possède de formidables avantages qui deviennent essentiels aux organisations pour survivre et prospérer dans un paysage orienté client et hautement compétitif.
Il ne faut toutefois pas prendre cela à la légère, en particulier dans cette approche, l’importance de la stratégie d’intégration globale et l’établissement des bons partenariats pour évoluer plus sereinement dans la jungle de l’intégration et éviter les pièges habituels.
Aucune solution unique n’est une panacée, c’est l’association des solutions les plus appropriées au bon moment qui guidera une organisation sur la voie de la réussite.
