Tips and tricks for an efficient real time data streaming platform !

0:12 Bonjour à tous et à toutes. A tous, en fait pas toutes, mais pas grave. C'est comme ça. Je m'appelle Damien, je suis avec mes collègues Nice. Et en fait, on est des... Enfin, très peu de voix, c'est pas confluent. Qui est un éditeur de logiciels spécialisé dans des systèmes de gestion de données en temps réel. Et en fait, on est des architectes techniques qui accompagnent justement nos clients sur leurs problématiques, soit de migration, soit de gestion de données en temps réel. Et aujourd'hui, on avait envie de faire un petit talk sur deux sujets qui nous sont chers. Le premier, c'est pourquoi faire du temps réel, pourquoi ne pas faire juste du batch comme on pouvait le faire il y a 5 ans, il y a 10 ans. Et une deuxième partie qui va être plutôt comment le faire de manière efficiente, qui est en fait bien plus compliquée. Donc on peut se poser la question, pourquoi ne pas faire juste du batch? Si vous avez plus que 30-40 ans, vous avez certainement travaillé avec pas mal de systèmes très orientés batch. Moi j'en ai fait beaucoup dans ma vie, j'ai un peu un petit SD dessus, j'en ai un peu marre de faire du batch, j'ai eu beaucoup de problèmes avec.

1:17 Les trucs un peu classiques où tu crées quelque chose et puis il faut que tu attendes deux jours avant de le voir dans un écran, c'est assez chiant. Mais d'une manière générale, le batch qu'on aime, qu'on n'aime pas, qu'on ait subi ça dans sa jeunesse ou pas, il faut bien comprendre que les systèmes orientés batch ont des limitations. Des limitations de métier, pour la simple raison et de manière assez naturelle, un système orienté batch ne pourra jamais couvrir des besoins de temps réel. Tu ne vas pas faire un système de détection de fraude, de paiement en temps réel, tu ne vas pas faire un système d'optimisation, de personnalisation en temps réel avec des batchs. C'est antinomique, c'est temps réel, tu ne peux pas faire du batch, tu ne peux pas couvrir ce genre de besoin de métier avec des solutions orientées batch. Et d'une manière générale, même si on peut faire certains use cases en batch, il faut bien comprendre que plus on attend pour traiter la donnée, plus cette donnée perd de la valeur. Et ça, c'est vrai pour beaucoup de use cases. L'exemple un peu, on va dire, typique qu'on peut donner, ce serait tout ce qui va être investissement en salle de marché. Si Elon Musk tweet Tesla fait faillite, si tu la prends le lendemain, ça n'a pas du tout le même impact que si tu la prends une milliseconde après qu'il tweet et tu la prends avant tes compétiteurs.

2:21 Et ça c'est vrai, donc ça c'est un peu l'exemple typique des salles de marché, mais c'est vrai pour beaucoup en réalité de use case. Tu as un retailer, tu as un client qui annule sa commande, si tu arrives à découvrir ça et à publier cette information à toutes les applications en temps réel, ça se trouve tu vas arriver à optimiser ton système pour ne pas l'envoyer. Alors que si tu l'apportes demain, que tu as le batch de nuit qui fait son plan de déploiement pour les usines, ça se trouve le paquet est déjà envoyé et ça le paquet va faire un aller-retour, ça va être de l'argent perdu. Donc d'un point de vue métier, les batchs vont avoir des limitations et peuvent également coûter cher. Et d'une manière aussi plus technique, les batchs peuvent poser pas mal de soucis, ça peut vite devenir un bordel. Par exemple, rien que cette semaine, je travaillais avec un client, J'avais besoin d'accéder à leur console cloud. Ils m'ont rajouté dans le groupe Azure AD, j'étais super content. Puis après, ils m'ont gentiment dit, écoute, tu auras les droits dans 24 heures, le badge tourne la nuit. Bon, cool, mais moi j'en ai besoin maintenant. J'ai perdu 24 heures, sauf que moi j'interviens seulement la semaine prochaine. Donc on a perdu quasiment une semaine. Ou pareil, j'avais un autre client assez récemment, il faisait la détection d'anomalies en batch, très bien.

