Exploitez vos données en temps réel

0:14 Salut tout le monde, bonjour, je suis vraiment vraiment ravie d'être avec vous aujourd'hui pour ce meetup, pour deux raisons déjà, parce que j'adore les meetups Tech.Rocks, mais je pense que ceux qui suivent la communauté depuis longtemps le savent, ce sont vraiment des super moments d'échange, donc je suis vraiment ravie d'être là, ça faisait un petit moment que je n'avais pas animé de meetup, donc je suis vraiment trop contente de vous retrouver. Et puis, deuxième sujet, c'est que, deuxième raison, pardon, c'est qu'en fait, on a un super sujet. Moi, j'adore les sujets qui traitent de la tech. Et on a un sujet bien tech aujourd'hui qui va traiter de comment valoriser les données. Et en fait, plus précisément, on va parler de temps réel. De comment on traite la donnée en temps réel et c'est quoi les cas d'usage qui peuvent être pertinents pour faire ça. C'est un sujet que j'adore vraiment parce que j'ai fait pas mal de data engineering. Je suis ravie de faire ça. Je ne vais pas vous parler de ça toute seule, je vais avoir des superbes personnes qui vont nous accompagner lors de ce meet-up.

1:17 qu'on va accueillir juste après. On va avoir trois personnes. On va avoir Benjamin. Benjamin Coste de la société Confluent. Confluent, c'est un éditeur. On va en apprendre un peu plus tout à l'heure. avec Benjamin, donc Account Manager chez Confluent. Ensuite, on va avoir une intervention de Christian Dubois, qui est Senior Solution Engineer chez Confluent. Et puis, on va finir par un cas d'usage, un retour d'expérience avec Charles, Charles Besselievre, pardon, j'espère que je le prononce bien, qui est CEO d'Affilizz. Voilà, sans plus tarder, je vais inviter mon ami Benjamin. Bonjour. Alors, est-ce que vous m'entendez bien? Tout est bon? Normalement, oui, on t'entend, mais je vais laisser peut-être les participants aussi nous dire s'ils nous entendent bien. Oui, ça a l'air d'aller. Parfait. Écoutez, ravi également de faire ce point avec vous aujourd'hui. Donc, en effet, l'idée là, pour ces quelques minutes, ça va être d'introduire le sujet. Qui est exploiter les données en temps réel.

2:21 Donc, c'est un sujet qui est vraiment d'actualité. Pour mettre peut-être un petit peu de contexte, le cabinet IDC a publié en 2022 un rapport sur l'exploitation de la donnée en temps réel, puisqu'en fait, ils ont noté qu'une grande majorité d'organisations, plus de 74%, considèrent justement que disposer d'informations en temps réel va représenter un atout pour leur activité dans les années à venir. C'est vraiment un sujet qui est crucial pour les entreprises, mais beaucoup d'entre elles rencontrent quand même des problèmes pour traiter cette donnée en temps réel. On va un petit peu en parler aujourd'hui. Et elles ont conscience que c'est un enjeu puisque la situation pourrait s'empirer si elles n'arrivent pas à traiter ces données en temps réel, puisque justement elles anticipent une augmentation du volume de ces données en temps réel. Donc aujourd'hui, on va voir quels sont les enjeux autour de ce traitement de données et pourquoi Kafka va pouvoir être une bonne alternative justement pour atteindre ses objectifs.

3:25 Donc, on voit ici à l'écran, justement, les résultats d'études IDC, les principales raisons pour lesquelles, finalement, la donnée en temps réel va être cruciale pour les différentes entreprises. Donc, l'idée, c'est qu'on voit que, justement, les données pour l'IT, pour la cybersécurité et pour la production, sont déjà celles qui sont le plus souvent gérées en temps réel. Donc ce constat va encore se renforcer à l'avenir, les entreprises anticipent, notamment puisque par exemple on a la montée en puissance de l'industrie 4.0, et donc avec cette industrie 4.0, il y a de nouvelles technologies comme par exemple les objets connectés qui vont justement renforcer le flux de données en temps réel. Donc, c'est un enjeu autour du pilotage de la production. Il y a aussi un enjeu autour des informations relatives à la relation client. Ici, l'idée, c'est vraiment pour les organisations de pouvoir améliorer les échanges avec les clients, quel que soit le canal d'ailleurs, et notamment améliorer ces relations grâce à des interactions qui sont personnalisées.

4:30 Et qui sont contextualisés. L'idée, c'est aussi de mieux gérer les réclamations, donc en termes de service client, puisque dans ces cas-là, en fait, la réactivité va être vraiment un facteur fondamental pour avoir la meilleure expérience client. Et on voit aussi de plus en plus de cas d'usage autour de la détection de la fraude et aussi des données financières. L'idée, c'est donc d'arriver à, là aussi, être au courant, d'anticiper. Potentiel problème pour les organisations autour de ces sujets-là. Donc ici, on a un petit peu de temps. On voit que les entreprises comprennent qu'il y a un enjeu autour de la donnée en temps réel. Mais comme on a dit en introduction, même si elles ont conscience de cet enjeu, c'est difficile à gérer. D'après justement le cabinet IDC, c'est plus de 93% des organisations qui sont confrontées à des difficultés. Et on voit ici les principales raisons. Donc, une majorité d'entre elles, les problèmes sont premièrement relatifs à la capacité de leurs applications à gérer le temps réel.

5:32 Donc, incompatibilité de ces applications. Un autre sujet, c'est aussi l'intégration de multiples sources de données. Qui font que c'est compliqué là aussi d'avoir vraiment une bonne exploitation de ces données. Et enfin, un sujet qui est émergent et qui est de plus en plus d'actualité, c'est le déficit de compétences internes pour justement traiter ce flux de données qui augmente. Donc, il y a ces contraintes qui ont été identifiées par les organisations. Et ce qui est assez intéressant là aussi de noter, c'est que justement, en plus de leur donner des données de leurs clients, de leurs données internes, les entreprises cherchent de plus en plus à intégrer justement des données issues de tout leur écosystème, comme par exemple les données issues des partenaires commerciaux, des fournisseurs pour gagner en efficacité. Ces données-là proviennent de sources qui sont souvent cloisonnées. Et donc, c'est là aussi où il va y avoir des difficultés grandissantes pour pouvoir bien... l'exploiter. Donc face à ces différentes contraintes identifiées, les entreprises décident donc de déployer Kafka.

6:39 Donc Christian, il y aura un petit peu plus en détail dans l'explication technique de Kafka tout à l'heure, mais l'idée c'est juste très rapidement d'avoir une idée de ce qu'est Kafka et pourquoi c'est publicité par les organisations. Donc Kafka, c'est une plateforme open source de streaming d'événements. Et l'idée de Kafka, c'est de pouvoir justement traiter en temps réel ce flux massif de données pour pouvoir les stocker et les rendre accessibles à toutes les applications d'entreprise. Donc Kafka, c'est conçu pour gérer des flux de données provenant de plusieurs sources et pour finalement mettre cette donnée aussi à distribution de plusieurs utilisateurs potentiellement. Donc on le voit ici à l'écran, pour comprendre le fonctionnement de Kafka, il faut d'abord comprendre le concept d'événement. Un événement, c'est par exemple lorsque l'utilisateur va s'enregistrer sur un système ou qu'une transaction, par exemple, est effectuée sur un site Internet. Un événement, ça peut être aussi un message qui contient des données.

7:42 Et donc ce message va être traité et potentiellement aussi sauvegardé quelque part si nécessaire. Donc si on reprend l'exemple que j'évoquais tout à l'heure de l'enregistrement sur un système, un événement, ça pourrait être un message contenant des informations comme le nom d'utilisateur, l'adresse e-mail ou le mot de passe par exemple. Donc Kafka va vraiment permettre de travailler avec ces flux d'événements dans l'objectif in fine, c'est ce qu'on voit ici, d'améliorer l'expérience client et aussi d'optimiser les opérations back-end par exemple. Donc, on parle ici de Kafka et d'événements. Souvent, les entreprises commencent leur initiative d'event streaming avec, par exemple, du messaging. Mais ce qu'il faut garder en tête, c'est que Kafka, justement, va beaucoup plus loin que juste du messaging. Donc, premièrement, à la différence des outils de messaging, Kafka va retenir les messages après qu'ils aient été consommés. Pendant une certaine période de temps. Donc les messages ne sont pas supprimés immédiatement après confirmation de réception.

