 Bon Laurent et Alain, vous êtes prêts ? Bonjour, oui, on est prêts. Salut, oui, super. Oui, et comme j'ai annoncé ce matin, je sais pas si vous avez vu, je lui ai dit que votre démon ça va être un peu plus que du Heal The World. Et euh, donc euh, j'ai hâte de voir ça. Donc, je vous laisse The Stage et on se retrouve à la fin. Ok ? Merci, merci. Merci. Merci. C'est parti. Partage d'écran. Et normalement, vous devriez voir mon écran. C'est bon là, tu peux me faire le feedback ? C'est bon. Super. Et bien, ben, bonjour à tous ces amis, puis bienvenue pour cette session effectivement, où on va discuter, euh, Kafka et Kinective au service des bricolores du dimanche. Alors, euh, tout de suite, on vous donne le ton, la couleur, hein, c'est, c'est pas un retour d'expérience, le roi mernin, brico dépeau, castorama, que sais-je ? C'est plutôt euh, notre vision à nous du bricolage. Donc, vision geek, vous allez voir. Vous avez peut-être un petit peu dérouté. Et euh, donc, aujourd'hui, ben, avant de démarrer, on va se présenter. Donc, aujourd'hui, je suis avec Alain. Bonjour à tous. Moi, je m'appelle Alain-Fam. Je suis architecte de solutions chez Redat. D'habitude, je voyage à travers l'Europe pour délivrer des BOC et des workshops. Bon, on essaye de faire tout ça à distance maintenant. Donc, en dehors de moi, je suis super passionné par la création de films. Et notamment avec des des appareils plutôt vintage et des choses pas trop chères parce que voilà, je ne veux pas casser la bourse. Ah mais à côté de ça, je suis aussi bricoleur du dimanche. Donc, ça tombe bien avec le thème de la présentation aujourd'hui. Exactement, parce que ce qu'on va vous raconter, c'est une histoire personnelle. Donc, moi, je suis également solution architecte chez Redat. Je travaille sur tout ce qui est effectivement pratique moderne de développement d'applications. Je contribue en open source la nuit. Allez voir un microx. Et puis, je suis bien occupé tout le temps. Voilà. Ma passion, c'est pas faire des films, c'est aussi m'occuper de mes enfants. Ça prend pas mal de temps. J'aime tout ce qui est architecture distribuée, donc Kubernetes, Camel. J'adore discuter pendant des heures des best design d'API. Voilà. Et puis, bien bien sûr, avec tous ces enfants, je suis aussi un bricoleur du dimanche. J'ai toujours plein de choses à réparer, à monter. Voilà. Des nouvelles chambres à peindre. Que sais-je encore? Voilà. Alors, Alain, tu vas peut-être nous parler aujourd'hui de ton projet sur quoi tu travailles en termes de bricoleur. Oui, en fait, j'ai réceptionné une nouvelle maison il y a un mariage. Et donc, mon épouse et moi, on se demandait comment on allait aménager l'intérieur. Et donc, c'est une tâche ultra difficile pour se projeter. Et je voulais absolument pas faire d'erreurs de choix. Et donc, voilà, pour se faire, j'ai vraiment pas envie de faire des erreurs, comme vous verrez là sur les photos. Si, voilà, là, par exemple, j'ai une porte de garage que je ne sais pas comment on peut y accéder. Absolument éviter une erreur de genre. Une autre photo encore. Là, le balcon, j'imagine que la solution, c'est de partir en haut et puis d'utiliser une corde pour descendre. Mais à part ça, je vois pas trop de solution d'accéder au balcon du dessous. Et puis, bon, le vécis divisé en deux, j'aimerais l'éviter aussi. Voilà. Oui, je pense que celle-là, on a percevoir et tu vas vite voir ton erreur. Et sinon, alors, du coup, comment tu fais, toi, pour justement réussir un petit peu à se projeter, à discuter justement avec ta moitié de ce que tu veux faire, de réussir à la convaincre et de dessiner ensemble la suite des chantiers, des options à retenir, comment tu procèdes. C'est une très bonne question. Donc, il y a un peu plus de 7 ans, j'avais à utiliser un logiciel qui s'appelle Blender, donc c'est un logiciel open source aussi, très bien. Et donc, ce qui permet de faire, c'est de modéliser des choses en 3D. C'est un logiciel très, très versatile et on peut effectivement modéliser sa maison et faire des simulations et faire des rendus photorealistes. Donc, c'est un peu comme ça que j'ai procédé. D'accord. Alors, là, pour les fans de Miyazaki, peut-être des gens ont reconnu, c'est en fait, c'est la maison des termes dans le voyage de Shiro, le fameux dessin animé. Donc, toi, tu as fait la même chose, hein. T'as modélisé la totalité de la maison avec Blender. Exactement. Donc, j'ai modélisé ma maison et puis, donc, à l'intérieur, j'ai pris des meubles, des modèles existants, j'ai composé les meubles, il y a certains meubles que j'ai modélisé moi-même. Et donc, ensuite, avec Blender, ça me permet de faire des rendus photorealistes et puis de me projeter pour voir si les meubles va bien avec un autre, telle couleur va bien avec un autre ou pas. Et donc, voilà ce genre de résultats qu'on peut obtenir. Donc, je suis super, super content de pouvoir faire ce genre de chose et de pouvoir se projeter avant d'aller acheter les meubles et de se lancer dans les travaux. Oui, puis l'avantage, sûrement, c'est que tu peux tester différentes configurations et facilement, justement, checker si les couleurs s'accordent bien, si les meubles sont bien disposés, si tu n'as pas mis la cloison au plein milieu des décès. Exactement, voilà. Et donc, il y a quelque d'autres exemples aussi, surtout, une grosse discussion, ça a été quelle est la couleur de la crédence, est-ce qu'on met un motif comme ça ou est-ce que ça va être une couleur bois, est-ce qu'on met une cloison ou pas, etc. Tout ça, on peut simuler avant et avoir ce genre de rendu photéraliste pour se projeter. Mais alors, du coup, j'ai un gros problème, j'ai rencontré un gros problème dans ce processus. Je peux te le montrer, c'est que, donc voilà, là, on est dans Blender. Donc, vous pouvez le voir. Donc, tu peux le voir. J'ai modélisé la maison. Et du coup, à chaque fois qu'on veut lancer le rendu, ça prend énormément de temps. Parce que c'est très coûteux de simuler le cheminement des différentes rayons de lumière pour avoir ce rendu photorealiste. Et donc, là, comme vous pouvez le voir, ça prend presque 40 minutes pour une seule image. Et c'est un gros frein pour la productivité, pour faire nos choix précolystiques, c'est-à-dire. Et donc, ça, c'est vraiment un gros problème que j'ai rencontré. Et du coup, si tu passes sur la slide suivante, on a perdu le rend. On dirait qu'on a perdu le rend. On a perdu le rend. Attends, je vais attendre qu'il me redemande maintenant. Est-ce qu'il est connecté ? Alors, ça a été reçu. Je sais de ce qui se passe. Bon, on va écouter. Oui, oui. J'ai eu une coupure de fibre. Désolé. Allez, on reprend alors. C'est parti. En croisant les doigts. On entend des partages d'écran. On reprend. Donc, tu nous disais juste, Alain, ça prend énormément de temps chaque fois que tu vas faire une simulation. C'est ça ? C'est ça. Et donc, pour faire des choix, c'est un processus qui est très long et c'est presque inacceptable, en fait. Alors, il y aura énormément de temps. Qu'est-ce que tu entends par là ? C'est quoi ? 5 minutes ? Là, comme tu peux voir dans l'exemple, c'est pour une image potable. Ah oui, d'accord. Ça prend du temps, effectivement, de parcourir plusieurs options. Exactement. Et donc, moi, je voudrais résoudre quand même ce problème. Je voudrais pouvoir accélérer le rendu. Comme tu peux le voir sur la vidéo, on a le modèle qui est là. Et puis, une fois qu'on lance le rendu, il y aura énormément de temps. D'accord. Et là, je vois effectivement 40 minutes facilement. Voilà. Vous voyez, l'image commence à apparaître au milieu. Ça passe sur les petits carrés, l'un après l'autre. Ça prend toute la CPU et ça prend énormément de temps. Ok. Donc, t'es challenge, pour réussir ton projet ? Pas du coup, voilà. Mes challenges, c'est d'attendre le moins possible pour avoir mes rendus photo réalistes. Et puis, ne pas casser la banque, payer le moins cher pour avoir ce résultat. Oui, parce que j'imagine l'option de t'acheter une super grosse machine qui soit up and running tout le temps, c'est pas forcément la plus économique. Tout à fait. Et donc, j'ai commencé à réfléchir à des solutions. Donc, la problématique des rendus comme ça, c'est quelque chose qui est divisible. Donc, on peut en fait diviser l'image en différentes tuiles et réaliser les rendus de manière parallèle. Moi, ce que j'ai fait, c'est que j'ai commencé à conteneuriser Blender et j'ai écrit un petit service d'orchestration au-dessus pour pouvoir lancer les rendus sous forme d'appel API. J'ai testé ça localement sur les machines que j'avais chez moi, donc j'ai confisqué les ordinateurs de toute la famille et j'ai lancé des tests de rendus. Par contre, ça aussi ça a dérangé tout le monde de devoir me donner les ordinateurs et donc, je vais vraiment arriver à une autre solution. Oui, puis bien sûr, t'es limité au nom de l'ordinateur dans la maison. Tu peux pas étendre ça du thème éternale. Ok. Et donc, c'est pour ça que je t'en parle parce que moi, j'ai entendu que tu étais super fort en architecture distribuée et que t'as toujours une solution dans la poche pour aider les gens à partir sur les solutions cloud. Est-ce que tu pourrais me proposer pour résoudre ce problème ? On va voir ça et je pense qu'effectivement on va pouvoir travailler sur la parallelisation de tout ça et l'optimisation de l'usage des ressources et donc on va voir comment les architectures distribuées notamment cloud peuvent venir au secours des bricoleurs. On voit que ce qui est déjà bien avec Blender c'est qu'effectivement on va pouvoir comme tu l'as dit, splitter les tuiles et donc on va être sur un modèle effectivement de scalabilité horizontal on va faire du scale out. Et puis, ce que je te propose c'est de voir comment on va pouvoir utiliser nos outils modernes Kafka, Knative pour justement optimiser toute cette partie rendering. Alors première chose qu'on va utiliser c'est effectivement on va pouvoir utiliser Kafka et toutes les capacités de parallelisme et pour ça on va utiliser en fait deux choses, on va faire du parallelisme à deux niveaux. Déjà tu sais qu'au sein d'un cluster Kafka, alors Kafka on le présente plus c'est un broker de messages qui va permettre de faire du streaming de messages, du streaming de data et donc qui fonctionne de façons de distribuer en cluster et donc au sein d'un cluster on va pouvoir trouver plusieurs brokers pour justement gérer de la haute disponibilité gérer de la résilience et puis aussi répartir la charge. D'accord et au sein de nos brokers on va organiser en fait nos messages selon des partitions et c'est grâce à ces partitions en fait qu'on va pouvoir gérer du parallelisme de consommation parce que typiquement je vais pouvoir consommer en parallèle des messages qui sont sur la partition 1, sur la partition 2 jusqu'à la partition 4 dans mon petit exemple. Et puis une notion importante en fait de Kafka qui se place au niveau du consumer c'est qu'on va pouvoir déterminer voilà ce qu'on appelle des groupes de consommateurs et au sein d'un groupe de consommateurs par exemple on groupe 2 effectivement si je fais du multisreading, si je fais du multi instance, du multi réplica eh bien chaque consumer va pouvoir s'occuper d'une ou de plusieurs partitions spécifiquement. Donc là on va avoir une belle mécanique pour justement faire du parallelisme donc ça c'est pour le problème effectivement d'aller le plus vite possible de distribuer les choses, les traitements et puis pour ton problème de payer le moins cher possible ben on va plutôt utiliser un pattern serverless donc vraiment de façon canonique le pattern serverless c'est voilà j'ai un événement quelque part une demande, un utilisateur qui s'logue une requête qui arrive et ça ça va en fait triggerer mon application mon process pour justement faire le traitement de la Tata et puis produire le résultat. Alors assez basiquement quand on parle serverless on pense tout de suite effectivement question et bon, son parent, sa AWS et les Lambda. Mais il faut savoir que dans la galaxie Kubernetes et dans le projet notamment kénétive ben on a la même chose cette généralisation en fait du pattern serverless à tout ce qui est événement donc ce qu'on va recevoir ce sont des événements sous forme de messages Kafka. On va en fait transmettre ces messages à un conteneur et la chose intéressante c'est que si on reçoit beaucoup de messages dans nos partitions Kafka, dans nos topiques Kafka, eh bien on va pouvoir en fait scale et donc instantier beaucoup de conteneurs pour justement traiter nos messages le plus vite possible. On va pouvoir mettre en place en fait des règles de concurrence pour justement adapter le nombre d'unités de traitement au nombre de messages en amont. Ok ? Donc ça ça va vraiment traiter en fait notre problème ton problème de coup c'est à dire qu'on va pouvoir utiliser cette mécanique là pour travailler beaucoup d'instances de traitement et puis une fois que ce sera terminé revenir à zéro et pas monopoliser de la ressource Donc voilà les deux principes. Et puis autour de ces deux principes on va monter une petite architecture alors je vais t'expliquer ce qu'on va faire on va bien sûr se créer un cluster Kafka d'accord, central et puis on va se faire une première petite application pour prendre les commandes avec cette application pour justement fournir tes ressources blender et puis on va te proposer différentes options de rendering est ce que tu veux de la haute qualité est ce que tu veux aller très vite et utiliser beaucoup de workers ou est ce que tu as ton temps et tu veux dépenser moins d'argent et utiliser moins de workers on va te proposer ça une fois que tu auras choisi cette option de rendering et bien en fait on va publier un message en fonction de l'option choisie dans un topic Kafka ce sont les requêtes de rendu et puis via la mécanique quénétive on va justement écouter ces requêtes de rendu et en fonction des différents du nombre de messages et des différents degrés de parallélisme qu'on aura renseigné et bien on va infrancier justement des pods de rendu pods qui vont embarquer justement le moteur blender qui vont travailler la première chose c'est qu'ils vont commencer par récupérer des ressources ils vont travailler et puis au fil de l'eau ils vont renvoyer des statuts pour dire comment ils avancent et puis renvoyer les résultats là aussi dans des topics Kafka voilà alors d'un point de vue du retour à un utilisateur ce qu'on va faire c'est qu'on va faire en sorte de faire les choses très dynamiques et à chaque fois qu'on recevra un message Kafka un statut ou un résultat eh bien on poussera en fait ce résultat dans ton navigateur en utilisant le protocole WebSocket comme ça ça te permettra vraiment d'avoir un suivi torre réel du rendering et normalement si tout va bien je crois des doigts on devrait être bien plus rapide que ce que tu fais sur les laptops de la maison qu'est ce que tu en penses ça te paraît chouette ? ça me paraît très très prometteur et je pense que c'est la solution qu'il me faut ok alors tu veux voir ce que ça donne on arrête les slides un petit peu allons-y on va déployer en fait ça pas à pas sur notre cluster Kubernetes OpenShift alors premier outil ce qu'il nous faut un beau broker Kafka et des topics d'accord donc j'ai instantié un cluster OpenShift tu le vois ici et sur ce cluster effectivement j'ai créé un cluster Kafka dans mon petit projet Undiman donc j'ai mon cluster Kafka, mon zookeeper tout est là et géré par un opérateur sur OpenShift alors je regarde un petit peu justement cet opérateur, un stade d'opérateur hop je reviens sur mon projet voilà donc ici j'ai mon instance Kafka qui a été créé et puis je vais aller voir justement les topiques d'accord où sont-ils les topiques voilà j'ai mes topiques de résultats de gestion des statuts qui ont été créés puis on va créer ensemble en fait le topique justement le plus important c'est celui où on va envoyer les requêtes de rendu ok on va mettre voilà pas de réplication pour ce topique c'est une démo et une chose importante ici c'est qu'on va régler le nombre de partitions d'accord et puis nous sur notre cluster alors ce n'est pas un cluster énorme on va se dire voilà je veux 25 partitions parce que je vais vouloir parler l'Elysée jusqu'à 25 traitements et donc j'ai juste à créer déclaré mon topique ça y est j'ai un topique OpenRunning d'accord rendering request il est là il est prêt donc mon cluster Kafka il est prêt à recevoir de la charge j'ai créé les topiques j'ai tout ce qu'il faut jusqu'ici tout va bien deuxième outil dont on a besoin c'est le fameux composant Ordering d'accord alors ce composant je l'ai développé en utilisant Quarkus d'accord et puis on va le déployer tout de suite dans mon cluster donc on va faire un poussé create un F un manifest un fold deployment j'ai créé normalement une config map pour dire sur quel cluster Kafka je vais en connecter voilà un déploiement et puis je vais aussi créer la partie réseau d'accord pour pouvoir facilement accéder à cette application et puis pour pouvoir l'exposer en dehors du cluster Ordering il me faut une route une route OpenShell c'est l'équivalent d'une ingresse puis Bernet tout simplement donc là c'est en train de se déployer juste il y a une chose hyper importante sur ce composant Ordering c'est que quand il produit des messages sur Kafka il faut être certain que ces messages en fait ils soient distribués de façon homogène sur toutes les partitions d'accord souvent quand on écrit effectivement des choses basiques on s'occupe pas trop sur les partitions sur lesquelles atterrissent nos messages là c'est vraiment en fait un point clé notre archi-lecture et donc pour ça en fait on utilise d'encore plus c'est dans micro profiles réactifs on va utiliser justement des métal data d'enregistrement Kafka d'accord et ces métal data on voit qu'on va les répartir de façon homogène justement sur l'ensemble de nos partitions en faisant un modulo sur la capacitude qu'elles sont bien distribuées on envoie notre message, notre quête avec les métal data associés pour distribuer ça surtout sur toutes nos partitions donc ça c'est vraiment indispensable dans notre application alors je vais revenir ici normalement est-ce que c'est déployé yes mon composant Quarkus est là d'accord je vais l'ouvrir, je vais vous montrer tout de suite à quoi ça va ressembler voilà je vais juste enlever la fenêtre comme ça et la mettre ici alors c'est notre petit IHM de test on va voir qu'on va pouvoir uploader un fichier blender une fois qu'on l'aura uploadé le moteur en fait nous proposera différentes options de rendu on pourra suivre le statut et le résultat en temps réel d'accord ça te paraît bien ça me paraît très bien je suis impatient de voir la suite ok il n'y a pas que moi qui travaille tu vas travailler aussi toi je te délegue toute la partie composant rendering tu as déjà pas mal regardé blender et ce qu'on pouvait y faire d'accord je vais expliquer gros modo comment j'ai fait cette partie donc le principal de ce composant là finalement ce que j'ai fait c'est que j'ai fait un projet camel Crocus qui expose des opérations donc c'est ça qui va recevoir des requests de rendu et donc en dessous j'ai intégré blender dans le même conteneur et la pays pour pouvoir piloter blender c'est du piton donc j'ai fait quelques quelques fonctions pitons pour qu'ils puissent accepter des commandes tel qu'ouvrir un fichier ou lancer le rendu et donc ce que fait camel Crocus il fait tout ce qui est l'intégration autour c'est pour ça qu'on utilise camel ici c'est parce que c'est quand même très pratique d'avoir ces briques d'intégration autour pour pouvoir télécharger des fichiers transformer les différents événements de la notification à renvoyer vers la partie ordering et puis finalement de prendre le résultat du rendu et de le renvoyer également vers la partie ordering donc tout ça ça fait des étapes d'intégration qui sont assez moyennement complexes on va dire et qui sont très très bien gérés par le vrai morgue camel puis Crocus voilà pour être vraiment l'out native et pouvoir démarrer d'instances de manière très rapide yes exactement si vous avez suivi la track 2 il y a Zineb ce matin qui nous a fait une super démonstration justement sur le détail d'utilisation de camel avec Crocus donc vraiment il faut voir ce composant comme une extension de ce qu'elle a fait avec effectivement les protocoles HTTP, file et Kafka alors du coup c'est prêt à déployer Alain on voit ensemble comment on va déployer donc là il y a des spécificités cognitive du coup qui vont s'ajouter mon développement il n'a pas tellement changé donc tu nous montres un peu la commande qu'on va utiliser la voici donc si je comprends bien ici les éléments importants c'est la partie concurrency limit égale à 1 si je comprends bien donc ça veut dire que pour chaque partition Kafka il y aura un pod qui va tourner exclusivement pour cette partition n'est ce pas ? exactement alors on voit que c'est des pods qui consomment pas mal de ressources quand même c'est pas du hello world donc ce qu'on veut c'est qu'il n'y ait pas trop de files d'attente et donc on limite explicitement la concurrence sur ces pods voilà et je vois aussi que tu as mis de la bonne ressource donc 4 cpu pour un pod j'espère que ça va dépôté plus tard exactement ouais tout à fait sachant que là en plus on a fait le rendu en utilisant simplement du cpu la chose intéressante avec blender c'est qu'on peut aussi utiliser du gpu et ça c'est une des pistes encore d'amélioration de notre projet dans les jours, les semaines à venir exactement alors on déploie d'accord et donc on voit que tout de suite la command kind service elle va nous créer justement un knetive service voilà et donc avec un knetive service en fait il y a une première instantiation qui se fait pour justement vérifier qu'on sait correctement instantier ce qui est du lait le pod on l'exécute une première fois et puis normalement comme là rien ne vient, pas de message on n'a pas encore demandé de rendering gentiment en fait le pod va venir se terminer au bout d'une petite période de 30 secondes je crois on va le laisser se terminer gentiment donc on a déployé tous nos composants un à un maintenant la dernière chose qu'il nous faut pour lier tout ça ensemble ça va être en fait une source d'événement on va faire le lien entre les messages qui arrivent sur nos partitions Kafka et justement ce service knetive de rendering et pour ça on va utiliser en fait une événement source knetive de type Kafka connecté à notre broker donc on va instantier ça tout de suite et on aura tout ce qu'il faut pour justement lancer la démonstration alors vous voyez effectivement le scale2zero est en train de se faire voilà parfait on va juste l'enlever comme ça donc là j'ai un pote qui en fasse terminating et alors on peut le créer via la ligne de commande cette événement source moi j'aime bien le faire aussi puis lié à Shemp parce que là il y a une petite flèche bleue qui va permettre de faire plein de choses dans dans les courses de développement mais si on la lâche comme ça on va pouvoir aussi associer en fait une événement source à notre service knetive notre événement source on va la choisir ici il y a le type type Kafka d'accord je veux simplement la créer et donc on va pouvoir la créer facilement depuis le formulaire on va choisir un bootstrap server c'est le service qui va permettre effectivement de se connecter au cluster Kafka moi je vais faire en local en interne sur le port 90-92 je vais choisir un topic ce que j'écoute c'est les requêtes de rendue d'accord je vais définir un consumer group qui me permettra justement de dire au sein du groupe ben effectivement je peux gérer de la paralysation en écoutant différentes partitions je l'appelle juste ondiman rendering group et puis la dernière chose importante c'est que voilà je dois déterminer un sync c'est la destination c'est l'endroit où seront en fait envoyer mes messages c'est le composant de rendering je crée cet event source c'est la foot voilà donc alors je peux réorganiser un petit peu on va faire un petit boutique voilà j'ai mes différents composants qui sont là mon rendering mon cluster mon ordering qui s'est mis ici je vais bouger là et ma Kafka source qui est prête à fonctionner donc maintenant on va croiser les doigts des mots c'est parti alors ce qu'on va juste regarder c'est voilà on va se mettre comme ça on va essayer on va voir le comportement j'arrange un petit peu mes fenêtres voilà allez c'est parti je choisis mon fichier blender j'ai le plan de ta maison que tu m'as transmis c'est bien ça oui c'est la dernière version la dernière version on va l'uploader sur le composant de rendering je plote mon fichier alors je crois que je fais 350 méga que quelque chose comme ça c'est fichier oui c'est pas nodin voilà petit temps de téléchargement voilà ça y est donc il y a une analyse de fête et j'ai 3 options 3 options de rendering qui coûtent plus ou moins cher qui produisent des choses avec plus ou moins de passe avec plus ou moins de sampling sur l'image et puis en utilisant plus ou moins de worker d'accord est-ce qu'on y va pour l'option L ? oui c'est bon j'ai mis 14 euros de près je te délitera la carte tout de suite mais on fera ça on nous développera cette partie la semaine prochaine allez c'est parti et voyez tout de suite sur la gauche et ça y est j'ai eu des messages Kafka et Knative entre en action donc là je suis en train d'instancer des pods pour justement réaliser en fait le rendering de du fichier d'aller donc sur la droite on voit effectivement les statues je suis en train de recevoir des requêtes d'accord et tiens certains ont déjà récupéré le fichier ils sont en train de faire le rendu voilà ça y est tout le monde commence à faire son rendu et donc d'ici je pense une petite minute je vais commencer à voir des rendering résult qui apparaissent effectivement dans mon convasse ici en bas alors vous voyez première chose c'est que en fait je demandais 16 workers mais finalement j'ai un peu plus de 20 potes qui ont été instantiés ça c'est parce que l'algorithme de Knative est assez complexe pas forcément très déterministe il va au moins instantier 16 pods et puis parce qu'il imagine qu'il y a beaucoup de trafics qui arrivent il va commencer à en préparer d'autres donc on va se retrouver avec plus de pods effectivement le nombre de messages donc on va voir que c'est pas très gênant parce que dès qu'on aura fini de travailler effectivement on va libérer de la ressource tiens premier résultat mon four qui est arrivé avec ma fenêtre ouais exactement alors ce qu'on peut voir ce qu'on peut regarder aussi la chose intéressante c'est on peut regarder pendant ce temps là c'est toute la partie aussi pods justement tout ce qui a été envoyé qui a eu pas mal pas mal de pods qui sont en mode running d'accord voilà on commence à consommer un petit peu de corps, un petit peu de mémoire du joueur derrière ça arrive en masse ouais tout à fait j'ai pas encore tout tout tout n'est pas encore là alors une chose intéressante que je voulais vous montrer c'est que voilà la Knative la Kafka Event Source alors visuellement vous avez vu c'est un voilà il y a une petite icône sur la console de développement mais derrière il y a aussi un pod bien sûr qui fonctionne c'est un petit programme écrit en go et donc qui va se charger justement de scanner en fait d'écouter des différentes partitions donc là vous voyez sur mes différentes partitions ça consomme et derrière ça fait appel au moteur Knative pour justement distribuer et instantier en fait le nombre le nombre de pods c'est intéressant de voir quand même Laurent c'est que j'ai pour faire ce rendu on a occupé le cluster entier mais uniquement le temps du rendu qui est de 1 min donc le reste du temps les ressources sont libres pour faire autre chose ça me paraît génial exactement si je regarde effectivement la partie rendering ici on voit que voilà j'ai déjà terminé 11 pod j'en ai encore 3 qui sont en train de terminer voilà ça correspond peu ou peu à la tuile ou à la partie qui nous manque et effectivement d'ici quelques minutes j'aurais totalement libéré les ressources sur mon cluster alors là on a fait les choses en plus dans un cluster j'irai qu'il était déterminé qui était figé avec un certain nombre de noeuds un certain nombre de machines j'ai été intérêt aussi d'open shift on l'a pas fait aujourd'hui en live c'est que vous pouvez justement via cette notion de machine set gérer justement le nombre de machines et mettre en place de l'autoscaling sur les machines donc on peut très bien imaginer un scénario où effectivement vous demandez un rendu énorme avec vraiment une centaine de pod qui sont instantiés si vous avez mis en place des machines autoscaler et bien en fait le cluster lui va derrière pouvoir provisionner automatiquement de nouveaux noeuds pour accueillir vos pods de rendu le temps de ce rendu et puis ensuite on descendra tout à zéro je reviens ici sur le déploiement dans mon projet un diman ça y est, je suis revenu à zéro j'ai vraiment libéré toutes les ressources j'ai mon dernier qui est en train de se terminer et Alain tu as ton image de rendu sans avoir un temps de 40 minutes qu'est ce que tu en penses donc là c'est accéléré par 40 moins de une minute et quelques on a le résultat tout de suite regarde si on on traque un petit peu la tuile 00 on a démarré à 10h15 30 et si je recherche les 00 voilà 10h17 01 donc une minute 30 pour le rendu de cette tuile comme on a réalisé normalement c'est super j'adore ok, bah top je pense qu'on va pouvoir continuer comme ça et puis créer notre petit projet de rendering farm bah oui et d'ailleurs on va le louer à d'autres personnes comme ça on va le rentabiliser exactement alors en conclusion ce qu'on a pu voir c'est bah voilà avec Kennethive, Kafka avec OpenShift Kubernetes bah vous avez tout ce qu'il faut pour justement créer votre rendering farm sur mesure dans un contexte un peu ludique de notre petit projet perso mais imaginez ce que ça peut donner sur dot use case de type analyse d'image satellite de type justement de job AI quand il faut traîner un modèle de façon très périodique dans la finance quand il s'agit effectivement de simuler des termes vous avez en fait tous les moyens maintenant pour monter un cluster sans monopoliser de ressources et vous avez tous les moyens aussi pour justement rendre ça pour être scalable soit d'un point de vue logique, soit même d'un point de vue physique en ajoutant des machines si le besoin s'en fait sentir et donc moi ce que je trouve super avec cette approche c'est que l'adoption de Kennethive en termes de développement ça n'a pas d'impact sur des développeurs à vraiment parler donc moi j'avais développé initialement pour faire les rendus tu l'as transposé exactement sans grande modification à une architecture Kennethive et finalement donc c'est en introduisant les éléments de configuration distribuées comme les key services les sources et les brokers que tu as pu mettre en place ce genre de de systèmes qui peuvent scaler à zéro et puis utiliser les ressources du mand seulement quand il y en a besoin moi je trouve ça assez exceptionnel et je trouve que en termes d'adoption c'est quelque chose qui est très très facile à adopter bon je pense que Laurent on a encore perdu Laurent et il semble avoir un orage chez lui ouais, il réfléchissait vraiment voilà mais voilà tout notre code est dispo sur github donc voilà sous Kennethive andyman on va le poster tout à l'heure sur le chat et donc vous pouvez aller voir ce qu'on a fait intérieur et vous pouvez le reproduire chez vous ouais non tout à fait moi je serai le premier le tester parce que Kennethive et Kafka c'est deux techniques que je présente beaucoup des use case un peu de basse parce que j'explique les bases mais là c'est carrément un use case c'est pas évident d'expliquer les use case derrière Kennethive toujours moi j'utilise souvent l'exemple du chat bot super compliqué qui est dans une société d'assurance par exemple qui doit calculer le contrat il t'a récalculé tout ça et que la nuit il n'est pas utilisé donc voilà il peut scaler à zéro il a journée justement il y a une édourage par exemple tous les gens vont demander des questions parce qu'il y a des soucis dans ce cas là mais là je veux passer rendering à ce service c'est cool alors il y a une question alors il y a une question de vaccins mais je crois qu'avant il y avait une question sur python il demandait si ça utilisait fast api tu alors je suis pas du tout expert python la raison pour laquelle j'ai utilisé python pour la partie blender c'est que nativement en fait blender la pays pour automatiser des choses c'est en python donc j'ai pas utilisé je saurais pas répondre à cette question et il y a une question de vincent alors est-ce que vous pouvez confirmer que l'intégration camel vers python considère que l'existent python en input des arguments type CLI et qu'il en sort en code d'exit genre ok, non ok ça c'est une question et que si besoin c'est du messaging sidebond comme Kafka qui permet d'intégrer la production résulte pérantopique ou une queue tu as saisis la oui oui j'ai pu la voir donc l'intégration qui a été faite pour ce projet c'était effectivement via des API rest python expose un endpoint HTTP qui est accessible uniquement en interne du conteneur donc c'est pas exposé en service vers l'extérieur et on aurait pu le faire en CLI effectivement mais le choix a été fait de passer via un API rest python expose une API rest et camel quarkus vient piloter blender via cette API rest ok c'est cool entre vous et le talk de Zinem ce matin on a eu pas mal de gens aussi la découverte de camel qui est magique Zinem m'a essayé un bout de sa démo que j'ai pas pu voir mais que je reverrai en replay oui c'est elle m'a montré un peu le combo quarkus en mode dev plus du camel enfin il y avait pas mal de magies et ça ça donne envie de celer c'est extrêmement puissant c'est extrêmement puissant moi j'utilise c'est la partie dans laquelle je suis spécialisé tout ce qui est intégration et camel donc j'utilise presque pour tout et ça permet vraiment d'accélérer les développements les petites tâches d'intégration comme ça où on a des connecteurs réutilisables c'est extrêmement puissant même pour orchestrer des différentes étapes ajouter un peu de logique faire des transformations tout ça c'est extrêmement puissant ça a l'air extrêmement puissant avec une syntaxe relativement simple en chaine les routes avec les transformeurs c'est quoi qui m'avait impressionné il y a deux trucs qui m'ont impressionné c'est qu'elle a rajouté une route pour envoyer sur du Kafka c'est vraiment un string Kafka 2 points le nombre du topic et là c'était persister dans jpa jpa 2 points le nombre de l'entité on a rien besoin de faire ok