3:24 Ce problème c'est que c'était des requêtes SQL très compliquées, non optimisables, et ça c'était des requêtes qu'ils avaient besoin de faire, c'était pas pour le plaisir. Le problème c'est que quand le batch tournait, la base de données perdait énormément en performance, ça impactait le front-end. Ça a impacté le front-end et grosso modo pour que le batch tournait, les clients n'avaient pas du tout une bonne expérience utilisateur sur le site web, soit le site web totalement bugué et les clients ne pouvaient pas faire de commande d'achat. Juste parce qu'il y avait un batch de détection d'anomalies qui utilisait la même base de données. Donc c'est vrai que les systèmes orientés batch sont peut-être une solution un peu naturelle ou facile, c'est ça qu'on a l'habitude de faire, surtout pour les gens qui sont dans le métier depuis quelques temps, mais il faut bien comprendre des limitations. Et de la même manière, les batchs ont tendance à mal vieillir, c'est-à-dire qu'on utilise souvent les batchs pour les questions d'intégration, et puis au final, les besoins évoluent. À l'année 2, à l'année 3, on a besoin de nouveaux systèmes d'intégration, on crée de nouveaux batchs. On lance le premier batch à 10h du soir en disant c'est bon, après on s'aperçoit qu'il faut un deuxième job de transformation, donc on le lance à 11h en disant allez, une heure entre les deux, ça passe.

4:28 Et après 10 ans, tu te retrouves avec... Et le huitième batch, c'est à 6h du matin et tu commences un peu à transpirer en disant qu'est-ce qui se passe. Et si quelque chose plante, tu as quelqu'un d'astreinte qui est réveillé pour s'assurer que le plan d'exécution marche bien. Donc c'est vrai que les batchs, grosso modo, ont un peu ce problème-là. Et cela fait que, grosso modo, les architectures orientées batch, aujourd'hui, posent pas mal de problèmes, à la fois en termes de couverture de besoins métiers, et également techniques. Ils ont tendance à mal scaler, à avoir des conséquences niveau coût, et également à avoir cette perte de données qui impacte en réalité. votre métier. Alors pourquoi est-ce qu'on a besoin de s'embêter avec faire du data streaming et du temps réel? Tu me dis, un petit signe fait que hop, discret. Du coup, je pense qu'on est tous aujourd'hui confrontés à être des utilisateurs de plein de services qui fonctionnent en temps réel, sur lesquels on peut effectivement voir de la valeur. Donc typiquement, je commande mon VTC, je suis content de voir quand est-ce qu'il arrive, de pouvoir traquer en temps réel ça.

5:36 Et je pense que globalement, dans les dix dernières années, on a vraiment vu une accélération sur, en gros, tous ces use cases historiques qui arrivaient. Ces entreprises, des nouvelles entreprises, typiquement les néobanques par exemple, qui arrivaient directement avec cette approche data streaming. Du coup qui ont un peu révolutionné le banking et donc du coup tout ça fait que ça met en avant du coup le besoin de faire du temps L. Tu me fais un petit... Donc nous, en tant qu'utilisateurs, nos besoins évoluent. Mais il faut aussi que cette évolution de besoins-là s'associe avec une évolution des systèmes d'information. de nos infrastructures, etc. Donc globalement, dans cette démarche de venir mettre du temps réel dans les systèmes d'information, il y a une grosse techno qui se dégage, qui s'appelle Apache Kafka.

6:48 Est-ce que Apache Kafka, ça parle à des gens ici? Tout le monde? Quasiment tout le monde, oui. Très bien, parfait. Donc nous, forcément, vous allez vous dire, on est un petit peu biaisé, parce qu'on a été fondé par les créateurs d'Apache Kafka. Mais globalement, sur le marché, il y a plein d'autres acteurs très connus, du style Netflix, Uber, plein de systèmes financiers également, qui, eux, sont basés sur Kafka. Il y a environ plus de 80% des entreprises top 500 au monde qui disent aujourd'hui utiliser Kafka. Donc on va essayer un petit peu de voir qu'est-ce qui fait une plateforme de data streaming au-delà de juste Kafka. Donc en gros, nous, au quotidien, on accompagne nos clients à déployer un système Kafka. Et généralement, comment est-ce que ça démarre? C'est des petites initiatives dans des groupes, des organisations, qui vont venir déployer leur petit cluster Kafka, faire leur use case en réel, tout le monde est content.