8:45 Et donc finalement, Kafka va agir en tant que source de données, source de données fiable, en stockant ces données à plus ou moins long terme et en permettant par exemple une relecture de la donnée si c'est nécessaire. Donc ça, c'est le premier aspect. Deuxièmement, Kafka va justement casser les silos où les données sont stockées. Et donc, vous n'avez plus besoin de connecter chaque source de data à chaque application. Kafka est connecté à tout votre système. Et enfin, troisièmement, ce qu'il faut garder en tête, c'est que Kafka, c'est surtout aussi un outil de data streaming, c'est-à-dire que Kafka permet d'exploiter la donnée enrichie qui est la plus à jour. Donc, la donnée finalement est traitée. Elle est intégrée en temps réel de façon simplifiée. Elle est sans cesse enrichie, synchronisée, vraiment mise à disposition de tout l'écosystème de données. Donc finalement, la valeur de Kafka et d'Event Streaming, c'est vraiment de pouvoir, comme on voit à l'écran, construire ces applications en temps réel.

9:46 Donc à la fois, bien sûr, on va fournir un modèle de messagerie public-subscribed, mais on va aussi permettre le stockage de la donnée à plus ou moins long terme et permettre donc de construire par exemple des applications qui misent sur la donnée en temps réel. Donc, une fois qu'on a ça en tête, on va faire le lien entre Kafka, justement, et les premiers chiffres qu'on a vus au début de la présentation sur l'exploitation de la donnée en temps réel. Donc, on l'a dit, Kafka, ça suscite de plus en plus d'intérêts d'entreprise. Il y a plus de 70% des entreprises du Fortune 500, donc c'est plus de 100 000 organisations dans le monde qui utilisent Kafka, dans toutes les industries. Donc, toutes les industries sont concernées. Et on voit que Kafka va être pertinent pour, justement, le pilotage de la production, le décisionnel, la cybersécurité et la relation client. Par exemple, vous pouvez imaginer une institution financière qui va utiliser les données du streaming, des séries chronologiques, pour par exemple lutter contre la fraude, optimiser l'expérience de ses clients,

10:47 améliorer sa stratégie de marketing en temps réel, pour pouvoir miser sur cette donnée-là. On l'a dit aussi, une tendance qui émerge, c'est dans l'industrie 4.0. Kafka va être de plus en plus utilisé pour l'enceinte prédictive, pour justement surveiller les flux de données qui proviennent d'équipements et d'objets connectés. Puisque justement, ces équipements vont requérir un traitement de données en temps réel. Donc l'idée, c'est vraiment que Kafka puisse être utilisé. Pour l'ensemble des services des entreprises et pas seulement pour quelques initiatives. Et c'est ça aussi le message qu'il faut garder en tête, c'est que pour vraiment tirer parti du streaming d'événements et de Kafka, il faut vraiment sortir de quelques initiatives. technique ponctuelle pour vraiment arriver à constituer un système nerveux, on dit souvent un système nerveux central de l'entreprise, pour que Kafka soit déployé sur plusieurs cas d'usage. Et donc là aussi, l'enquête d'IDC révèle que c'est là où les entreprises peuvent être confrontées à des difficultés pour mettre à l'échelle Kafka.

11:51 Il faut là aussi le garder en tête. Donc souvent, les entreprises, lorsqu'elles abandonnent leur projet de streaming, c'est parce qu'elles ont mis trop de temps à les mettre en œuvre ou parce que c'était trop difficile à gérer une fois en production. Donc on voit les principales contraintes, c'est le temps passé sur la gestion opérationnelle de Kafka, lorsqu'il y a de plus en plus de data qui est exploitée parce qu'il y a de plus en plus de cas d'usage. Et c'est aussi le fait que les entreprises doivent s'assurer que cette donnée qui est utilisée dans Kafka est sécurisée, encryptée, que les accès soient contrôlés. Et donc, en fait, lorsque Kafka devient vraiment ce système nerveux central d'entreprise, il faut vraiment s'assurer de son bon dimensionnement, de sa disponibilité, pour éviter qu'il y ait des interruptions qui impactent potentiellement les opérations de business. Donc c'est parce qu'il y a ces contraintes justement qui sont émergentes que les entreprises vont montrer vraiment de plus en plus d'intérêt dans des solutions gérées qui vont être capables justement d'offrir une meilleure sécurité, un meilleur contrôle des coûts, une plus grande flexibilité pour pouvoir mettre à l'échelle

12:52 Kafka sur différents cas d'usage. Pour justement évoquer les solutions pour mieux gérer Kafka. Je vais laisser la parole du coup à Christian et à Charles qui vont témoigner un petit peu plus en détail. Merci Benjamin. Juste une petite question, le temps qu'il y ait quelques questions après. L'étude que tu évoques, on peut avoir le lien, je ne sais pas si vous l'avez posté ou pas. Oui, je pourrais éventuellement le mettre peut-être dans le chat. C'est une étude, un effet IDC qui a été faite. Ça peut être intéressant, je pense, pour l'audience. Et du coup, ça concerne tout type d'organisation, tout type. Ici, Tech.Rocks, on a, je pense, pas mal de scale-up, pas mal de start-up, des organisations aussi un peu plus... C'est vrai qu'il y a un échantillon assez représentatif. Il y a beaucoup, je pense, quand même de grandes entreprises, mais il y a aussi des organisations de taille intermédiaire, par exemple des scale-up, qui sont aussi concernées par ces sujets-là. Ok. J'imagine que ça requiert aussi, enfin voilà, c'est des cas d'usage où il faut architecturer de toute façon, il faut cadrer, il faut voir quel est le bon.

13:59 Et c'est des sujets peut-être qu'on va voir avec Christian juste après. Comment on s'y prend. Et voilà, donc effectivement, on a eu un tour d'horizon, une ouverture avec toi. Merci Benjamin. Avec plaisir. À la fin, on se retrouvera à la fin. Donc, si vous avez des questions pour Benjamin, gardez-les bien au chaud. On va y prendre à la fin avec l'ensemble des intervenantes et intervenants d'aujourd'hui. A tout à l'heure, Benjamin. Eh bien, sans plus tarder, Christian, tu me rejoins, s'il te plaît. Super, t'es là. Bonjour à tous. Vous me voyez? Vous m'entendez? Oui, on te voit, on t'entend. J'espère que tu vas bien. Oui, très bien. Je dis noir, mais nous, on est bien ici. Dans notre meet-up, Tech.Rocks a parlé de données et de streaming et d'architecture orientée événement. Christian, toi tu es senior engineer chez Confluent, c'est ça? Voilà, exactement. Donc, c'est de l'avant-vente technique.

15:00 Super, mais tu es quand même très technique et c'est pour ça que tu nous intéresses. Donc, on a eu une mise en bouche avec Benjamin. On a envie d'en apprendre beaucoup plus avec toi. De flore et de source. Merci beaucoup, Meriem. Bonjour à tous. Comme expliquait mon collègue Benjamin, je vais aller un peu plus dans la technique. L'idée de cette session, ça va être d'expliquer de manière un peu plus technique ce qu'est une event streaming platform. Qu'est-ce que Kafka dans ce monde-là et qu'est-ce que Confluent? Et tout ça à travers d'un use case métier qui est la gestion de flotte. Et là, en l'occurrence, ça va être la gestion de flotte temps réel, bien sûr. Alors, on va commencer par définir un peu ce que je parle par gestion de flotte. La problématique ici, ça va être pour un opérateur, donc au travers d'une centaine, voire de milliers de points de livraison.

16:11 Et puis également avec une flotte de véhicules qui peut être composée d'une dizaine, voire une centaine de véhicules, de générer au quotidien un plan de livraison pour ces milliers de points de livraison. Le but étant bien sûr d'optimiser d'optimiser ces plans de livraison avec comme objectif de réduire le coût et l'être efficient. Alors comment on fait ça? Bien sûr, ça consiste à avoir un taux de remplissage optimisé pour chaque véhicule et puis un trajet également qui est optimisé de telle sorte à ce qu'on arrive à réduire le temps global du trajet pour ces différents véhicules pour pouvoir livrer ces marchandises. Et au final, bien sûr, ça va représenter un gain pour les entreprises qui sont dans ce domaine-là.

