Note : 5 ; Une architecture intéressante rendue difficile d’accès par trop de foisonnement technologique !

Le titre initial de cet ouvrage était « unified log processing ». Et c’est souvent de cela qu’il est question ici. Mais le propos a été quelque peu élargi en cours de route, tout en tournant quand même essentiellement autour des grands bus de messages que sont Kafka et Kinesis. Voyons ce qu’il en est.

Le livre compte près de 300 pages, structurées en 3 parties pour un total de 11 chapitres. La première de ces parties se focalise sur l’aspect Unified Log. C’est la plus conséquente du volume, car elle contribue pour 5 chapitres et noircit près de 115 pages ! Fort classiquement, le premier chapitre introduit quelques grands principes d’architecture de l’event stream, ainsi que des cas d’usage. Tout cela est fort agréablement écrit et très bien illustré. On rentre un peu plus dans le dur au chapitre 2, non pas avec la première partie qui détaille l’event log et la structure d’un évènement (en JSON), mais plutôt par l’illustration de la chose avec Kafka et son installation !

Le 3ème chapitre est assez gourmand. Il nous conduit à écrire notre premier worker Kafka. Cela veut dire aussi mettre en place un environnement de développement avec Vagrant et une architecture comprenant du Zookeeper et tout le toutim. Ce n’est pas très facile à suivre. En fait, on n’a guère le temps de reprendre notre souffle au chapitre 4 qui remet ça, mais avec Kinesis ! Dans son ensemble, le chapitre n’est pas super-agréable à lire : beaucoup de setup AWS (forcément) et de longs listing JSON assez ennuyeux en sont la cause principale. De plus, même si c’est assez logique, le code Kinesis est en Python, ce qui n’est pas ce que je préfère.
Au-delà d’être un chapitre douloureux, le va et vient entre Kafka et Kinesis afin de couvrir beaucoup de terrain est une surcharge technologique qui nuit à l’objectif du livre : nous permettre d’appréhender l’architecture « log unifié ». Cette première partie se conclut sur un chapitre au titre paradoxal : le stateful stream processing. Cela commence de manière fort sympathique avec des concepts tels que les évènements dérivés et le fenêtrage de traitement. C’est plus rugueux en seconde partie de chapitre où les auteurs nous introduisent la suppression de paniers avec Apache Samza, avec le code, l’installation et la configuration qui vont avec…

La seconde partie s’intitule « data engineering with streams » et nous gratifie de 4 chapitres qui s’étendent sur 120 pages. Si la première partie a parlé plomberie, c’est aux données elle-même qu’il est question maintenant. Et cela commence au chapitre 6 par aborder la question des schémas. Le chapitre est plutôt bien fait et moins intimidant que les précédents : y sont présentés les principes généraux des schémas d’évènements avec une petite étude de cas hélas différente de la précédente. Les différentes technologies de schéma sont présentées un peu trop succinctement mais néanmoins clairement. Enfin la seconde partie de chapitre se focalise sur les schémas Avro, leur génération et leur test. C’est très correct.

L’archivage des évènements arrive fort logiquement après leur génération. C’est l’objet du chapitre 7. Le chapitre reprend la structure du chapitre 6 : les principes généraux en premier (ici le manifeste des « 3 R »), et la mise en œuvre (on revient à l’étude de cas du chapitre 5 !) en seconde partie, avec le framework Secor et un stockage sur S3 au format Hadoop « Sequence file ». On ne s’arrêtera pas là, car il sera question de traitement batch en fin de chapitre avec Spark ! Bref une seconde partie de chapitre vraiment très dense !

Le chapitre 8 est mystérieusement intitulé « railway-oriented processing ». En fait, ce chapitre est un peu en rupture des précédents : il présente l’architecture « unified log » promue par les auteurs. Elle est du type « pipe and filters » et les échecs sont représentés par autant d’évènements alimentant des « chemins d’échecs » conduisant soit à des tentatives de recouvrement soit à des nettoyages et consignation d’échecs. C’est réellement passionnant et bien illustré, dommage que côté code il nous faille dégainer une autre technologie, et pas des plus simples : Scalaz ! Le chapitre 9 qui clôt cette seconde partie complémente Unified Log avec des commandes. Là aussi l’impact architectural est clair, on en rajoute juste une petite couche côté techno avec Plum (déjà croisé) et Mailgun.

La 3ème partie est consacrée aux analytics. Elle comprend 2 chapitres qui totalisent 70 pages. On débute par un chapitre 10 consacré aux « analytics on read ». Cette fonctionnalité, c’est en quelque sorte le BI du big data. Bon ici, c’est beaucoup, beaucoup plius compliqué, surtout quand on ajoute Amazon Redshift ! « Analytics on write », décrit au chapitre 11 ajoute une complexité supplémentaire : le temps réel ! Et bien sûr nous avons un cortège de technologies à ajouter à notre pile : DynamoDB et les Lambdas AWS, essentiellement !

Au final, l’architecture « railway », une extrapolation du vieux pipe and filter, présente assurément quelque chose d’intéressant, comme tous les sujets abordés, d’ailleurs. Mais l’ambiance est plombée par une irrationnelle foire aux technologies. Non seulement nous balançons-nous entre deux stacks, mais chacune d’entre-elle est bien trop encombrée d’outils dont la seule prise en main est un petit challenge. Il aurait fallu faire bien plus frugal et n’utiliser qu’une seule étude de cas d’un bout à l’autre du livre.

Référence complète : Event Streams in Action – Alexander Dean & Valentin Crettaz – Manning 2019 – ISBN : 978 1 61729 234 7