7:57 Et très vite, on voit se créer plein de petits silos comme ça, de temps réel. Et nous, ce qu'on essaye de faire, et ce pourquoi les clients nous sollicitent, c'est finalement tous ces petits silos, au bout d'un an, ils ont besoin de venir s'interconnecter à ce qu'on appelle une plateforme de data streaming, qui est plus que juste... À Vachikavka. Donc ici, nous, avec Damien, on a fait l'exercice sur cette slide d'essayer de vous donner un petit peu des clés sur, au-delà de Abadji Kafka, quel est un petit peu tout l'écosystème qu'il faut venir construire autour de Kafka pour pouvoir réellement assurer... Pour avoir une plateforme de data streaming qui puisse vous permettre couvrir vos use case et voilà. C'est vrai qu'on parle beaucoup de Kafka, mais Kafka c'est vraiment un broker de messages.

8:58 C'est ce qu'on appelle un log distribué, donc ça permet juste finalement de produire et de consommer des messages. Et en fait, quand on parle de Kafka, il y a tout un écosystème qui se forme au souple, qui n'est pas en fait juste Kafka. Il va y avoir du Kafka Connect, du Kafka Stream, et cette écosystème existe pour la simple raison, c'est que pour faire une plateforme de gestion de temps réel, il n'y a pas que la partie stockage, il y a d'autres aspects. Donc naturellement, il y a une partie processing pour traiter les messages en temps réel. Donc là, on va parler surtout de Kafka Streams, de Flink, de ce type de solution. Il y a une partie connectivité, parce qu'une fois qu'on a traité un message en temps réel, une fois qu'on l'a peut-être dénormalisé, enrichi, agrégé pour compter ou autre, certainement le résultat, on a envie de le pousser quelque part, dans une base de données, un data warehouse, un Snowflake, un MongoDB, je ne sais quoi. Donc il y a toute une partie intégration et collectivité avec des systèmes tiers, ça peut être aussi des applications de métier type Salesforce. Donc ça, toute cette partie-là, on va dire, il y a une partie sécurité, tout ça, ça paraît assez logique, les autres systèmes ont à peu près les mêmes composants, de la connectivité, du process, de la sécurité. Mais ici, il y a également, on va dire, de grosses différences par rapport à des...

10:00 des technologies d'intégration, on va dire, plus historiques. Quand je dis technologie d'intégration historique, je pense notamment à des systèmes SOA, ESB, EAI. Juste par curiosité, qui a déjà travaillé avec un ESB ici? C'est quoi ton expérience avec l'ESB par curiosité? Moi, j'ai dû maintenir des USB, c'est des solutions d'intégration d'entreprise. Je peux vous assurer que ce n'est pas un job fun. C'est un type de job où, en fait, quand tout marche, personne ne sait que tu existes. Par contre, le jour où ça tombe, tout le monde t'appelle, le PDG connaît ton nom et tu as intérêt à mettre ton téléphone en silencieux, sinon tu ne dors pas. Donc ouais, ce type de solution, c'est une solution critique, et c'est vrai que ce type de solution d'intégration est aussi très centralisé. C'est-à-dire qu'historiquement, tu avais une équipe, c'est eux qui font tous les jobs d'intégration pour toute l'organisation. Et c'est vrai que le problème de l'ESB, c'est justement cette centralisation. Que le fait que ce soit totalement centralisé, l'intégration, fait que ça devient très très vite le bottleneck pour n'importe quelle organisation.

11:01 Et dès qu'il y a un nouveau projet, ils ont besoin de données, ils ont besoin d'intégration, et donc ils ont une dépendance à cette équipe, à ce projet-là, et bien sûr cette équipe-là a sa propre backlog qui peut ne pas être alignée avec la backlog projet. Donc vous savez que si vous avez déjà fait des projets USB-SOA, c'est vraiment cette centralisation qui, on a dit, a vraiment impacté ce pattern et qui fait qu'aujourd'hui, ce n'est plus vraiment à la mode. Et on va dire, pour ne pas faire de centralisation, c'est simple. Et donc, dans Kafka, dans les plateformes de temps réel, on ne voulait pas répliquer ce problème. Donc, comment ne pas centraliser? C'est simple. Il faut décentraliser. Ça paraît assez simple. Par contre, si on décentralise, il y a d'autres problèmes qui arrivent. Par exemple, on peut prendre l'extrême, où tu donnes l'accès en écriture à toutes les applications de ton organisation. Tout le monde a accès en écriture à tout. Vous pouvez faire ça. Il y a des clients qui ont essayé. C'est assez rigolo. C'est assez rigolo quand tu es à l'extérieur de la boîte, quand tu es à l'intérieur, que tu es architecte. C'est moins rigolo parce qu'après quelques années, c'est un vrai Far West. Tu as des mecs qui ont poussé des MP4, tu as un mec qui a poussé ses photos de mariage, tu as de l'ubidique, du CSV, du JSON, du protobuf, tu n'as aucune convention de nommage.