17:13 Et puis par-dessus tout, bien sûr, c'est également la satisfaction client. Alors, présenter comme ça, ça paraît simple, mais c'est un problème extrêmement complexe, surtout si on veut faire ça, non pas de manière quotidienne, mais faire ça en temps réel, c'est-à-dire pouvoir réagir à tout type d'aléas. Donc, ça peut être un accident, des problèmes de circulation, des véhicules en panne, des employés qui sont peut-être absents, etc. Et pour résoudre ce problème, il y a différents types de patterns. On appelle ça en fait, souvent, c'est en anglais, on appelle ça véhicule routing problem. Donc, ça fait intervenir différents modèles. mathématiques, donc ça existe, ces modèles sont connus, extrêmement complexes, donc c'est du machine learning, ça peut être des réseaux neuronaux, etc. Et donc c'est un traitement qui est quand même relativement complexe à partir du moment où on commence à intégrer du flux temps réel.

18:15 Mais en amont de ça, pour pouvoir optimiser ce traitement, il y a un autre problème, et j'irais même que ce problème-là est encore plus complexe, c'est comment récolter ces flux de données en temps réel. Donc c'est vraiment la donnée, parce qu'on a besoin de beaucoup de données pour pouvoir optimiser ce processus. Et c'est là que les choses se compliquent, parce que quand on parle de gestion de flotte, de problématiques de gestion de flotte, ça relève de la logistique. Et la logistique n'est qu'un maillon de la chaîne d'approvisionnement. Et les données dont on a besoin pour pouvoir optimiser ce traitement sont réparties sur les différents autres maillons qui composent cette chaîne d'approvisionnement. Et concrètement, en fait, quand on regarde dans les entreprises, ces différents maillons qui composent la chaîne d'approvisionnement vont être représentés par différents business units, différents business lines.

19:19 Et chacun avec leurs propres données, leurs propres modes de stockage, différents types de bases de données, différents types de data warehouse. Un ensemble d'applications également. Et puis des formats de données qui leur sont propres aussi. Donc, c'est extrêmement compliqué, en fait, dans ce monde qui est complètement siloté, de pouvoir échanger de la donnée. Alors bien sûr, les technos ont beaucoup évolué depuis les années 90. On a eu tout au début, on avait l'habitude d'utiliser ce qu'on appelle des middlewares, en fait orientés. des messages, des MOM. Par la suite, on a eu d'autres patterns. Tous ces patterns-là, en fait, on peut les regrouper, on peut appeler ça des patterns d'intégration. Donc, on a eu des patterns open spoke, des brokers d'intégration, des EAI, des serveurs d'application aussi qui commençaient à faire un peu d'intégration, le standard JMS.

20:22 Et puis, à la fin des années 90, on a vu émerger la technologie SOA, essentiellement basée sur du SOAP, SOAP XML. Et à cette époque-là, on croyait tous que ça allait être le standard pour les années à venir, pour les dizaines d'années à venir. Et donc, ce qui s'est passé, c'est que les éditeurs d'EAI ont commencé à faire des ESB pour être compliant avec ces nouvelles technologies-là. Et puis après, vers les années 2006, etc., on a entendu que SOA était mort, SOAP était mort, et puis on a eu de l'API REST, et puis des besoins de gouvernance autour des API, donc des outils d'API management. Et puis plus récemment, essentiellement dans les architectures microservices, qu'on appelle des services mesh, etc. Mais tout ça pour vous dire qu'en fait, les technos ont beaucoup évolué. Mais dans la réalité, en fait, dans les organisations, les nouvelles technos n'ont pas remplacé les anciennes technos.

21:30 les technos un peu plus traditionnels, legacy, comme on dit, ça s'est juste accumulé, en fait. Donc, au final, le problème est devenu encore plus complexe avec l'accumulation de ces différentes technos. Mais globalement, on avait la manière vraiment d'échanger de la donnée entre différents business lines, business units. Ça a été de se dire, OK, on va exposer des services, on va exposer des API et on va faire communiquer ces API ensemble, donc ces différents services qui appartiennent à différentes business lines. Et puis, de cette façon-là, on va échanger de la donnée. Et quand on regarde, il y a eu, Il y a essentiellement deux approches pour faire communiquer ces différents services. Donc, une approche beaucoup plus point à point, aujourd'hui plus basée sur du REST API. Il existe encore un peu de SOAP, c'est la réalité, mais c'est essentiellement de la communication synchrone.

22:32 Et on a également... Une approche un peu plus asynchrone, on va dire, basée sur des bus de messages plus traditionnels. Mais si on prend par exemple l'approche point à point, ça paraît évident, à partir du moment où on commence à exposer un service avec de l'API, on crée une interdépendance entre différents services, différents business lines. Donc, si il y a un service fait... évoluer son API, il faut que l'autre service s'adapte. Donc, au final, en fait, ça ralentit énormément les temps de mise en production de nouvelles fonctionnalités, de nouvelles applications. Et puis, deuxième point, c'est que souvent, avec ces connexions point à point entre les différents services, c'est extrêmement difficile de parler de scalabilité horizontale. Ça nécessite de mettre en place différents types de patterns, service discovery, circuit breaker, etc.

23:35 Et ça représente un coût opérationnel extrêmement élevé quand on est sur ce mode de communication. Et puis honnêtement, voilà. Tout le monde n'est pas Netflix, tout le monde ne peut pas se permettre de mettre en place tous ces patterns-là et de les faire évoluer. Je parle de ça parce que Netflix a été un peu précurseur dans ce domaine-là pour mettre en place ces différents patterns. Et puis, l'approche asynchrone basée sur des bus de messages traditionnels. Benjamin l'a évoqué tout à l'heure rapidement. Ces bus de messages traditionnels sont basés sur un mécanisme de queue qui est destiné à chaque service. Puis, un routage qui est fait par les brokers. Et les messages ne sont pas persistants. Donc, une fois que le message est consommé, il disparaît. Donc ça, c'est un gros problème. Et au-delà de ça, en fait, quelque part, on n'a fait que déporter le problème qu'on avait au niveau des API dans les communications pour un point.

24:38 On les a ramenés au niveau de la donnée parce qu'on n'a pas réellement de gouvernance. Donc, si jamais le producteur d'un message fait évoluer le format d'un message, on se retrouve avec le même problème. Donc, c'est toujours une interdépendance entre différents business units. Donc, ça ralentit les temps de mise en production. Deuxième point, souvent ces solutions-là sont des solutions monolithiques, avec des gros serveurs en mode actif-passif, qui sont scalables à la verticale, mais pas à l'horizontale. Et puis, ce sont des solutions qui coûtent extrêmement cher. Autant vous dire que ces deux approches-là ne sont pas du tout adaptées pour ingérer des pétabytes de données en temps réel. Donc ça, c'est vraiment le problème sur ces deux approches-là. Donc on a vraiment besoin de faire un changement de paradigme.

25:44 Donc sortir de ce monde un peu appel de méthode distante, qu'on appelle souvent RPC, donc en exposant des services et des API au niveau des différents business lines, et d'aller vers une approche qui est beaucoup plus centrée sur la donnée. Donc une plateforme qui soit capable d'ingérer des pétabytes de données en flux temps réel, qui soit scalable à l'horizontale, qui persiste la donnée et qui s'intègre en fait dans l'écosystème existant. Parce qu'effectivement, vous pouvez vous dire, oui, on vient rajouter une techno supplémentaire, finalement, au-dessus de toutes ces technos que j'ai évoquées, qui ont évolué depuis les années 90. Mais en fait, la particularité de cette plateforme, c'est de s'intégrer à l'existant et de permettre en fait une migration progressive. Parce que forcément, on ne va pas faire un changement Big Bang du jour au lendemain, remplacer toutes les technos existantes, mais on va venir s'intégrer

26:46 dans ce qui existe déjà dans les organisations et ainsi faire coexister des bases de données traditionnelles, des data warehouses traditionnelles, avec des systèmes un peu plus modernes, pourquoi pas sur des clouds publics. Et puis également des applications monolithiques qui peuvent coexister avec des applications beaucoup plus modernes, cloud natives, basées sur des architectures microservices. Et puis faire cette migration de manière progressive. Donc c'est vraiment avec cette idée-là que Kafka a été créé par des ingénieurs chez LinkedIn en 2010 et ça a été open-sourcé par la suite sous licence Apache. Donc, qu'est-ce que c'est Kafka? Pour aller un petit peu plus en détail, ce qui caractérise Kafka, c'est vraiment ces trois piliers-là. C'est avant tout un système de stockage distribué. Donc, vous pouvez voir ça comme une plateforme de système de fichiers qui est distribué sur différents serveurs, donc on appelle des brokers, et l'ensemble de ces brokers, c'est ce qui constitue le cluster Kafka.

