Qu’il s’agisse d’améliorer l’expérience utilisateur ou l’efficacité des applications, le traitement des données en streaming permet aux entreprises de devenir plus efficaces et réactives en intégrant la capacité d’interagir en temps réel avec leur environnement. Une architecture événementielle suit l'idée qu'il faut concevoir un logiciel à partir d'événements qui se produisent sur le terrain et qui ont un véritable sens métier, de sorte que ces événements deviennent le concept central de l'architecture. « Au même titre que nous avons vu grandir la notion de software defined dans le domaine des infrastructures, le paysage de la data est en train de se transformer sous nos yeux » illustre Eric Carlier. « La data n’est plus perçue comme un ensemble statique d’informations mais comme un flux continu d’événements. Les entreprises qui veulent tirer parti de leurs données pour prendre les meilleures décisions business au meilleur moment doivent à mon sens adopter cette approche, sous peine d’accumuler du retard vis-à-vis de la concurrence. »

« Les entreprises qui veulent tirer parti de leurs données pour prendre les meilleures décisions business au meilleur moment doivent adopter une approche basée event streaming   »

Contourner les limites du database first

Dans une architecture traditionnelle, l’évènement est intégré dans une base de données, notamment grâce à des mécanismes d’ETL. Les applications interagissent avec les bases de données qui elles-mêmes se positionnent en tant que source de données pour d’autres environnements. C’est ainsi que l’on crée des pipelines de données qui dispersent l’information au sein du SI pour alimenter des systèmes de reporting, de monitoring, etc. Mais la limite de ce modèle apparaît avec la complexité croissante des SI. « La propagation de l’information dans les systèmes est de plus en plus longue, les délais de traitement s’allongent également. On parle parfois de plusieurs semaines entre le moment où l’événement a lieu et le moment où il est disponible dans les systèmes d’information » précise Eric Carlier. Dans un domaine tel que la gestion des stocks, cette problématique peut conduire à travailler avec des données fausses ou incomplètes.

« La lenteur de la propagation de l’information dans les systèmes conduit souvent à travailler avec des données obsolètes, fausses ou incomplètes  »

Optimiser le pipeline d’achat pour un site de ecommerce

Autre exemple dans le secteur du e-commerce. Selon l’approche traditionnelle, les services communiquent entre eux à travers des appels de services REST, mais les événements restent éphémères. « Par exemple, lors du passage d’une commande, le service Order déclenche un appel vers le service Shipping chargé d’imprimer l’étiquette. Ce dernier va récupérer les coordonnées du client auprès du service Customer… » explique Eric Carlier. « Dans ce modèle, tous les services sont couplés les uns aux autres. Ainsi, la survenance d’un bug dans le service Shipping peut bloquer potentiellement le service Order et toute la chaîne en pâtit. »

Le passage à un mode de stockage centré sur les événements implique un changement de paradigme. « Pour rester dans le contexte du site de ecommerce, les différents services vont être découplés » poursuit Eric Carlier. « Dans ce modèle, la commande sera transmise sur la plateforme de streaming, sous la forme d’un événement de notification, “commande finalisée”, sans attendre de retour de la part du service Shipping ». En utilisant la notion d’événement comme forme primaire de stockage de l’info, on s’ouvre la possibilité de réagir en temps réel et de rendre cette information immédiatement disponible à d’autres services. Les services gagnent ainsi en réactivité, tout en ayant la possibilité de mettre en forme la donnée dans n’importe quel système sans perte d’information et en optimisant la façon dont cette dernière est présentée. 

Développer de nouveaux services agiles sans bouleverser les systèmes legacy : l’exemple de la Royal Bank of Canada

Comme pour tout projet technologique, l’industrialisation sur des cas d’usage concrets est une phase cruciale pour tirer parti de l’event streaming. La démarche s’appuie sur une plateforme centrale chargée de collecter les événements et les mettre à disposition des systèmes. Pour remplir sa fonction à l’échelle de l’entreprise, cette plateforme doit être hautement scalable et en mesure d’assurer la persistance de la donnée. De plus en plus d’entreprises utilisent Apache Kafka allié à la plateforme Confluent pour convertir en temps réel les bases de données en flux de données live.

« Pour remplir sa fonction à l’échelle de l’entreprise, la plateforme d’event streaming doit être hautement scalable et en mesure d’assurer la persistance de la donnée  »

La Royal Bank of Canada est un bon exemple de projet réussi. « Dans une dynamique de digitalisation, cette banque était confrontée à un double problème » explique Eric Carlier. « D’un côté des sources de données statiques et silotées, et d’autre part un système de traitement centralisé basé sur le mainframe engendrant une grande complexité d’accès aux données, sans parler des coûts associés à ces systèmes legacy ». En mettant en place une architecture event driven, la banque a pu connecter son mainframe et les applications périphériques à la plateforme de streaming. Désormais, toutes les informations sont accessibles aux métiers en temps réel, ce qui a permis de développer de nouveaux services de manière agile, mais également de soulager le mainframe de la charge liée aux anciennes requêtes, avec des économies de plusieurs dizaines de millions de dollars à la clé. « Sans bouleverser leur systèmes legacy avec un gros projet de migration du mainframe, avec un simple offloading vers une plateforme event driven, la Royal Bank of Canada a pu moderniser son architecture » conclut Eric Carlier.