12:01 C'est très dur à exploiter la donnée. Donc ça, c'est vraiment un extrême de donner l'accès en écriture en pro à tous tes projets. Ça a des limitations. L'autre extrême, ce serait de tout centraliser, mais si on centralise, on retrouve dans le même problème qu'on a avec les ESB. Donc il y a un équilibre à trouver entre je centralise et je décentralise tout. Donc il faut une solution un peu ici gris. Et ça implique que dans ce type de système, tu as des pratiques de gouvernance qui peuvent être assez nouvelles par rapport à des systèmes traditionnels type USB, ETL. Et ces pratiques de gouvernance sont ici importantes. Et de la même manière qu'il y aura des pratiques de gouvernance, il y aura de nouvelles problématiques ou de nouveaux challenges qui vont être différents. Par exemple, il y aura des pratiques de scalabilité. Si vous êtes un retailer, si vous êtes une boîte qui avait des variations d'activités très fortes, quand vous faites du temps réel, il va falloir potentiellement s'adapter en permanence. Et si vous êtes un retailer, en ce moment, on arrive dans les périodes de Black Friday, Noël, il y a une activité qui peut être 10 fois, 20 fois supérieure par rapport à un mardi 23 mars. le soir, on a 15 heures. Donc on peut se demander pourquoi et quels sont les points de difficulté de ce type de plateforme, qui est en fait tout un écosystème.

13:10 Le premier, c'est bien sûr ces pratiques de gouvernance, de scalabilité que je viens d'en parler, mais d'une manière générale, comme je vous disais, une plateforme de gestion de temps réel, ce n'est pas juste Kafka, c'est tout un écosystème, donc ça veut dire qu'il y a plusieurs en réalité composants. De manière assez classique, on va parler de Kafka, qui va être le cœur, mais il y aura également, très généralement, il y a ce qui m'a enregistré, pour définir justement le modèle de données, il y aura peut-être du Kafka Connect, du Kafka Streams, du KSQLDB, du Flink, et tout ça, ce sont en fait des systèmes distribués. Et si vous avez déjà fait pas mal de systèmes distribués dans le passé, vous savez que ce ne sont pas forcément les systèmes les plus faciles à maintenir. Et chacun de ces systèmes, vous allez devoir les comprendre, vous allez devoir les sécuriser, les monitorer, les gérer, les mettre à jour. Chacun de ces systèmes est généralement, on va dire, une politique de support de deux ans. C'est le plus classique chez les éditeurs logiciels de dire on supporte deux ans n'importe quel système. Donc ça implique que chaque année, il faut les mettre à jour. Donc même si vous les déployez, il faut toujours le faire. Donc ça, ça a des implications pour votre organisation, pour la plupart des organisations.

14:13 Ça a des implications surtout sur combien ça va coûter de gérer cette plateforme. Et on va dire de manière assez naturelle et intuitive, il va y avoir des personnes qui vont devoir avoir du temps alloué pour gérer ces personnes, enfin pour ces nouveaux clusters, donc ça aura bien sûr un coût humain, il va falloir du temps. pour les gérer. Il y aura bien sûr un coût hardware, parce qu'il faudra des VM, du réseau, du stockage. Ces deux-là sont assez évidents, coût humain, coût hardware. Ils sont également liés, pour la simple raison que si vous voulez optimiser vos coûts hardware, certainement, il va falloir rajouter plus d'intelligence. Parler d'autoscannabilité, ajuster, vérifier différents types de disques. Mais pour rajouter cette intelligence, vous allez avoir besoin de personnes. Et donc si vous avez besoin de personnes, ça va augmenter le coût humain. Ou alors il va falloir besoin de plus d'outils ou plus de formations. pour que les personnes soient plus à l'aise sur les différents composants de la technologie. Donc finalement, pour optimiser les coûts hardware, ça va naturellement augmenter les coûts humains. Et si à l'opposé, la personne qui gère la plateforme n'a pas du tout le temps, elle doit gérer six systèmes en parallèle, elle est totalement débordée, certainement on va devoir surprovisionner le cluster, juste au cas où, parce qu'en réalité on n'a pas fait de bon sizing, on ne sait pas vraiment qu'est-ce qui va se passer.