27:56 Et ces fichiers sont partitionnés et répliqués sous licence Apache. Donc, qu'est-ce que c'est Kafka? Pour aller un petit peu plus en détail, ce qui caractérise Kafka, c'est vraiment ces trois piliers-là. C'est avant tout un système de stockage distribué. Donc, vous pouvez voir ça comme une plateforme de système de fichiers qui est distribuée sur différents serveurs, donc on appelle des brokers, et l'ensemble de ces brokers, c'est ce qui constitue le cluster Kafka. Et ces fichiers sont partitionnés et répliqués sur... sur les différents serveurs qui sont les brokers. Donc de cette manière-là, on garantit en fait la durabilité, Et puis, comme c'est stocké dans des fichiers, c'est persistant. Donc, vous pouvez mettre autant de producteurs et de consommateurs l'un en face de l'autre et les messages ne vont pas disparaître. Et donc, on en vient au deuxième pilier. Qui est le PubSub. Kafka, on peut appeler ça un système PubSub un peu revisité, parce qu'en fait, au travers de l'API client Kafka, Kafka permet à des producteurs de venir écrire dans ces fichiers, et puis de l'autre côté à des consommateurs de venir lire. Dans ces fichiers, mais avec une API qui est extrêmement simple, type PubSub. Et puis, le troisième pilier, qui est pour le coup extrêmement important et qui différencie complètement Kafka

28:58 des autres systèmes PubSub, c'est la capacité de traiter la donnée à la volée en temps réel. Voilà donc pour définir vraiment un très haut niveau, sans rentrer trop dans le détail, Kafka. Alors maintenant, qu'est-ce que... Alors, je vais aller sauter une étape. Ça, c'est juste pour vous montrer, en fait, comment la plupart des organisations adoptent Kafka. C'est via ce qu'on appelle Kafka Connect, qui est une librairie, en fait, qui permet d'injecter de la donnée qui provient de différents systèmes dans Kafka et également de déverser la donnée qui se trouve dans Kafka vers d'autres systèmes existants. Tout ça sans avoir à écrire une seule ligne de code, mais juste en paramétrant. Et ce mécanisme-là, il est complètement scalable en fonction de la charge. Donc, ce qu'on constate, c'est que la plupart des clients, quand ils commencent à utiliser Kafka, utilisent.

30:00 Kafka Connect. Donc Kafka Connect, c'est vraiment une librairie qui s'appuie sur, encore une fois, l'API client et ce mécanisme de producteur-consommateur, mais ça évite d'avoir à écrire du code pour des systèmes déjà existants qui, du coup, n'auraient aucune valeur métier. Christian, on peut faire peut-être, je ne sais pas s'il y a des questions, je n'ai pas l'impression qu'il y ait des gens qui ont posé des questions, mais peut-être qu'on peut faire une petite pause sur ce que tu as présenté jusque-là. Oui. Sur Kafka, c'est hyper intéressant. Donc, peut-être insister sur le fait que Kafka est un système distribué. Donc, en fait, tu as parlé de réplication, tu as parlé de durabilité. Donc, tout ça, il y a des histoires de compromis, finalement. Donc, pour la cohérence, le théorème de cap, je ne sais pas si les gens sont… N'hésitez surtout pas à poser des questions. Si vous n'êtes pas familier avec les systèmes distribués, ce sont des notions assez complexes. Donc, franchement, n'hésitez pas.

31:00 Il n'y a pas de… Voilà, toutes les questions sont bonnes à poser. Donc, est-ce que tu peux nous dire comment est-ce que Kafka, jusqu'à quel point Kafka, justement, est configurable pour… coller à un cas d'usage par rapport à ces compromis-là sur, je ne sais pas, si on veut, comme tu l'as dit, on a besoin que l'information soit durable, donc elle est persistée, mais on va faire un compromis sur autre chose. Inversement, on a besoin que la cohérence soit plus rapide, Donc, peut-être qu'on fera un compromis sur autre chose. Est-ce que tu peux nous dire jusqu'à quel point on peut jouer avec la technologie pour coller à notre cas d'usage? Alors, je vais essayer de ne pas trop rentrer dans les détails techniques. Mais effectivement, comme tu le dis, c'est un compromis. Souvent, on fait un compromis en ce qu'on appelle le throughput, la latence, la consistance de la donnée. Alors, très rapidement, j'ai expliqué que c'était un système de fichiers distribués. Donc, ces fichiers-là sont des fichiers de log, en fait, de log d'événements.

32:05 Ces fichiers vont être partitionnés et répartis, en fait, répartis, répliqués sur les différents brokers, donc qui sont les différents serveurs, en fait. Donc, en termes de paramétrage, par exemple, ce qu'on peut imaginer, c'est est-ce que je privilégie plus la consistance, auquel cas j'attends que la réplication soit faite sur l'ensemble des serveurs pour dire que pour recevoir un acquittement, parce qu'il y a un mécanisme d'acquittement, et à ce moment-là, forcément, la latence va être impactée, par exemple. Donc, si la latence est très importante, auquel cas, on ne va pas... Que quand un producteur écrit, que le message soit bien répliqué sur l'ensemble des serveurs pour pouvoir considérer que j'ai reçu mon acquittement. Et le message est bien consistant, sera bien consistant dans le temps. Donc ça, c'est un aspect.

33:08 Après, il y a cette notion de rétention, donc tu en as parlé. Effectivement, par défaut, vous imaginez bien, c'est du stockage derrière. Donc, plus on augmente la rétention, plus on va avoir besoin de stockage, de capacité de stockage. Par défaut, la rétention est à 7 jours. Donc, encore une fois, là, c'est un compromis à faire entre la taille des messages qui vont arriver, la fréquence à laquelle ils vont arriver et la capacité de stockage dont on dispose. Et en fonction de ça, on ajuste bien sûr la rétention. Après, si je vais un peu plus loin, il y a des moyens pour… pour optimiser ça et éventuellement considérer qu'est-ce qui est du stockage à chaud, qu'est-ce qui est du stockage à froid et éventuellement déporter tout ce qui est stockage à froid historisé vers d'autres systèmes un peu moins coûteux que les systèmes locaux. Mais voilà, ce sont des sujets relativement complexes et il y a beaucoup de paramétrages et d'optimisations possibles de faire dans Kafka.

34:19 Et d'où le fait que c'est un système complexe. Exactement. Comme tous les systèmes distribués, finalement. Exactement. On a une question de Bilal qui est hyper intéressante. Qui parle de format de données qu'on peut échanger entre un consommateur et un producteur. Est-ce que tu peux nous en dire un peu plus sur les formats les plus communs des fichiers qui sont échangés? Oui, bien sûr. Oui, alors la plupart, le format le plus simple, on va dire, ça va être du JSON qui va être échangé. Après, on peut avoir un format binaire, en tout cas, c'est ce qu'on recommande dans des environnements de production, avec de l'avro, parce qu'à l'avro, Avec ce format-là, on peut aussi faire de la validation de la donnée, assurer de la compatibilité. Du versionning. Voilà, du versionning et assurer de la compatibilité. Justement, je parlais tout à l'heure, j'évoquais le problème de gouvernance avec les bus de messages traditionnels.

35:21 Et justement, ça vient apporter une réponse à ce problème-là, Kafka, par ce biais-là. Parce qu'Avro, comme vous le savez, ça inclut également le format du message. Et donc, ça permet de faire de la validation de la donnée. Merci, les métadonnées en effet. Super. Eh bien, écoute, un immense merci pour tes réponses. En plus, ça nous a permis de faire une petite pause sur Kafka. On peut reprendre sur Confluent maintenant? Qu'est-ce que Confluent nous permet de faire en plus? Voilà. Donc, vous l'aurez compris, Kafka est un système extrêmement complexe parce que distribué, comme tout système distribué, c'est complexe. Donc, opérer Kafka à l'échelle d'une entreprise dans un environnement de production, c'est une tâche à temps plein et ça nécessite énormément de ressources et d'expertise. Donc, avec cette idée-là, en fait, les créateurs de Kafka, donc qui ont créé Kafka en 2010 chez LinkedIn, ont créé la société qui s'appelle Confluent en 2014.

