Ces dernières années l'usage des microservices, microapplications et des solutions orientées événements a marqué ma vie professionnelle. Les microservices et microapplications sont de mieux en mieux connus et compris, mais j'ai constaté que ce n'était pas vraiment le cas avec les architectures évènementielles.
Pourquoi entendons nous parler de plus en plus d'architecture orientée événements (Event-Driven Architecture) et de flux d'événements (Event Streaming) ?
Pour répondre à cette question mais sans pour autant faire un cours d'histoire, je vais remonter dans le temps afin de mieux cerner les tenants et aboutissants de l'architecture événementielle.
Il y a fort longtemps - pas si longtemps que cela - la principale voire unique stratégie pour la conception des applications était en silo, monolithique : une équipe d'une compagnie avait un besoin, il était traduit tel quel, codé dans une application accompagnée parfois d’un SGBD, le tout installé directement sur une machine, sous un bureau - je caricature.
Pas de problème d'intégration : l'architecture était fermée et seule l'équipe qui avait passé commande pouvait accéder aux données et fonctionnalités.
Avec les besoins grandissant et les évolutions en IT, notamment avec ce petit réseau appelé Internet, les entreprises comprirent que les informations étaient dispersées, redondantes et elles voulaient un moyen de gagner en temps et efficacité - entendez par là gagner plus d'argent.
Alors le besoin d’interconnectivité entre les systèmes s’est fait ressentir de plus en plus fort.
Tranquillement les conceptions des applications ont commencé à s'orienter vers des systèmes plus petits, plus facile à maintenir (et à décommissionner). L’ère des microservices et micro applications a commencé.
Les compagnies avaient une collection d'applications différentes, dans des langages différents, des formats de données différents et pour autant, tout cela devait communiquer ensemble et partager des données avec les microservices à notre aide. Comment ? Avec des projets de modernisation numérique.
Qui a eu la chance de pouvoir travailler sur des projets labellisés "Micro services de transformation de données / ETL" ?
J’ai travaillé pour une compagnie sur ce genre de projet : développer, tester et déployer plus de 10000 microservices Spring Boot qui se connectent à un système archaïque A pour envoyer les données vers un système B obsolète ou presque, avec comme transformations de données des changements de formats de dates ou des changements de types.
Il faut dire les choses telles qu’elles sont : ce n'étaient que des microservices GIGO (Garbage In, Garbage Out) et une perte de temps.
Cette expérience s’est déroulée en 2020 et des solutions existaient déjà.
En effet à cette date, des intergiciels (middlewares) d’intégration existaient déjà et auraient pu éviter toute cette peine : des ESBs propriétaires ou même libres, des ETLs ou même des intergiciels orientés événements qui intègrent des composants variés et astucieux, comme Apache Kafka - purement par hasard.
J’espère qu’ici une chose est bien comprise : les systèmes doivent communiquer entre eux mais il y a des enjeux colossaux : une multitude de systèmes parfois archaïques (ou plus maintenus), des formats de données en pagaille, souvent des protocoles qui différent (que de bonheur d’interfacer des services SOAP avec des services REST) et des volumétries de données conséquentes.
Ma première sous conclusion: faire des micro services à tout va n’est pas nécessairement la solution pour faire de la modernisation numérique.
Et l'événementiel dans tout cela ?
Pour comprendre ce qu’est l’architecture événementielle et ses avantages, nous devons d’abord définir ce qu’est un événement, un flux d'événements et une donnée à un moment T.
Voici l’exemple d’une donnée à un moment T : je suis un homme dans la trentaine, marié, avec un enfant, qui vit au Québec. Ces informations sont précieuses et peuvent être exploitées telle quelle.
Cependant, ce qui me décrit aujourd’hui peut décrire d’autres individus : ce qui me différencie est mon histoire, mon parcours, jonché d’événements. Un événement est un fait atomique et immuable, marquant le changement d’un état, d’un statut : je ne peux contester le fait que je me sois marié, cet événement existe et persistera tant et aussi longtemps que cela sera utile. Important ici de souligner qu’un événement n’est pas forcément utile éternellement : pour ceux qui ne l’auraient pas compris, je parle de stratégie de rétention de données.
De plus, théoriquement, si l’ensemble des événements - le flux d’événements - qui ont constitué mon présent peuvent être rejoués, alors je reviendrais au même stade (c’est très théorique certes car il faudrait sans doute TOUS les événements de l’univers pour y arriver).
Pour les curieux, le fait d'agréger des événements dans un ordre chronologique afin de déterminer la valeur actuelle de la donnée (donnée à un moment T), s'appelle une transformation par restriction chronologique.
Pour des définitions plus techniques:
un événement représente un changement d’état qui par nature est immuable. Il ne peut n’y être modifié ni supprimé (sauf si il devient obsolète)
un flux d’événements est un ensemble d’événements du même type. Il peut être vu comme un historique des changements d’état
une donnée à un moment T est l’ensemble des valeurs actuelles d’un objet. En théorie, en rejouant le flux d’événements d’un objet depuis son origine, nous sommes censés retrouver le même état actuel, la même donnée au moment T
Patrons de conception événementiel
Si je reviens à un contexte technologique, l'architecture événementielle peut aider à capturer les changements dans des systèmes sources, produire des flux d’événements qui seront consommés par des systèmes cibles.
Un événement serait par exemple, une modification d’une ligne dans une base de données, un clic sur une page web ou un changement excessif de consommation des ressources infonuagiques.
Jusqu’ici, je vous parle de l’approvisionnement événementiel (Event sourcing), c’est-à-dire un patron de conception focalisé sur les changements d’états d’une application ou d’une donnée.
Un autre patron est aussi fréquemment utilisé : la transformation de flux d'événements (Event Stream Processing). Pour illustrer cela et faire original (donc ne pas prendre l’exemple tant exploité de la fraude bancaire), je vais parler des voitures autonomes.
Une voiture autonome possède un logiciel de conduite, qui, selon les niveaux d’autonomie, permet de soustraire certaines actions du pilote humain. Pour y arriver, le logiciel utilise bon nombre de capteurs (ultrasons, LiDAR, caméra, accéléromètre…) qui vont agir comme des producteurs d’événements. Ces événements vont être alors agrégés, sur une fenêtre de temps par exemple, pour calculer la distance de freinage nécessaire par rapport aux véhicules proches et donc déterminer les actions à suivre.
Exemple concret : si la voiture de devant freine doucement et qu’il y a une voiture proche à l'arrière, la voiture autonome ne va pas freiner brusquement, mais adapter son freinage (voire se déporter pour certaines). C’est l'agrégation de ces deux données issues des capteurs qui permet de fournir une nouvelle donnée qui est exploitée par le logiciel pilote.
Le principe de la transformation de flux d'événements est assez simple : prendre des événements et les transformer en nouveaux événements pour les enrichir, les agréger, les filtrer, les adapter, les analyser… Il s’agit donc de créer de nouvelles données qui seront plus facilement exploitables ou encore qui auront plus de valeur métier.
Dans un contexte moins tendance, la transformation de flux d’événements peut servir simplement à migrer des données d’une base de données historique vers plusieurs bases de données avec des règles de filtrage différentes, en enrichissant les données qui seraient manquantes (en appelant des web services) afin de découpler les données intelligemment.
Je vous donne mes raisons d’utiliser une architecture événementielle :
centraliser et d’uniformiser l’accès à vos données
suivre le changement d’état de vos données
faire des études comportementales sur vos données et de générer de nouvelles données
L’architecture événementielle ne permet pas :
l’amélioration de la qualité de vos applications et de vos données par le simple fait d’utiliser ce genre d’architecture - AKA par magie
à rendre plus facile le développement ni le déploiement de tous vos systèmes sans former les équipes
l’attraction des nouveaux clients ou talents parce que l’architecture événementielle est "vendeur" ou "hype"
Et sinon Kafka dans tout cela ?
Apache Kafka est une des solutions pour faire de l’architecture événementielle. En effet, il existe plusieurs solutions sur le marché avec leur propre concept et sémantique : RabbitMQ, ActiveMQ, Azure Event Grid, Google Pub/Sub, Apache Pulsar…
Qu’est qui différencie Apache Kafka des autres ?
Son architecture interne basée sur l’élasticité horizontale, la redondance des données, la tolérance aux pannes, la faible latence, les APIs fournies qui facilitent grandement l’intégration de système ou même la transformation des données. Dois-je ajouter que Apache Kafka est open-source ? Cela lui confère un avantage de poids : une communauté active, réactive. D’autant plus que des firmes telles que Confluent contribuent énormément à l'améliorer en repoussant ses limites.
En matière d’intégration de systèmes, une des APIs fournies par Kafka, Kafka Connect est particulièrement intéressante : elle permet d’interfacer des systèmes de données du marché - entendez des bases de données, des systèmes de fichiers - directement avec Kafka.
Par exemple, besoin de migrer une base de données Oracle vers plusieurs bases de données dans des cloud Azure, AWS ou Google ? Kafka Connect va permettre d’installer un Connector source, qui va “copier” les données d' Oracle SQL et produire des messages vers des topics Kafka ; puis utiliser un Connector Sink qui va se charger de consommer ces messages produits et de les "insérer" dans les nouvelles bases de données. Ceci pour un coût en terme de développement minimal (car oui il y aura toujours des petites choses qui font que cela ne fonctionne pas du premier coup).
Pour la transformation d’événement, Kafka Streams offre une API incroyable permet en quelques lignes de codes, de pouvoir développer une micro application performante qui va faire des opérations de transformation simple sans état (stateless) comme du filtre, du mapping, et également des opérations plus complexes comme des agrégations sur des fenêtres de temps. Il y a même la possibilité de transformer des flux d’événements en des "KTables", des similis tables de bases de données qui facilitent d’autant plus l’application de règles métiers.
En bref, des possibilités et des facilités en tout genre sont présentes avec Apache Kafka!
Une chouette conclusion
L’architecture événementielle est une façon décentralisée et uniforme en termes de protocole et de format de données d’aborder l’interconnexion des systèmes. Les microservices ne sont pas toujours l’option optimale mais cela ne remet pas en cause leur usage.
Apache Kafka est une des solutions les plus utilisées par les grandes entreprises pour traiter d'énormes volumes de données, avec des options de réplication avancées, du load balancing. Le tout vient avec de la scalabilité et de la forte tolérance aux pannes.
Dans le cadre d’une transformation numérique, l’usage de l'événementiel (avec ou sans Kafka) peut venir compléter ce qu'apportent déjà les microservices et les micro applications : un découplage des responsabilités applicatives pour se rapprocher d’un patron de conception CQRS effectif.
Alors la prochaine fois que quelqu’un vous parle de connecter des systèmes entre eux pour échanger des données : échanger sur l'architecture événementielle et pourquoi pas Apache Kafka.
Comments