15:20 Donc ces deux coûts sont plus ou moins, on va dire, traditionnels, classiques, attendus, assez obvious. Mais le troisième coût, qui est généralement le coût principal, c'est juste la gestion des risques. Ce type de plateforme, donc ce type de plateforme de gestion de données en temps réel, ça devient très rapidement, que vous le vouliez ou non, une plateforme d'intégration. C'est-à-dire que c'est une plateforme qui est utilisée pour pouvoir communiquer vos différentes applications ensemble. Et en fait, dès que vous avez par exemple une approche micro-service, dès que vous utilisez des services managés, dès que vous faites de la synchronisation de bases de données, il y a de fortes chances que ça passe par Kafka, que vous voulez ou non. Pour la simple raison, c'est dès qu'on parle de Event-Driven Architecture, qui est un pattern de synchronisation de micro-services, il faut un bus de données. Et si tu tapes sur n'importe quel site web, plus de données, microservices, architecture, il va te dire Kafka, Kafka, Kafka. Et donc vite, ça va devenir un système d'intégration, pour connecter les données entre plusieurs applications. Et généralement, ça va être utilisé à peu près partout au sein d'une organisation. Qu'on le veuille ou qu'on ne le veuille pas, c'est un peu le chemin naturel que ça prend. Et par exemple, nous, on a beaucoup de clients, quasiment tous, qui utilisent ce type de plateforme pour gérer les paiements au sein de leur système.

16:25 Ça veut dire que, que vous soyez une banque, un retailer, un site web, à un moment qu'on fait un paiement, Il y a besoin de différentes vérifications. Il faut un bus de données pour s'assurer que ça passe bien les messages. C'est souvent Kafka. C'est-à-dire que si vous avez un problème dans votre cluster, votre cluster est down, il y a de fortes chances que les gens ne puissent pas payer, grosso modo. Et si les gens ne peuvent pas payer et qu'on est un vendredi soir de Black Friday, ça peut avoir un impact métier très important. Si vous êtes une banque et que vos paiements en carte bleue sont fusés, pareil, là, votre téléphone va sonner, très probablement. Ils ne vont pas être contents. Il faut bien comprendre que ce genre de plateforme devient très vite critique. Il y a une composante risque qui a bien sûr un coût. La gestion du risque, c'est une question, encore une fois, de coût. Donc comment construire cette plateforme de façon efficace? Je pense que vous nous voyez un petit peu venir. Donc on va se focaliser dans un premier temps sur Kafka. Donc on peut décider typiquement de prendre le projet Apache Kafka, de le déployer sur son infrastructure.

17:30 C'est ce que je faisais avant de venir travailler pour Confluent. Au début, c'est très bien, ça marche relativement bien, c'est stable. Par contre, dès qu'il faut faire des opérations de maintenance, donc typiquement monter de version, changer les certificats, extend la capacité du cluster, etc. Ça devient tout de suite beaucoup plus compliqué. Ensuite, il y a certains acteurs qui proposent des services Kafka self-managed, donc par les clients, qui eux rajoutent un petit peu d'abstraction, qui vont rendre potentiellement le déploiement plus facile, mais toujours avec certaines opérations manuelles qui doivent être effectuées. Typiquement aussi, encore les upgrades, il faut se les taper. Et enfin, il y a les services fully managed. Donc là, c'est typiquement un service sur lequel je peux avoir de la scalabilité, un stockage illimité, pas besoin de s'occuper de l'infrastructure.

18:36 Je pense qu'on est tous d'accord globalement pour dire qu'aujourd'hui, un petit peu dans l'IT, une des tendances qu'on voit, c'est du coup, on a démarré un petit peu dans un monde où on achetait son software, on achetait son infrastructure, on utilisait des outils comme IBM, Oracle. Apache Kafka. Ensuite, on est passé dans un monde un petit peu différent dans lequel on avait tendance plutôt à déployer des services hostés toujours, mais plus packagés. Et enfin, aujourd'hui, on est plutôt dans un monde où les organisations préfèrent se focaliser sur l'essence de leur métier et utiliser des services fully managed comme Databricks, Snowflake, MongoDB Atlas et Confluent Cloud. Donc, pour faire un service concrètement fully managed, qu'est-ce qui s'est passé chez nous à Confluent ? Donc, on a mis l'accent sur trois points essentiels.