36:27 L'idée, c'était vraiment d'aider. les entreprises dans l'adoption de 4K. Donc, ça commence par tout d'abord compléter Kafka avec un certain nombre de fonctionnalités qui vont être indispensables dans un environnement de production. Je parlais tout à l'heure de la validation, de l'aspect validation de la donnée. Et de tout ce qui est une brique, on va dire, la validation dans ce qu'on appelle la gouvernance. Parce que bien sûr, vous avez la sécurité de la donnée aussi qui va avec. Et donc, ce type de fonctionnalité, on vient l'apporter avec ce qu'on appelle Confluent Platform. Donc, on a enrichi le Kafka Open Source avec un ensemble de fonctionnalités. Là, j'ai parlé juste de l'aspect gouvernance. Donc, il y a la sécurité, bien sûr, du Airbag, différents types de déploiements pour des stratégies PRA, PCA, par exemple.

37:34 Nativement, ça n'existe pas dans Kafka, donc il faut le mettre en place. Et donc, c'est vraiment ça l'idée principale derrière Confluent Platform. C'est en complet. Moi, en premier, Christian, c'est hyper intéressant. C'est-à-dire que Confluent est basé totalement sur un Kafka open source avec des fonctionnalités en plus, si on comprend bien. Donc, c'est toutes ces fonctionnalités-là qui sont ajoutées en plus. Et j'imagine qu'il y a du support. C'est ce que tu appelles probablement profession service, effectivement. Exactement. Et Entreprise Support. Et est-ce qu'on peut dire que vous avez aussi des committers sur la partie open source, qui est un peu le modèle de tous ces éditeurs, j'allais dire, nouvelle génération, qui sont basés sur des solutions open source? C'est ça, exactement. J'allais y venir parce qu'en fait, bien sûr, on a créé cette plateforme qui est disponible avec une licence commerciale, mais on reste commetteur de Kafka Open Source, donc 80% du code Kafka vient de chez nous.

38:34 Et également, Confluent Platform, on a aussi tout un ensemble de fonctionnalités qu'on a aussi open sourcées, qui sont disponibles gratuitement. Et c'est quelque chose qu'on voit très couramment chez nos clients, ces fonctionnalités qui peuvent être utilisées avec du Kafka open source, qui sont disponibles sous licence communautaire Confluent. Donc ça inclut bien sûr la validation de la donnée avec ce qu'on appelle le schéma registry, qui est si call DB, enfin sans rentrer dans le monde des... Mais voilà, les clients, les différents types de clients disponibles pour faire du PubSub, parce qu'à la base Kafka c'était que du Java fait par des architectes Java pour des développeurs Java, donc on n'avait que du client Java. Donc nous on apporte un ensemble de clients supplémentaires pour du .NET, pour du C. C++, Node.js, etc. Donc, il y a aussi cet aspect un peu… Enfin, voilà, c'est vraiment… Ça fait partie de l'ADN de Confluent, ce côté open source.

39:40 Donc, on a… On ne va pas aller trop en détail là-dessus parce que ce n'est pas le sujet du mot de l'heure d'aujourd'hui. Mais en revanche, c'est quand même intéressant parce que ça touche un peu le modèle d'affaires qu'il peut y avoir derrière des projets open source et comment est-ce que les gens qui commettent peuvent se rémunérer aussi avec ces solutions comme ça. Donc, voilà, c'est des gens qui commettent à 80% sur la solution de façon. Donc, c'est aussi normal qu'il y ait des professionnels de service qui soient payants par-dessus, etc. C'est une façon d'avoir aussi... De l'open source qui est financée et c'est pour le bien de toute la communauté. Exactement. Je vais faire une parenthèse là-dessus et je te laisse continuer. Oui, exactement. Le Professional Services, c'est vraiment pour aider pour la migration parce que je parlais tout à l'heure que ça permet une migration progressive. Donc, pour ça, vraiment, on a besoin, la plupart des clients ont besoin d'accompagnement pour migrer sur des architectures un peu plus modernes ou même pour les aider dans des déploiements un peu complexes, multi-DC, multi-régions, etc.

40:42 Donc, ça sert à ça, la partie Professional Services. Et puis, un ensemble de trainings qui sont soit gratuits, soit sur demande avec un instructeur qui peut être dédié. Et puis un dernier mot sur Confluent Cloud. Confluent Cloud, c'est vraiment Confluent Platform, mais disponible en mode SaaS, donc hébergé sur les trois principaux clouds qui sont AWS, GCP et Azure. Et c'est la façon la plus simple, bien sûr, de commencer à utiliser Capca, parce qu'en trois clics, on a un cluster de production prêt à être utilisé. Je ferme la parenthèse ici pour conclure et je vais revenir un peu à notre... d'usage métier de base qui était la gestion de flotte. Donc comment on vient simplifier ce problème que j'ai évoqué, vraiment le fait de collecter l'ensemble des données qui sont réparties sur les différents maillons de cette chaîne d'approvisionnement.

41:48 Très naturellement, comme le font la plupart de nos clients, c'est via les connecteurs, parce que vous avez plus de 200 connecteurs disponibles. Et donc, avec les connecteurs, sans avoir à écrire de code, on peut venir déverser les données dont on a besoin pour optimiser ce processus, tout simplement dans Kafka. Et puis, pour tout ce qui est données temps réel, donc par exemple la position du véhicule et d'autres types de sensors IoT qu'on peut avoir, ça, on peut les déverser par le biais des proxys MQTT et puis un connecteur MQTT également qui existe, qui permet de déverser ces données temps réel dans Kafka. Et puis, une fois qu'on a l'ensemble de ces données présentes dans le bus Kafka, Là, ça simplifie énormément les choses pour les applications concernées parce qu'en fait, on va accéder à l'ensemble de ces données de manière uniforme.

42:53 Si on n'avait pas ça, on aurait été obligé d'aller se connecter à une base de données Oracle d'un côté. peut-être des données qui proviennent d'un ERP bien spécifique, etc. Donc, ça serait extrêmement complexe. Rien que ce processus de collecter la donnée, là, en fait, tout est déjà présent. Et donc, Kafka devient la seule source de vérité. Puis, on a la garantie que la donnée la plus fraîche se trouve dans le bus. Et puis, on y accède très facilement avec le système PubSub. l'ensemble des applications qui relèvent de la logistique peuvent se connecter et consommer ces données de manière uniforme. Et puis, ça, c'est quelque chose qu'on retrouve de manière très classique dans ce cas d'usage métier. Souvent, on utilise MongoDB. MongoDB pour éventuellement faire des analyses, des traitements a posteriori sur des données historisées. Donc ça, c'est un grand classique. Pourquoi? Parce que souvent, les données qui sont stockées, parce que là, je parlais de position de véhicule, donc le format, ça va être du GeoJSON.

44:00 Et ça, c'est un format qui est compris par MongoDB et qui est capable, très facilement de faire des requêtes type géospatiale, etc., qui peuvent être très utiles dans ce contexte-là. Donc pour ça, j'ai préparé une petite démo. Je surveille juste le temps, Meriem. Je ne sais pas si... Ce que je te propose, Christian, si tu veux bien, c'est qu'on passe... La démo dure combien de temps ? Parce que c'est vrai qu'on a beaucoup... Je peux aller très vite. Oui, je peux aller très vite sur la démo. Comme ça, on prend le reste de Charles juste après. Et puis ensuite, s'il faut s'attarder un peu plus sur la démo, on le prendra à la fin? Oui, ok. Allons-y. Donc, juste rapidement, pour présenter la démo, j'ai utilisé Confluent Cloud parce que c'était le plus simple pour démarrer un cluster. Comme je n'ai pas une flotte de véhicules à ma disposition, j'ai créé une application. en Java Spring, une application producteur qui va simuler un ensemble de véhicules qui sont en déplacement sur Paris.