19:39 C'est le rendre, ce Apache Kafka, cloud natif, le rendre disponible partout, et fournir une plateforme complète, donc en y incluant tout l'écosystème dont Damien a parlé juste avant. Cloud Native. Non, non. Cloud natif. Qu'est-ce que ça veut dire ? Ça veut dire adopter les contraintes des différents cloud providers et en même temps les avantages, c'est-à-dire pouvoir s'adosser à des services, typiquement du stockage, pouvoir s'adosser à un service comme S3 par exemple dans la WS, pouvoir s'adosser à des technos plus élastiques du style des Kubernetes Managed, des choses comme ça. Disponible partout, ça veut dire un service qui va être disponible sur les principaux cloud, les plus gros cloud providers, mais aussi quand même d'avoir une patte aussi dans potentiellement des infrastructures on-premise.

20:41 Je pense que le jour où il y aura des organisations qui n'auront plus de mainframe et qui ne traiteront plus des informations cruciales, ce n'est pas prêt d'arriver tout de suite. Donc c'est important aussi d'avoir cette capacité de pouvoir être déployé on-premise. Et Complete, c'est pouvoir justement fournir tout l'outillage et tout l'écosystème qui va permettre de transformer Apache Kafka en réellement une plateforme de data streaming. Donc chez nous, globalement, le travail a été fait sur différents axes. Donc il y a rendre Kafka serverless. Donc typiquement aujourd'hui quand on parle à quelqu'un de S3, On s'en fiche derrière de l'infrastructure qui est associée, on s'en fiche de la taille des disques, la gestion de l'infrastructure, les risques associés à ça. On veut juste faire du stockage.

21:42 L'ambition ici, c'était de faire la même chose avec Kafka, c'est-à-dire qu'on veut que le client s'en fiche de gérer son infrastructure, de sizer, et on veut que ça soit une solution complètement serverless. Ensuite, élastique, on a besoin effectivement de payer uniquement pour ce qu'on va consommer. Donc c'est d'avoir un service qui va me permettre potentiellement d'absorber ma croissance naturelle ou alors des pics de charges typiquement pour le Black Friday ou des choses comme ça. Et après, il y a aussi une composante importante, c'est d'avoir découplé. Historiquement, Apache Kafka, ça a été designé vraiment pour être déployé sur du bare metal plutôt. C'est-à-dire que c'est un système qui fait directement le parallèle entre le réseau et le disque. Et qui est très basé là-dessus. Et donc là-dessus, il y a eu un gros travail sur le découplage des différents composants de la batch Kafka pour pouvoir...

22:43 Faire en sorte que le stockage, le compute et le réseau soient complètement décorrélés et qu'ils puissent scaler les uns indépendamment des autres. Et après, il y a la partie networking. Donc je ne sais pas si vous avez déjà essayé d'interconnecter des cloud providers ensemble, etc. Mais ça peut vite être un cauchemar. Et du coup, nous, on a rajouté aussi une abstraction réseau autour de ce tabachik Kafka pour pouvoir faire en sorte que les clusters puissent se connecter, parler entre les différents cloud providers, parler avec la partie on-premise également. Donc tout ça, on a en gros réimaginé Kafka pour le faire tourner dans le cloud. C'est ce qu'on appelle le Cora Engine. C'est quelque chose sur lequel on a communiqué que relativement récemment. Et ce core engine, grosso modo, il s'articule autour de ces quatre points très importants. C'est le fait qu'il soit élastique, résilient, performant et cost-efficient.

23:46 Un autre petit point que je voulais rajouter, donc ça c'est par rapport à rendre la plateforme complete, c'est du coup, on a parlé de Apache Kafka, Cora c'est la réponse en gros pour rendre ce Apache Kafka natif, cloud natif, mais autour de ça, On a rajouté aussi tous les outillages. Après, ça ne veut pas dire que vous ne devez rien construire autour. Toujours construire des choses. Mais on a essayé de faciliter la vie de nos clients en rajoutant des composants d'interconnexion entre différents systèmes. La partie gouvernance... Dont Damien a parlé, qui est très importante, qui va permettre de pouvoir gérer les schémas, de pouvoir permettre aux équipes de collaborer entre elles, de pouvoir gérer plus facilement les droits d'accès pour avoir cette décentralisation. Et la partie processing, c'est vraiment pour faire de la transformation en temps réel, qui peut être fait par exemple avec Flink. Et donc on peut se dire, ok, là c'est la théorie, c'est joli, mais concrètement, comment ça se déroule ?