45:07 Et puis, une autre application de supervision. Donc ça, on peut imaginer par exemple que ça, c'est la destination d'un opérateur pour superviser l'ensemble des véhicules qui sont en train d'effectuer des livraisons. Et puis, il y a un connecteur MongoDB Sync que j'ai utilisé pour déverser les données qui sont présentes dans Confluent Cloud dans MongoDB Atlas et utiliser cette capacité de MongoDB de créer très rapidement des graphiques pour permettre des analyses a posteriori. Voilà, donc tout de suite, je vais vous montrer. Vous voyez toujours mon écran? Oui. Ok. On va voir. Allez, 30 secondes. Alors, je vais très rapidement lancer ces deux applications-là dont je vous ai parlé. L'application qui simule la position des véhicules et puis l'application qui sert d'interface de supervision pour...

46:11 Pour les opérateurs. Donc, on le rappelle, c'est la supervision de flotte de... De flotte de véhicules, voilà. Véhicules, exactement. Donc, pour vous dire, je l'ai développé pour les besoins de cette démo. Donc, ça a été quand même extrêmement simple de mettre ça en place. parce que j'avais Kafka derrière, donc j'avais un moyen très simple d'accéder aux données. Donc ça, c'est l'application de supervision. Donc là, pour l'instant, vous ne voyez aucun véhicule parce que là, je ne simule pas. Et donc là, si je lance l'application qui simule... Donc, c'est cet ensemble de véhicules qui est en déplacement sur Paris. Donc là, je l'utilise, ma box derrière, pour ceux qui connaissent, pour simuler des déplacements.

47:15 Donc là, vous voyez mes véhicules qui sont en train de se déplacer. En fait, ici, c'est apparu quasiment en temps réel. Alors, juste pour vous expliquer, quand j'ai créé mon cluster, je ne me suis pas rendu compte que je l'avais créé. C'était sur AWS mais je l'ai créé dans la région nord virginien donc pour vous dire que là les données vont quand même de chez moi jusqu'au cluster qui se trouve dans le nord virginien et puis ça revient donc c'est quand même extrêmement performant à Kafka de ce côté là il n'y a pas de doute et là par exemple si je vais simuler quelques petits événements Tu veux dire que le réseau va plus vite que la circulation des véhicules dans Paris aujourd'hui? Exactement. Et bien, c'est ça. Vous voyez les événements, je génère des aléas, etc. Ça arrive relativement rapidement.

48:17 Mais tout ça, juste pour vous dire que ça ne m'a pas pris beaucoup de temps. Bon, certes, j'ai un passé de développeur d'architectes logiciels, mais ce n'est quand même pas mon job à plein temps. Mais ça a été simple de développer ça, de mettre cette solution en place avec le Kafka. Excellent. Un grand merci, Christian. On te retrouve à la fin. Oui. Et je vais appeler notre troisième intervenant, Charles. Merci beaucoup, Christian. Merci. A tout à l'heure. Bonjour. Bonjour. Eh bien, écoute Charles, on a appris pas mal de choses sur Kafka, un peu plus sur les fonctionnalités confluentes, et on a vu un cas un peu théorique, mais je crois que toi, tu as un cas professionnel à nous présenter. Voilà, un cas pratique, oui. Alors, je vais partager mon écran. Parfait. Alors moi, je suis le CEO d'Affilize. Donc, je vais rapidement présenter ce que fait Affilize pour contextualiser un petit peu la suite de la présentation.

49:22 Donc, nous, on est une méta plateforme d'affiliation. Donc, qu'est-ce que l'affiliation? Je vais tout de suite passer un exemple de ce que c'est l'affiliation. L'affiliation, c'est en gros tous les tableaux de prix, les call to action que vous pouvez voir quand vous allez sur des sites, des guides d'achat type les numériques, etc. Donc nous, on permet à nos clients de gérer ces displays-là, entre autres en ingérant tous les catalogues marchands disponibles. On gère le display, les KPI, les performances, etc. Voilà ce que nous, on fait. Rapidement sur l'outil, permet à un média, que ce soit un média standard, que ce soit un influenceur, que ce soit un Instagrammeur, tout type de personnes qui ont des médias, de pouvoir gagner de l'argent avec l'affiliation. Et tout ça en nos codes, très facilement, sans aucune complexité. On intègre, nous, toutes les complexités liées à l'affiliation. Donc, qu'est-ce qui va nous concerner dans cette démo?

50:26 C'est la gestion du catalogue. Donc, il faut savoir que, je vais prendre l'exemple du catalogue français. Le catalogue français, donc l'ensemble des marchands français type Amazon, Fnac, Darty, qui font de l'affiliation, ça représente un catalogue de données d'environ... 150 millions d'offres. Donc, si on prend tout Amazon France, la FNAC, Darty, Cédis, Contre, AQT, NIMB, etc., nous, juste sur la France, on a 150 millions d'offres à gérer, à mettre à jour et à rendre disponibles dans l'outil. Donc, ces 150 millions d'offres, une fois qu'on les a mis dans un catalogue, ça représente environ 90 millions de produits. Donc la différence entre offre et produit, donc typiquement on peut avoir un iPhone disponible chez 15 marchands, donc on a 15 offres et on a un produit qui va être un type d'iPhone, par exemple le 14 Pro Max vers 256 Go. Donc nous, on a ces offres à mettre à jour tous les jours, tous les jours, tous les jours. Et sur les 150 millions d'offres, il y a environ 150 millions, en tout cas de mise à jour à traiter par jour pour le catalogue français.

51:32 Donc, quelles sont les problématiques liées à cette volumétrie ? À chaque fois qu'on importe une offre, Nous, il faut qu'on fasse de l'enrichissement en temps réel. C'est-à-dire que, je vais prendre l'exemple de l'iPhone 15 qui va arriver en fin d'année. La première fois qu'on va avoir une offre d'iPhone 15, est-ce que cette offre, on l'a déjà en base? Est-ce que cette offre est sur un produit qui existe déjà chez nous? Est-ce qu'on a déjà la fiche produit de l'iPhone 15? Si c'est une offre qu'on a déjà, est-ce que son stock a changé? Est-ce que son prix a changé? Comment je peux, au moment où l'offre arrive, automatiquement lui donner un niveau de structure de gamme? Par exemple, high-tech, smartphone, Apple, etc. Est-ce que j'ai téléchargé l'image de ce produit? Est-ce que j'ai téléchargé l'image de cette offre? Est-ce qu'elle a été supprimée? Etc. Donc voilà les problématiques qu'on avait. Avant de lancer Affilizz, on avait un produit qui gérait ça, mais juste pour la partie jeux vidéo, on avait les mêmes problématiques, mais à une échelle beaucoup plus petite.

52:36 On avait quelques millions de produits. Mis à jour moins régulièrement et du coup on avait des solutions standards qui étaient simplement des appels base de données. Mais dès qu'on passe à l'échelle, des solutions qui fonctionnent avec quelques centaines de milliers de produits ou quelques millions de produits, dès qu'on passe à 150 millions pour le marché français et potentiellement le milliard pour le marché français, le marché européen, du coup, ces solutions qui étaient acceptables à petit volume ne sont plus acceptables à gros volume. Donc, il y a différentes solutions. Est-ce qu'on peut optimiser les appels de bases de données pour gérer cette volumétrie? Donc, on a énormément de... L'offre doit être enrichie de plein de données. Au moment où elle arrive et au moment où elle va être en base, on peut se dire qu'on va faire une table, peut-être une table temporaire qui contient l'ensemble de ces données, je fais un appel en base de données, etc. Même si on a une super latence, qu'on est colocalisé à la base de données, qu'on a du ping, tout ce qu'on veut, on arrivera quand même à quelques millisecondes.

53:41 Donc, multiplié par le nombre d'événements, si on fait le calcul, c'est rapidement impossible. On peut se dire qu'on va utiliser du cache, on va cacher ça dans du Redis par exemple. Donc il y a toujours la notion d'appel réseau, peut-être si on a diminué la latence au niveau de la base, il y a toujours le réseau. Après, on peut se dire, du coup, je vais utiliser du cache local. Potentiellement, si on utilise du Redis, par exemple, on a du cache local. Mais du coup, ça pose la problématique de quand est-ce que je rafraîchis mon cache. En fait, on règle un problème, on va s'en créer un autre. Et on a le streaming. Donc, en fait, nous, on est parti sur du streaming pour justement avoir cet enrichissement. Temps réel et surtout au-delà du temps réel sans appel réseau. C'est-à-dire que quand mon offre elle va arriver dans mon système. Si je veux savoir si elle existe déjà, si je veux savoir si elle est déjà rattachée à un produit, si son stock a changé, il faut que tout cet enrichissement se fasse sans aucun appel réseau.

54:42 Parce que dès qu'on mène, si on a des temps de réseau à une milliseconde par exemple, multiplié par 500 millions, multiplié par le nombre de pays, ça devient ingérable. L'enrichissement, il est fait, il est colocalisé sur l'endroit où se trouve la donnée. Exactement, c'est tout ça. La force de 4K. L'enrichissement, en fait, il va être colocalisé. J'ai mon offre qui va arriver sur un pod, donc sur un pod Kubernetes qui va, par exemple, s'occuper de savoir si le produit est encore en stock ou si l'offre existe déjà. En fait, ça sera sur le site d'après. Cet enrichissement va être colocalisé, du coup, au pod qui est censé enrichir la donnée. Et on n'est pas dépendant de quel réseau, que ce soit en base de données ou que ce soit en cash. C'est vraiment Kafka qui nous permet, via Kafka Stream, de faire ça. Pourquoi on a utilisé Kafka et Kafka Stream? Dans notre solution, tout est basé sur les événements.

55:42 Il nous fallait envoyer ces événements. À ce stade-là, on pourrait choisir d'autres solutions, du PubSub, du RabbitMQ, etc. Il fallait qu'on ait un throughput assez élevé. On a énormément de données qui arrivent. Typiquement, si je prends un exemple de flux Amazon, les flux Amazon, rien qu'en France, c'est 50 millions de produits à mettre à jour 12 fois par jour. Donc, on a vraiment de gros volumes. Après, il y a aussi une notion de, est-ce que le bus qu'on va choisir, le bus d'événement qu'on va choisir, il est relativement disponible? Nous, on a de l'Astic Search, on a du Redis, on a du Mongo, on a du Rockset, on a plein de solutions. Est-ce que nativement, Kafka est pris en compte dans les connecteurs de source ou de sync? Donc ça, c'était nous, c'était vraiment très important. Si on est... utilise une solution qui est superbe, mais que derrière, on n'a aucun connecteur natif disponible sur les plateformes, nous, ça nous pose un problème. On voulait un SaaS, nous on ne gère aucun de nos hébergements, tout est opéré à chaque fois par un SaaS, et donc on voulait un SaaS avec beaucoup de support, un SaaS fiable,

56:51 On voulait une solution scalable, parce que quand on a lancé le produit Affilizz au début janvier, là on est déjà à 150 millions de produits, on voulait que ça suive la scalabilité du produit, la scalabilité du catalogue, et qu'on ne se retrouve pas à 6 mois, 1 an plus tard, de voir changer de système. Donc une solution complètement managée, vous, vous n'avez pas à vous occuper ni de la scalabilité, ni du monitoring, ni de quoi que ce soit. Alors, effectivement, il y a la scalabilité côté éditeur, mais nous, dans notre choix technique, une fois qu'on allait mettre en place cette solution-là, il faut qu'elle marche, en gros, nous, de zéro à 2 milliards de produits. Il ne faut pas qu'on ait changé de techno entre zéro et deux milliards de produits. Donc, des capacités de streaming. Donc là, déjà, une fois qu'on a inclus la contrainte des capacités de streaming, du coup, on a déjà pas mal de technologies, d'événements qui sont out. Et après, une large communauté, parce que du coup, c'est standard. Il faut derrière qu'il y ait du support, qu'il y ait de la communauté, qu'il y ait des échanges, etc.

57:54 Donc on a choisi Kafka pour toutes ces raisons-là. Donc là, je vais passer du coup dans... un use case très spécifique dans le cas des imports produits. Donc nous, on a des imports qui tournent, on a des offres qui arrivent en CSV, en JSON, absolument tout le temps, tout le temps, tout le temps, tout le temps. Et on doit à chaque fois enrichir cette offre de plein d'informations. Les stocks, les prix, la taxonomie, est-ce que j'ai téléchargé l'image? Tout un tas d'informations et surtout sans appel réseau. Je vais rajouter des petites notions techniques pour bien comprendre. Quand on publie dans Kafka, on publie dans ce qu'on appelle un topic. Les topics sont partitionnés. Et ce qui est clé, absolument clé dans Kafka, c'est la notion de partitionnement et la notion de clé. Pourquoi la notion de clé est importante? Parce qu'entre autres, elle va nous permettre de faire des jointures entre les topiques. Typiquement, imaginons que j'ai les offres Amazon qui arrivent.

58:58 Elles sont brutes, elles sont issues du catalogue Amazon. J'ai besoin de savoir, par exemple, si cette offre-là est déjà reliée à un catalogue. Et comment je fais? Du coup, j'ai dans Kafka un topic dans lequel je pousse les produits. Donc les produits, la clé, c'est EN plus local. Donc tous les produits français EN plus local, ils sont poussés dans Kafka. Et du coup, quand mon offre arrive, je peux faire une jointure exactement comme un live join en base de données, sauf que là, au lieu de... Faire un jointure entre des tables, je fais une jointure entre deux topiques. Et du coup, je joins mon offre qui a comme clé EAN et local avec mon topic qui a comme clé EAN et local. Et si jamais la jointure est succès, du coup, en résultat de la jointure, je vais avoir le produit auquel est rattaché l'offre. Donc, je peux faire des jointures. Idem pour les prix. Typiquement, si on passe à la suite, on a un topic…

1:00:00 Un topic offer state dans lequel, par exemple, on met le dernier état de stock, le dernier état de suppression, le dernier état de prix. Je fais une jointure, typiquement pareil, en temps réel, colocalisée au pod Kubernetes qui est en train de traiter cette offre. Je fais une jointure avec ce topic dans lequel j'ai tout mon dernier état computé de l'offre. Je fais une jointure et je sais instantanément, sans faire d'appel en base de données, est-ce que mon offre a été supprimée? Est-ce que le stock a changé? Est-ce que le prix a changé? Ou n'importe quel changement, je l'ai colocalisé sans aucune latence. Donc si je retourne en arrière et que je prends l'exemple du produit, si la jointure est succès, du coup j'enrichis l'offre. Si la jointure n'est pas succès, du coup je push dans un topic de création de produit et on voit que sans faire d'appel en base de données, j'ai pu soit enrichir mon offre, soit toucher dans un topic qui lui va venir créer mon produit. Une fois que le produit sera créé, il sera repoussé dans le topic de Products Topic.

1:01:04 Et la prochaine fois qu'une offre, qu'un MEN arrive, la jointure sera succès et l'enrichissement sera succès. Donc tout ça sans aucun appel en base de données. Et ainsi de suite, et ainsi de suite. Donc, la force de Kafka-Castrine, c'est cette capacité à faire des jointures entre les topiques pour faire de l'enrichissement temps réel. Par la suite, typiquement, on allait savoir est-ce que j'ai déjà téléchargé l'image pour mon offre? ou l'image pour mon produit, tout simplement, j'ai un topic dans lequel j'ai poussé des images. En clé, j'ai mis l'offre ID. J'ai qu'à faire une jointure entre le topic d'offre et le topic d'image, jointure par offer ID. Si c'est succès, j'ai déjà téléchargé. Si ce n'est pas succès, je balance dans un topic de téléchargement d'image. Et quand l'image est téléchargée, ça repousse dans le topic d'image. La prochaine fois, la jointure sera succès. Donc, on imagine comme ça, ainsi de suite. Et on imagine potentiellement tous les use cases où on a toutes nos données qui sont dans des topics et on n'a qu'à faire des jointures.

1:02:06 Et en fonction des jointures, on a l'enrichissement de la donnée où on pousse potentiellement dans d'autres topics pour déclencher d'autres traitements. Typiquement, pour rentrer un peu plus dans la technique, nous, l'enrichissement des 150 millions de produits, ça tourne avec quelques pods qu'on a entre 500 millicores et 1000 millicores. Le topic qui prend toutes les offres, qui prend les 500 millions, le pod, on a 5 pods de... Donc de 500 millicores, donc c'est tout petit pod, ça suffit à gérer ces volumes. Et donc, ça nous a permis de scale de 0 à 150 millions d'offres potentiellement, sans rajouter de pod, parce que c'était suffisamment performant. Donc peut-être que quand on sera à 200, 300, 400 millions, on rajoutera des pods, mais... On a réussi à... à gérer une grosse volumétrie, on n'a pas besoin de rajouter des pods et on gère ça avec finalement peu de pods, peu de CPU et peu de RAM.