24:52 Je ne vais pas faire de démo, parce que la démo, c'est toujours l'effet démo, ça fait transpirer, donc j'ai fait des vidéos. C'est plus simple, plus safe pour moi, sauf que les vidéos ne marchent pas sur PowerPoint. Ça a l'air vraiment... C'est pas top. Mais imaginons finalement un cas concret où tu aurais deux boîtes avec deux architectes différents, Tom et Anne, qui doivent justement déployer une plateforme en temps réel. Que ce soit pour de l'intégration, pour faire du processing en temps réel, qu'importe, ils ont juste des besoins, ils ont besoin de mettre à disposition cette plateforme. Et Tom et Anne ont pris deux approches différentes. Tom a décidé de tout déployer lui-même. Donc il prend des VM sur EC2, un premise, qu'importe, mais en tout cas il déploie tout lui-même. Anne, à l'opposé, a décidé de prendre justement Confluent Cloud, une plateforme qui est cloud native et où on peut avoir des clusters rapidement. La conséquence, c'est que Tom va certainement passer beaucoup de temps, et notamment la première année, à déployer l'intégralité des composants. Comme justement Nice l'a dit, Kafka c'est tout un écosystème, donc on commence toujours avec le cœur, Kafka, mais il n'y a pas que ça. Il y a du Kafka Connect, du Skim et ma registrie, du REST Proxy, du KSCO DB et autres.

25:56 Et donc Tom va devoir déployer, automatiser, peut-être avec du Onsibon, il va devoir ensuite monitorer, c'est remettre une couche d'autorisation, créer tous les systèmes de gouvernance, peut-être qu'il va avoir besoin de créer son propre système de cartographie des flux. En tout cas, c'est sûr que la première année, il va passer beaucoup de temps à gérer tout ça. Et l'année suivante, il y aura de nouveaux use cases, il y aura des mises à jour à faire, et il va quand même passer certainement 60 à 80% de son temps sur la partie infrastructure. Anne, à l'opposé, elle a pris Conflot Cloud, donc c'est un peu différent pour elle. Si elle veut déployer un cluster, c'est juste... soit quelques lignes de Terraform. Là, je vous présente la UI parce que c'est plus joli, la UI, ça vend du rêve. Mais dans la vraie vie, tu as envie d'automatiser en Terraform. Tu as envie de faire de l'infrastructure à ce que c'est quand même plus sympa. Mais en tout cas, pour Aya, Anne, c'est beaucoup plus simple de déployer. Et ce cluster sera monitoré, sécurisé. Tu ne peux pas désactiver TLS, tu ne peux pas désactiver l'encryption at rest. Tu es obligé d'avoir des mécanismes d'authentification et d'autorisation. Et ça, pour l'intégrité des composants. Donc, elle peut avoir un cluster prêt à l'utilisation en quelques minutes.

26:57 Je ne dis pas qu'il n'y a pas de boulot derrière. En tout cas, elle pourrait avoir un premier cluster qui peut être disponible pour les projets et les applications vraiment en quelques minutes. Et comme disait Nice, c'est tout un écosystème. Par exemple, si un projet avec Anne a besoin de se connecter à un 16 forces, récupérer de la donnée d'une base de données, la pousser dans MongoDB Atlas ou la pousser dans 16 forces, Il y a plein de systèmes de connectivité déjà existants, ce qu'on appelle des connecteurs. Et donc, les développeurs peuvent juste aller sur le portail de connecteurs et dire, j'aimerais bien pousser la donnée dans mon GoDB Atlas. Et en faisant juste un petit fichier YAML, JSON, Terraform ou quelques formulaires dans la UI, ils peuvent créer ces liens de connectivité. Et pareil sur toute la partie gouvernance, il y a beaucoup d'outils qui vont être disponibles pour tous les projets, pour Anne, dès le début. Donc par exemple, tous les projets vont avoir accès au portail de topics, où on va pouvoir voir les différents topics, le schéma associé, quelques messages, et ils peuvent même demander permission en lecture ou écriture à ces topics-là. Donc les gens peuvent voir ce qui est disponible comme données dans quel topic.