1:03:11 Est-ce qu'il y a des questions sur ce slide-là? Après, j'en ai encore un. Alors, il n'y a pas de questions pour l'instant. Donc, on peut les prendre à la fin si tu veux. Continue. Parfait, parfait. Alors, on a plein, plein, plein d'autres use cases, nous, avec Kafka. Typiquement, il faut savoir que nous, nos clients, ça va être des médias, ça va être des influenceurs, ça va être des gens qui sont sur des Discord et qui potentiellement vont publier des bons plans. Donc, on a eu un use case il y a deux semaines. On a le livre, le guide de Harry Potter, Horrors Legacy qui est sorti. Et du coup, on a un de nos gros clients qui a publié ça sur Twitter. Et donc, nous, tous les clics potentiellement partent dans Kafka. Et on a un Kafka Stream qui est là pour potentiellement détecter les contenus chauds. Donc un contenu chaud, ça va être quelque chose qui va être en gros beaucoup cliqué sur une petite période de temps. Grâce à Kafka, en fait, on fait des agrégations sur des fenêtres de temps. Et on est capable, par exemple, de détecter sur 10 minutes, 30 minutes ou 1 heure, si un contenu est chaud, parce qu'on estime que s'il y a 10 000 clics sur une fenêtre de temps de 10 minutes

1:04:20 sur un produit ou sur un lien, du coup, c'est un contenu chaud, et ça, ça peut partir dans un process de redistribution de ce contenu chaud à différents clients. Donc ça, on peut faire ça. On fait ça grâce à Kafka Stream. Real-Time Analytics, encore une fois, nous, tout est dans Kafka. Et on synchronise ça avec une Rockset, ça permet de faire de l'analytique en temps réel. Donc, on envoie tout dans Rockset. Donc, il n'y a pas de traitement par batch. La donnée, elle part du clic. Donc, Kafka dans Rockset, agrégation temps réel. Et on a le clic qui est disponible sur le dashboard de nos utilisateurs. Une seconde. Deux secondes après avoir été réalisé. Et surtout sur Dashboard. Nous, il y a une grosse notion d'éviction de cash. Comme on gère les tableaux de prix pour tous nos clients, il faut imaginer que dès qu'un prix change, il faut instantanément, potentiellement, aller évicter le cash de tous les tableaux de prix. Donc, on peut en avoir potentiellement, on peut avoir peut-être 500 tableaux de prix sur lesquels on a une offre de l'iPhone 14 qui sont live chez nos clients.

1:05:28 Et il y a deux solutions. On pourrait dire, tiens, j'ai une offre qui arrive, je fais un appel en base de données, je récupère l'ensemble des tableaux de prix qui ont été computés et puis je reset le cache. Du coup, il y a cet appel en base de données que nous, on veut supprimer. Donc, on a simplement une jointure à faire entre l'offre qui a été mise à jour et un topic qui contient du coup les tableaux de prix, les widgets qui sont live chez nos clients. On fait une jointure, on a instantanément l'ensemble des widgets sur lesquels il faut éviter le cache et on évite le cache sans se faire d'appel en base de données. C'est passionnant. On a compris la force, en tout cas, de votre utilisation de Kafka, mais aussi de votre implémentation, parce que vous l'avez plutôt bien designé avec une possibilité de faire les bonnes jointures entre les bons topiques. Vous avez bien designé vos topiques. C'est aussi ça, probablement, qui donne la force de la solution. On va prendre des questions. Il y en a deux. Et on va peut-être en profiter.

1:06:30 Pour conclure aussi, je vais inviter Benjamin et Christian aussi à nous rejoindre. C'était ta dernière slide. Oui, c'est ma dernière slide. Après, c'était des use cases identiques. Et du coup, Charles, tu as une question de Louis qui nous demande, vu que Kafka est un produit open source, pourquoi ne pas le manager vous-même? Parce que Christian l'a dit, nous, typiquement, on a du Kafka, on a de l'Elastik, on a du Mongo. Par le passé, nous, on a déjà opéré nous-mêmes des clusters Mongo, des clusters Elastik, des clusters Coachbase. Ça peut vite devenir très, très compliqué à manager. Dans l'équipe, il faudrait qu'on ait un architecte Mongo, qu'on ait un architecte Kafka. Aucun intérêt. Et surtout, c'est qu'après, potentiellement, la Kafka, on est en multizone. Si on veut passer en multirégion, ça veut dire qu'à moins qu'on ait quelqu'un de confluent, le niveau de compétence de quelqu'un de confluent et qui peut nous garantir un SRA 99.9 comme confluent chez nous, si on n'est pas capable de se trouver ce profil,

1:07:36 et je pense même que si on est capable de se trouver ce profil, je ne suis même pas sûr que ce soit rentable pour nous. Donc, pour moi, il y a... Après, quand c'est des technos qui sont très compliqués à opérer, ça ne vaut pas le coup. Si on a, alors sans caricaturer, si on a juste un post-grès qui n'est pas répliqué, qui n'est pas cher derrière du tout, la question se pose. Par contre, dès qu'on tombe sur des choses aussi complexes que ça opérait, Je crois que moi, ça va. Hyper clair, hyper clair. Merci Charles. Autre question de Bilal. Bilal, très actif aujourd'hui. Merci beaucoup d'avoir été avec nous. Comment Kafka distingue entre les pods? Comment Kafka choisit un pod en particulier pour l'enrichissement? Très bonne question. Alors, si je prends l'exemple du topic d'offre, nous, le topic d'offre, on l'a dimensionné avec… Christian, si j'ai des conneries, tu me coupes. Nous, on a dimensionné, donc on a fait un sizing des topics, et les topics, ils ont des partitions. Donc, nous, le topic offer, typiquement, il a 60 partitions. On a 5 pods, et en fait, au démarrage des 5 pods qui consument le topic offer et qui ont un consumer group, le consumer group, par exemple, offer,

1:08:43 chaque consommateur groupe et chaque pod se voit attribuer une liste de partitions que lui va gérer. Ça veut dire que si j'ai 5 pods et 60 partitions, le pod 1, alors je vais dire 6 pods par exemple et 60 partitions, le pod 1 il va gérer les partitions de 1 à 10, l'autre de 20 à 30, etc. Et après tu as tout un mécanisme de rebalance des partitions s'il y a des soucis, selon ta stratégie de mise à jour de tes pods, si tu mets par exemple à jour tes pods un par un, tu auras des systèmes de rebalance pendant qu'il y en a un qui n'est pas là, potentiellement c'est l'autre qui va prendre le relais, potentiellement nous ce qu'on fait c'est qu'on arrête tous les pods d'un coup et on les remonte tous d'un coup parce qu'il n'y a aucun intérêt, et du coup il y a un système d'attribution des partitions en fonction du nombre de pods qu'il y a dans un consommateur. Donc c'est comme ça que le routage se fait. C'est bon, Christian, je peux me détisser? C'est parfaitement ça. C'est tout fait via les consumer groups. Et si on rentre un peu dans le détail, le groupe coordinateur, ce sont des mécanismes qui sont nativement implémentés dans Kafka qui permettent à un ensemble de consommateurs qui sont

1:09:49 dans un même groupe de partager plusieurs partitions. Super. Écoute, Charles, c'était passionnant. Franchement, j'ai adoré ton reste. Un grand merci. Très, très dédé. détaillé, très technique. Et en fait, voilà, ça sent le vécu. Donc, hyper bien. Merci beaucoup. Merci, Christian, pour les éclairages que tu nous as donnés. Benjamin, merci beaucoup pour votre présence. Super. J'ai passé un excellent moment avec vous. J'ai passé un excellent moment avec vous toutes et tous. Restez avec nous. On va aller... Passez un petit moment sur l'étape de networking. N'hésitez pas à venir. Franchement, c'est un sujet qu'on n'a pas épuisé. Il y a un milliard de trucs à dire encore. Merci beaucoup. Donc, restez avec nous. On se retrouve tout de suite sur les tables de networking. Merci encore à nos intervenants. C'était vraiment d'un très, très bon niveau. Merci beaucoup. Merci.