28:00 rechercher et puis demander les permissions. Et toute la partie cartographie est également inclue. Donc ça veut dire qu'Anne a déjà des dashboards. Encore une fois, je montre la UI. On met l'information à disposition sur des API, sur Terraform. Tout est disponible sur GraphQL, si vous connaissez. Bon, j'avoue que tout ce qui est cartographie, je préfère la UI. Mais qu'importe. En tout cas, tous ces systèmes-là sont disponibles dès le début. Et donc la conséquence, c'est que Tom va passer beaucoup de son temps sur la partie plateforme. J'ai été Tom pendant très longtemps, pour être honnête. Moi, j'aime bien faire ça. Mais après, il faut bien comprendre que la partie plateforme, c'est un point important quand tu déploies toi-même, parce qu'il faut absolument que ta plateforme soit sécurisée, monitorée. Ce n'est pas quelque chose d'optionnel. Pourtant, ce n'est pas quelque chose pour mon métier, grosso modo. Alors que Anne, à l'opposé, toute cette partie-là va être abstraite pour elle et Anne va pouvoir utiliser ce temps-là, non pas pour se concentrer sur les pratiques de sécurité, mais pour accompagner les différents projets sur la plateforme. S'assurer que les projets vont avoir, poursuivre les bonnes pratiques de développement, construire des bonnes pratiques, ensuite

29:03 les patterns d'utilisation des différents projets, promouvoir l'EDA en interne, dire attention si tu veux faire de l'EDA, de l'Even Driven Architecture, il ne faut pas faire ça, il faut plutôt faire ça. Et avoir ce type d'accompagnement. Un vrai impact et des vraies conséquences bénéfiques au sein d'une entreprise. Il faut absolument accompagner les projets, surtout si c'est leur premier projet, à faire de la gestion de données en temps réel. Donc ce coaching, ce coaching, Support projet, c'est une partie très importante dans n'importe quel système de gouvernance, notamment dans ce type de plateforme de gestion de données en temps réel. Et donc, Anne va beaucoup plus se concentrer sur ça, qui est vraiment bénéfique, je vous conseille fortement de le faire. Ce type de plateforme, l'équipe service, l'équipe middleware, il y a un changement de paradigme, ce n'est plus eux qui font, c'est eux qui vont coacher. Et ce job de coach, c'est extrêmement important, quelle que soit la taille de votre organisation. Dès qu'on arrive à plusieurs applications qui doivent s'intégrer, il doit y avoir un mec qui va dire un peu le centre d'excellence Kafka, la connaissance Kafka et qui va passer son temps, non pas à faire le job, mais vraiment à parler au projet en disant « Tiens, j'ai vu ta pull request, j'ai vu ton design, est-ce qu'on peut en parler ?

30:09 » parce que ça me semble un peu… ça ne me semble pas être super pratique, peut-être que tu peux l'optimiser ici, ici. Et ça, c'est une vraie valeur ajoutée. En 30 minutes, on a un peu parlé de qu'est-ce que c'est qu'une plateforme de gestion de données en temps réel, comment la faire de manière plus efficace, quels sont les différents composants. C'est encore une fois très haut niveau, parce qu'en 30 minutes, on n'a pas trop le temps de zoomer. Il y a énormément d'autres sujets qu'on pourrait rentrer en détail. Faire du processing de données en temps réel, c'est très différent par rapport à faire du batch. On n'a pas du tout les mêmes problématiques, surtout si vous faites des transformations stateful, des voitures, de l'agrégation, de la dénormalisation, ça apporte pas mal... Enfin, c'est un changement de paradigme, c'est différent. Pareil, la gouvernance, c'est un énorme topic où il n'y a pas vraiment de silver bullet, il n'y a pas une solution qui correspond à tout. Les pratiques de collectivité, les pratiques de gestion, vraiment, ce sont des sujets assez grands. Ce serait avec plaisir qu'on peut rentrer dans le détail, mais ce sera plutôt du tour de la question parce qu'en 30 minutes, on ne peut pas tout présenter. Donc justement, je ne sais pas s'il nous reste un peu de temps pour les questions. Je pense qu'on peut peut-être en prendre une ou deux. Sauf si il y a l'apéro direct. Ou apéro direct, Ricard, 5 heures, ce que vous voulez.