Bruno:
[0:50] Ça marche sur ma machine. Cette simple phrase peut déclencher des guerres de tranchées sans fin. Il existe un monde entre notre dev et le monde de la prod. Un monde qui se résorbe de plein de manières, par des process ou même par des technos. Mais cela passe surtout par une compréhension des enjeux respectifs. Kubernetes est une techno connue mais aussi méconnue, complexe et nécessairement complexe pour gérer les environnements aux enjeux de plus en plus forts. Mais alors, peut-on s'abstraire de cubes ? Faut-il juste arrêter les clusters ? Et surtout, comment s'assurer que si ça marche sur ma machine, ça marche aussi en prod ? Pour répondre à ces questions de charge, je ne reçois pas Optimus Prime, mais il s'y connaît en conteneur. Benjamin, bonjour.
Benjamin:
[1:34] Bonjour Bruno.
Bruno:
[1:35] Alors Benjamin, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Benjamin:
[1:38] Oui, bonjour à tous. Je m'appelle Benjamin Chastanier, j'ai 34 ans. Ça fait un peu plus de 10 ans que je fais du dev niveau professionnel, on va dire. Et j'ai eu une petite expérience j'ai fait 7 ans de dev chez Criteo et là ça fait à peu près 3 ans et demi que je suis chez Covry en tant que back-end engineer Ok.
Bruno:
[1:56] Je vais me permettre de commencer direct par une question qui est peut-être un peu plus vaste que le sujet donc toi à la base t'es plutôt dev back-end aujourd'hui tu bosses sur des sujets d'infra à quel point est-ce que pour toi c'est nécessaire qu'un dev, connaisse des sujets d'infra et à quel point il faut les connaître et les maîtriser.
Benjamin:
[2:17] Alors il y a plusieurs questions est-ce que c'est intéressant je trouve ça super intéressant, parce qu'en fait on a beau dire que le dev on est agnostique ça part en prod on sait pas trop comment ça fonctionne et ça marche ou ça marche pas je trouve que c'est hyper intéressant de savoir un peu comment ça marche derrière parce que nous ça peut nous permettre d'optimiser ou pas les choses, Et de mieux connaître aussi, on a des problématiques qui ne sont pas forcément les mêmes, et on peut aller dans le même sens, optimiser des choses. Donc pour revenir à la question, je pense que c'est très important, même si dans les ayatollahs, peut-être diront qu'il ne faudrait pas.
Benjamin:
[3:00] Mais il y a des problématiques notamment depuis la partie cloud, enfin depuis le cloud qui sont ton application elle peut être stateless ou pas stateless, elle peut mourir à tout moment et, se faire recréer ailleurs donc on va dire pour comprendre tout ce qui est, je vais prendre un exemple simple, le monitoring, pour comprendre le monitoring de ton app, il va se passer des trucs que tu ne comprends pas et si tu ne sais pas comment ça se passe derrière côté infra tu pourras pas comprendre donc voilà typiquement je vais avoir plusieurs instances en parallèle qui tourne de mon application il y en a qui meurent c'est normal recréé sa scale up down etc et enfin moi je trouve ça hyper intéressant de comprendre et pareil pour les releases un autre exemple c'est comment tu relises est ce que la release elle est en gros on arrête ton appli et on reprend la nouvelle version et elle redémarre ou est-ce que c'est en parallèle et en parallèle tu peux avoir deux versions concurrentes qui tournent en même temps le temps de la release quoi en.
Bruno:
[4:00] Fait il y a quelques temps j'ai reçu le responsable de l'équipe android de 10 heures, qui a fait un qui a tenu un propos sur ce podcast qui a généré un extrait vidéo qui a été les vidéos la vidéo la plus vue sur tiktok où il dit qu'il regrette de voir de plus en plus de dave qui connaissent pas la différence entre tcp et uidp, Alors, je suis conscient que ce n'est pas forcément des sujets d'un franc en tant que tel, mais tu vois, mais ça adresse ce sujet de, est-ce qu'il faut connaître des choses au-delà de simplement sa pure stack techno ? Je pense que les gens qui écoutent ce podcast, et c'est aussi pour ça que moi, je le fais, c'est parce qu'on est justement des personnes qui avons envie d'en découvrir un peu plus. Mais est-ce que tu penses, effectivement, comme lui et comme d'autres, que c'est une nécessité pour être un bon développeur, une bonne développeuse, de connaître d'autres choses ?
Benjamin:
[4:45] Oui, complètement. On ne va pas se mentir. Plus on connaît de choses, pas forcément dans le détail, mais les grands concepts. On ne va pas dire, ok, je connais Kubernetes, mais Kubernetes, il marche comme d'autres orchestrateurs dans les grandes lignes. Et de connaître un peu le fonctionnement de ces choses-là, on va dire la théorie, je pense que ça aide complètement. Comme quand tu es bac, si tu connais un peu comment marche un système de base de données, ça peut aider à faire des choses. Tu sais que derrière, c'est un SQL ou un OSQL, ce n'est pas forcément la même chose. et même si pour nous quand on l'utilise ça peut paraître assez abstrait etc derrière c'est bien de comprendre les mécaniques un peu internes pour optimiser ou comprendre des bugs.
Bruno:
[5:27] Attends j'ai une question qui m'a échappé Ah oui, toi qui donc as été dev et qui maintenant est sur des sujets d'infra, est-ce que tu te souviens d'une espèce de un moment, une épiphanie ou un truc où tu vois quand tu as découvert un peu tous ces sujets d'infra de manière quand même plus précise et plus approfondie où il y a un truc, un apprentissage où tu te fais ah ouais un truc de ouf en fait c'est ça.
Benjamin:
[5:50] Alors là j'ai pas en tête mais tu vois bah alors quand, chez Criteo on avait pas du cube on avait du Mesos et en gros on a dû basculer les applications qui étaient des applications on va dire clients lourds avec des bons vieux points exé sur des machines Windows où il y avait une machine Windows une appli, qu'ils ont fait la bascule pour passer sur Mesos justement tout le changement de paradigme de dire ok bah maintenant t'as un pool de machines ton app en fait elle peut tourner sur telle machine ou telle machine ça sera pas forcément les mêmes specs techniques, ça sera enfin voilà il y aura un startup il y aura des choses à faire, et tout ce paradigme là en fait de dire bah moi je ship un conteneur et le conteneur en fait n'importe quelle machine le prend et peut le runner ok après j'ai digué un peu sur toutes les parties comment fonctionne cube etc Et je trouve ça super intéressant, même si vous ne connaissez pas trop par curiosité. Il y a Émilie Vache qui a fait un petit bouquin très visuel sur les concepts de Cube et des orchestrateurs en général de manière visuelle et je trouve ça vraiment super intéressant à regarder.
Bruno:
[7:00] Pour revenir sur le sujet principal de cet épisode, où c'est de parler de génération de clusters et de tous ces outils qui vont autour, pour nous aider à plonger dans le sujet, est-ce que tu peux nous expliquer un peu ce que vous faites chez Covery ?
Benjamin:
[7:13] Ok, donc la genèse du projet, c'est en fait justement de dire, bon ben voilà, on a des devs d'un côté qui veulent shipper des choses rapidement et qui n'ont pas envie de forcément connaître tout comment marche chez un cloud provider pour s'étopper les machines, faire le provisioning, tous les problèmes de droit, etc. Donc l'idée c'était de dire, moi j'ai juste un repo git ou une image docker, je veux la chipper et je veux qu'en fait je puisse y accéder publiquement sur internet donc d'un côté on a ça et de l'autre on a, donc pardon l'idée c'est vraiment d'autoriser un peu d'abstraire cette couche là pour que n'importe quel dev puisse juste en mettant son repo guide vers clic clic et en gros son app est déployé sur un cloud provider est disponible sur internet.
Bruno:
[8:06] Avec une gestion automatique des problématiques de charge.
Benjamin:
[8:09] De réplication donc on va dire qu'on est opinionated c'est à dire qu'on va toutes les questions de comment je release, toutes les questions que t'as pas envie de te poser au départ on va te prendre un choix par défaut, et ensuite si tu as besoin de revenir dessus je vais te donner un exemple mais pour le réseau on va faire un réseau par défaut si demain t'as besoin de changer de réseau, changer des règles de réseau avoir un truc hyper fine tune tu pourras le faire, donc en gros l'idée c'est vraiment de, te shipper un cluster avec les bonnes pratiques par défaut ça marchera et ensuite si toi en fonction de tes besoins etc tu vas pouvoir fine tune ce truc là, en connaissant un petit peu ce qu'il y a dessous du cube donc tu ne seras pas limité quelque chose de flexible.
Bruno:
[8:59] On se disait au début que c'est nécessaire pour des devs de connaître ces sujets d'infra et de maîtriser au delà.
Benjamin:
[9:05] De simplement.
Bruno:
[9:07] Leur langage au final ce que tu permets c'est que justement j'ai plus besoin de me poser ces questions là et j'ai pas besoin de savoir en fait je te donne mon code et tu le.
Benjamin:
[9:16] Alors j'ai nuancé juste de dire tu n'as pas besoin de connaître la solution qui tourne dessous mais on va dire les grandes lignes, les bonnes pratiques il faut les connaître par exemple, ok ton application il faut que tu mettes un nombre de réplicas que tu dises comment elle scale etc ces choses là maintenant c'est des trucs qui sont on va dire acquis sur la partie cloud qui sont bien à connaître et ça on l'abstrait pas quoi.
Bruno:
[9:40] Est-ce que c'est sujet aussi de effectivement de clusterisation, de maîtriser Kubernetes et ces problématiques de scale, de comment est-ce qu'on scale, et peut-être même d'une certaine façon de containerisation, est-ce que c'est pas encore aujourd'hui réservé quand même à une certaine catégorie d'entreprise qui a une certaine volumétrie ? Ou est-ce que pour toi par exemple la containerisation ça devrait être day one, quelle que soit l'entreprise, on commence avec un environnement containerisé ?
Benjamin:
[10:09] En fait, je n'ai pas la réponse à la question, mais si je me mettais à la place, je ne vois pas de raison pour ne pas commencer avec une image, enfin avec un conteneur. Je ne vois pas à quel point ça peut aller plus vite de ne pas faire comme ça. Donc je dirais que de facto, oui, ça doit devenir un nouveau standard. Enfin, c'est le standard.
Bruno:
[10:29] Mais tu vois, cette notion aussi de réplication, de scaling de ton app, ça, c'est des problématiques qu'au final, assez peu de gens ont en vrai.
Benjamin:
[10:38] Bah si tu prends n'importe quel le même un site e-commerce il va dire j'ai un pic de trafic à cette heure là j'ai un pic de trafic pour black friday et c'est donc c'est des choses si alors forcément ainsi tu déploie quelque chose sur un héros coût sur un aws beaucoup plus managé genre, un ebs tu pousses tous les curseurs à max et ça va aller sauf que tu vas payer très cher et ça sera pas forcément en lien avec tes besoins donc je dirais que tu, Je dirais qu'on doit commencer là-dessus.
Bruno:
[11:13] À quel point est-ce que ces différents outils, ces différents orchestrateurs, te permettent de t'abstraire complètement des concepts de clusters, de réplication ? Le fait d'avoir quand même plusieurs machines qui vont tourner sur un même environnement, avec toute cette notion de serveur primaire, serveur secondaire, qui contient la source de vérité, toutes les données qui se dispersent. À quel point est-ce que ça te permet de t'abstraire complètement de ces sujets-là et de juste faire ton code sur ta machine et de te dire si ça marche là, normalement ça marche après derrière.
Benjamin:
[11:48] Alors la bonne nouvelle c'est que tu peux faire tourner un cluster cube sur ta machine, donc ça marche un local, du coup si ça marche sur ton cluster sur ta machine, il n'y a pas de raison que ça marche pas sur le cube déporté, alors je suis pas sûr d'avoir compris la question, mais par exemple sur les choix on va dire, nous par exemple sur les bonnes pratiques sur les clusters managés qu'on propose on va obliger d'avoir minimum 3 réplicas, donc 3 nœuds et en fait sur AWS par exemple tu as 3 zones par région c'est d'avoir un nœud dans chaque, région comme ça si tu as une région qui tombe tu as toujours de la redondance là où quand tu avais une machine, si le cluster il est out du coup tu perds tout et tu n'as pas cette histoire de redondance pareil, s'il y a une zone qui tombe enfin une zone dans la région qui tombe, tout sera mort si tu n'as qu'un réplicas là-bas donc en fait c'est on va dire des bonnes pratiques qui te permettent d'être beaucoup plus résilient, mais les devs ne se posent pas la question en fait c'est comme ça ça marche comme ils espéraient que ça marche mais derrière il faut savoir que c'est comme ça ils auraient pas forcément fait ce choix sans avoir buté une fois dessus.
Bruno:
[12:56] Mais du coup c'est des questions que t'as plus à te poser c'est du coup aussi des sujets que t'as plus besoin de connaître au final est-ce que ça peut pas être aussi un... Enfin, tu me diras, tu peux toujours faire l'effort de dire « Ok, j'ai envie de comprendre comment ça marche » et d'aller diguer. Mais ce n'est plus une nécessité.
Benjamin:
[13:15] Non, pas forcément. Après, ça dépend. Parce qu'imagine que tu fais tourner quelque chose dans une région en Europe, tu vas créer une base de données. Comment ça communique si ce n'est pas dans la même région, etc. Donc forcément, tu devras essayer de comprendre un peu l'histoire.
Bruno:
[13:31] Qu'est-ce que vous apportez comme abstraction ou justement comme concept, Kubernetes c'est quand même pas un outil qui est forcément hyper simple à maîtriser de premier abord pour un dev c'est un vrai outil professionnel donc il faut quand même un peu de training et de formation dessus, vous en faites quoi vous apportez une abstraction supplémentaire au dessus de Kubernetes ou comment ça se passe ?
Benjamin:
[13:55] Exactement, donc nous en fait on se base vraiment sur Kubernetes enfin on pense que c'est un super outil et qu'il n'y a pas besoin de, tout réinventer juste ce qu'on permet c'est pour avoir un peu une expérience comme sur Heroku mais sur ton compte cloud à toi donc par exemple, nous la solution elle est cloud agnostique donc par exemple tu pourrais dire, j'ai ma petite app pour faire mes podcasts c'est un conteneur forcément, du coup je vais la déployer sur AWS parce que il y a la région à paris je sais qu'elle est bien ça me coûte un peu plus cher mais voilà elle sera dispo ici, Et donc là, toi, tu vas juste mettre ton git ou ton container et tu vas pousser et ça sera bon. Donc nous, on va t'automatiser toute la création du cluster avec les bonnes pratiques. Donc ça, tu n'as pas besoin de t'en occuper. Et après, tu vas créer ton app pour dire mon repo git, il est là, mes paramètres, c'est là, l'URL, c'est ça, je veux mettre tel DNS, tel droit, tel setting, etc. Et ça va marcher. Là où après, nous, on va un peu plus loin et où c'est intéressant, c'est qu'on est cloud agnostique. Donc là, tu vas pouvoir dire OK, maintenant, AWS, ils abusent un peu. Ils ont vraiment augmenté les prix, je vais basculer chez Scaleway par exemple, donc tu vas prendre ton tu vas créer un cluster Scaleway.
Benjamin:
[15:09] Et en fait tu vas prendre ton premier environnement qui tournait chez AWS tu vas faire cloner, targeter le nouveau cluster Scaleway et en fait tout va marcher donc il faudra juste faire la bascule de DNS mais voilà, donc c'est pour abstraire un peu toutes ces problématiques là pour dire, voilà t'as besoin de dire, bah c'est chez AWS, il faut que je fasse ce réglage là, là c'est chez Scaleway c'est un autre réglage etc et après on ajoute, trucs, par exemple tes clusters, enfin tous tes environnements dev t'as pas forcément envie qu'ils tournent, H24, enfin la nuit tu vas pouvoir les éteindre pour faire des économies etc donc toute cette couche là, la couche de droite gestion des utilisateurs par exemple chez nous pour dire bah t'as un pool d'utilisateurs c'est des devs, t'as un pool d'utilisateurs c'est plutôt des SRE ou des devops qui vont avoir le droit de modifier la partie cluster etc donc on ajoute un peu, une couche sympa au dessus en plus d'avoir une UI un peu sympa. Parce que je sais pas si t'as déjà vu la UI côté console AWS, c'est très complexe, je trouve.
Bruno:
[16:09] C'est pas là où ils ont mis le plus d'efforts.
Benjamin:
[16:10] Après, elle marche très bien, c'est sympa, mais je trouve que c'est très compliqué.
Bruno:
[16:15] Et pourquoi ce choix de Cube, qui est pourtant pas la solution universelle dispo partout ?
Benjamin:
[16:23] Alors ce qui est intéressant ça ça vient alors là on est en train de voir que c'est quand même en train de devenir le de facto quoi là que ça soit du point de vue de la communauté, de tous les projets j'ai l'impression que ça devient un peu le standard et ça ça venait vraiment d'une on va dire des fondateurs de Covery, qui donc était il y en avait un chez Criteo qui a opéré du coup Mesos à assez haut niveau et en fait ils ont vu Kubernetes monter et en fait lui il a commencé à suivre le projet dès le départ, et même le mettre à scale et voir que ça marchait très très bien quoi donc c'était facile à opérer donc au début on peut l'opérer chez toi sur tes machines tu peux l'installer toi, et l'opérer toi et là nous ce qu'on fait c'est que, on utilise un cube managé donc c'est à dire qu'en gros on utilise la partie managé du cube chez AWS on va dire donne moi un Kubernetes managé c'est à dire que c'est eux qui gèrent toute la partie control play l'install des cubelets etc et donc nous on a juste on va dire l'API cube et on vient se mettre par dessus donc voilà et j'ai l'impression que tous les cloud providers la plupart supportent en une partie cube managée et donc ça pour moi ça veut dire que c'est en train de devenir le standard.
Bruno:
[17:38] Mais du coup parmi tous les autres alors ma question va peut-être pas paraître con mais parmi toutes les autres solutions qui existent il n'y a pas un moment où vous avez peut-être envisagé de se dire en fait, cette abstraction supplémentaire qu'on apporte. Parce qu'au final, tu aurais pu choisir n'importe quoi comme... Comme... Comme outil derrière vu que tu rajoutes une couche.
Benjamin:
[18:00] Oui non non bah là la question se pose pas à un moment mais peut-être qu'elle se posera mais là là non cube on trouve que c'est le bon compromis parce que, on peut l'administrer il y a plein de choses à faire, à côté et enfin ce que je veux dire c'est que c'est pas du tout lock-in c'est très flexible on pourrait créer un cluster cube avec Covery et Et après, dans quelques années, on dit, on débranche Covry et en fait, on opère ce cluster cube à la main et c'est nous qui faisons les choses. En fait, ce n'est pas limitant, on n'est pas du tout locké. Donc, c'est ça qu'on trouve intéressant.
Bruno:
[18:38] Et sur le... Attends, j'ai perdu ma question. Donc, vous, aujourd'hui, vous gérez plusieurs clusters, c'est ça ? Mais du coup, vous les opérez vous-même ou en fait, c'est chaque client qui...
Benjamin:
[18:50] Alors, nous, le pitch, c'est de dire là où sur un Heroku, par exemple, si tu crées ton cluster c'est sur l'infrastructure de Heroku, en fait t'as pas de notion de cluster mais si tu déploies ton app elle va tourner sur le compte cloud de Heroku, nous l'idée c'était vraiment d'être enfin pas non intrusif mais que les utilisateurs possèdent leurs données et leurs comptes cloud donc en gros nous quand les utilisateurs viennent chez nous, ils nous donnent un accès à leur compte cloud pour créer les clusters mais les clusters sont créés sur leur compte cloud donc s'ils nous coupent les accès en fait eux ils gardent tout ce qu'on a créé et ils peuvent vivre sans couvrir il n'y a pas de choses, du coup j'ai perdu le fil de ta question.
Bruno:
[19:29] C'était sur votre.
Benjamin:
[19:31] Niveau de.
Bruno:
[19:33] Gestion de ces différents environnements.
Benjamin:
[19:34] Voilà donc après on a plusieurs offres mais on va dire que la version standard c'est de créer en fait un cluster qu'on appelle manager c'est à dire que nous on va leur créer le cluster donc sur leur compte cloud, et on va gérer toute la partie embêtante de cube, c'est à dire les upgrades ils sortent une upgrade tous les 3 mois donc en fait c'est un peu la course, une version mineure donc là nous on est en 1.30, on sait que dans les prochaines semaines il y a l'1.31 qui sort donc en gros c'est nous qui allons opérer tout ça donc en gros on boot le cluster, on installe tout ce qui va bien pour qu'il puisse être opéré donc à savoir external DNS cert manager pour avoir les certificats les Nginx pour exposer, les apps, pour faire les LB, etc. En gros, il est prêt à être opéré.
Benjamin:
[20:27] Ça, c'est la version standard. Quand on dit qu'il est managé, c'est nous qui gérons la montée de version, les upgrades de Nginx, les upgrades de tout ça. Ça, juste pour se rendre compte, chez nous, c'est quasiment une personne à temps plein qui fait ça pendant trois mois pour chaque upgrade. Ça nous prend une ressource. Ce qu'on voit, c'est qu'on a pas mal de clients qui en reviennent parce qu'ils avaient un cluster cube, ils ont sauté quelques versions au départ, mais là après il faut qu'ils fassent une montée de version, il n'y a rien qui marche, il y a tout qui casse, et c'est vraiment un pain point, énorme, et t'as pas envie de... C'est pas ton coeur de métier, t'as pas envie de dépenser de l'argent là-dessus, donc tu le fais pas. Donc ça on va dire que eux c'est hands-on, ils déploient leurs apps, ils ont leurs clusters, et nous c'est nous qui nous assurons que tout marche, même que leurs apps soient dispo, enfin soit compatible sur la nouvelle version etc.
Benjamin:
[21:19] Et donc sur les clusters managers on a plusieurs centaines et donc nous chez nous, c'est nous qui nous occupons de faire les upgrades donc on va dire bah là aujourd'hui on a fixé quelque chose par exemple on va redéployer tous ces clusters et on va monitorer que ces clusters tournent bien que les apps des clients continuent de tourner etc, donc ça on a plusieurs centaines et après on a une autre offre où c'est ok on crée pas l'infrastructure pour toi parce que tu es une grande banque ou parce que tu as, ton fine tune de Kubernetes qui ne sont pas les mêmes que nous et où tu as envie de garder la main dessus tu vas dire ça c'est mon cluster mais moi j'adore l'expérience Covry, donc du coup je veux pouvoir déployer mes applications via Covry sur mon cluster que j'opère moi-même, Donc là, en fait, il va pouvoir installer le contrôleur Covery, dire mon external DNS, il est là, mon Nginx, il est là, j'ai mon cert manager, ça fait ça. Et en gros, après un peu de setup, il est prêt à déployer, enfin avoir l'expérience Covery sur son cluster à lui. Mais là, du coup, c'est lui qui gère la partie upgrade. Nous, on n'opère pas du tout son infra là-dessus.
Bruno:
[22:24] Quel est l'impact côté dev alors que ce soit qu'on utilise Covry ou d'autres outils, qu'on utilise directement Cube par exemple c'est quoi pour toi la différence d'impact sur le métier de dev au quotidien ?
Benjamin:
[22:42] Tu veux dire d'utiliser Cube ou de pas l'utiliser ?
Bruno:
[22:43] Cube ou Covry ou d'autres, versus pas l'utiliser éventuellement après on peut aussi imaginer utiliser rien de tout ça.
Benjamin:
[22:52] Bah en fait en tant que dev tu vois ça va un peu dans la mouvance de tout ce qui était on va dire devops dans la philosophie c'est de dire donc là maintenant c'est devenu un métier ce qui est un peu à l'encontre de la philosophie parce que du coup c'était de.
Bruno:
[23:05] Relier les gens entre eux.
Benjamin:
[23:06] Bah c'est ça en fait c'est toi qui qui construis le truc c'est toi de le shipper mais là du coup c'est d'autres personnes qui le shippent pour toi là en gros c'est de dire bah tu construis ton appli c'est toi qui connais et c'est toi qui va la shipper via Covery parce qu'en fait c'est toi qui va cliquer sur deploy c'est toi qui va citer les choses et tu vas voir un peu ce qui se passe, tu vas pouvoir suivre et c'est toi qui as les clés du camion, là où si tu n'utilises pas de solution, que ce soit covrir ou autre, en fait pour un dev ça ne va pas du tout être trivial de shipper, son appli parce que, ok, alors je la shippe où, comment je la shippe, comment je monite qu'elle a été bien shippée etc, toute cette couche là en fait c'est hyper intéressant mais ça te rajoute en fait, ok comment je fais.
Bruno:
[23:49] Mais tu vois, alors je sais pas si c'est un débat de vieux con ou pas mais je pense que c'est quand même un débat de vieux con, je vais commencer du coup la phrase comme effectivement un vieux con, moi à mon époque quand on voulait shipper effectivement une app en prod, il y avait tout un travail à faire, qui mine de rien t'obligeait à te confronter à des problématiques, t'étais obligé d'apprendre en fait les différentes couches les différents services que tu set up, monter un cluster c'était une tannée, enfin c'est-à-dire que c'était un ça prenait vraiment plusieurs jours, en tout cas quand on était incompétent comme moi, mais ça nécessitait en fait de te mettre le nez dedans et d'apprendre énormément de choses qui te servaient mine de rien après, plus tard, donc j'entends que ces outils sont une nécessité parce qu'aujourd'hui, de par l'explosion des trafics des demandes et des besoins, on peut plus créer des clusters à la mano et rajouter un serveur à la mano c'est plus gérable ça se fait mais il faut une équipe colossale pour réussir à manier ça, mais il y a effectivement parfois l'impression que c'est aussi une perte d'apprentissage, pour toute une population qui n'a plus besoin de se confronter à ces problèmes là.
Benjamin:
[25:07] Oui bah c'est sûr après tu vois tu dis bah tu montes un cluster ok ça va t'embêter un coup mais après qui l'opère c'est à dire que toi, faire passer les patchs de sécurité sur ton cluster que t'as monté à la mano 3 ans avant enfin tu vois tout ça c'est des trucs que t'as pas enfin c'est déjà alors potentiellement t'as envie mais de deux est-ce que t'as les compétences, est-ce que t'es sûr qu'en gros au niveau sécu, c'est les bonnes pratiques etc, en fait pour moi c'est du temps que tu perds sur autre chose, alors t'as la main, tu comprends c'est sûr, mais je sais pas si c'est optimisé et optimal pour les boîtes tu vois, tu vas monter ton projet toi tu veux juste faire une appli qui fait un tout petit truc, mais tu vas devoir te poser la problématique de ok comment j'installe mon cluster, qu'est-ce que je mets comme, enfin tu vois, qu'est-ce que j'installe comme l'autre balancer, comment je fais, etc. En fait, j'ai l'impression que de faire comme ça, tu es obligé de te poser un milliard de questions qui devraient arriver normalement beaucoup plus tard. Day one.
Bruno:
[26:08] Oui, mais en même temps, c'est des questions qui ont... On est là aussi justement pour apprendre. Je trouve que c'est des questions qui apportent beaucoup de... Je trouve que c'est des questions intéressantes à se poser.
Benjamin:
[26:18] Oui, bien sûr. C'est bien, mais après, ça dépend où est-ce que tu places le curseur.
Bruno:
[26:25] Donc toi du coup t'as été t'es arrivé chez Covery parce que t'avais déjà commencé à te poser ces questions là et t'avais envie de bosser sur des sujets d'infra, où toi au final tu te dis moi je suis un dev back et le contexte au final, change et pas forcément important plus que ça mais ça t'a permis quand même d'apprendre aussi plein de sujets côté infra.
Benjamin:
[26:48] Moi j'avais comme la plupart des devs j'avais un petit pet project à côté avec mon petit cluster cube, et pareil ça a bien marché puis après au bout de 3 ans vas-y faut faire l'upgrade du coup tu dois changer, tu dois changer donc j'utilisais Traifee qui est à la base après ils ont changé de version etc c'était le bazar donc fallait changer tout ça sans interruption et c'est là que je me suis dit non mais en vrai c'est cool mais là c'est un pet project et je suis en train de faire des trucs de fou juste pour ça, et c'est là que j'ai rencontré le CTO donc Pierre parce qu'il bossait chez Crito aussi j'ai dit ah t'avais fait un blog post sur tel truc et on a commencé à parler un peu comme ça et c'est là où j'ai vu la vraie valeur, de Covry ou des orchestrateurs de manière générale de dire ok moi c'est pas mes compétences j'ai pas envie de me focus là dessus et j'ai envie d'avoir la main je peux aller voir si je veux y'a pas de problème mais c'est pas je veux pas faire ça, pour un pet project de un week-end monter le truc c'est marrant pour comprendre mais j'ai pas envie de l'opérer pendant 5 ans derrière quoi.
Bruno:
[27:54] Et puis le côté c'est marrant en fait une entreprise elle s'en fout un peu du côté c'est marrant de gérer ton project.
Benjamin:
[28:00] C'est ça mais après du coup voilà le truc c'est que tu peux mettre la complexité où tu veux si t'as envie de gérer l'infra et de tout fine-tuner tu peux le faire parce que c'est, nécessaire pour ton business et que tu penses que s'il faut oui enfin tu vois après on pourrait partir du truc bah pourquoi tu codes pas tes drivers sur tes routers parce que enfin tu vois voilà à chaque fois c'est toujours la même question oui.
Bruno:
[28:24] C'est vrai que j'entends la question c'est vrai qu'on peut aller effectivement extrêmement loin dans l'optique de se dire si tu veux tout faire fine fais tout mais en fait le moins de projets te prend deux ans.
Benjamin:
[28:34] Pour moi maintenant le cloud c'est un nouveau service, et en gros toi c'est une nouvelle couche d'abstraction de dire donne moi une base de données managée je sais pas comment l'installer je sais pas comment aller opérer mais je sais que ça marche parce que c'est toi qui gère les réplicas les backups, les snapshots etc et voilà c'est une mise à dispo de service et nous en fait après on se base dessus en fait tu sais comment ça marche mais toute la partie embêtante de gestion des problématiques c'est fait par des gens qui savent faire donc le cloud provider typique.
Bruno:
[29:12] Attends j'essaie de formuler parce que, je suis toujours un peu alors peut-être que je reviens sur le même sujet, mais en fait je trouve qu'effectivement ça apporte une, facilité dans le métier, parce qu'effectivement comme tu le dis au final moi je m'en fous de savoir si j'adresse le serveur 1, le serveur 2 ou le serveur 4000 moi ce que je veux juste c'est accéder à ma donnée et pouvoir te faire un update quand j'en ai besoin, donc ça j'entends que ça apporte effectivement énormément de confort au dev, mais tu parlais aussi tout à l'heure de DevOps la philosophie de DevOps c'est quand même de rapprocher ces deux métiers pour qu'ils communiquent mieux ce côté de dire au final, tu t'embêtes plus de tout ça et on le fait à ta place il y a aussi un peu un côté de dire ok en fait on sépare nos métiers, chacun fait ce qu'il a à faire et les vaches seront bien gardées.
Benjamin:
[30:13] Alors c'est marrant je le vois pas vraiment comme ça parce qu'en fait t'as la partie infra où oui spawner de l'infra créer de l'infra, faire la partie réseau, etc. Ça, pour moi, c'est vraiment le métier d'infra. Et pour moi, la partie DevOps, c'était OK, on connaît un petit peu d'infra, On connaît un petit peu de code. Et en fait, nous, notre but, c'est qu'on prend ce code-là et on le balance sur notre infra. Et là, ce qu'on est en train de dire, c'est de dire si tu es un DevOps, en gros, tu vas pouvoir utiliser notre techno parce que ça va te simplifier la vie. Et si tu es dev, c'est super parce qu'en fait, c'est toi qui va cliquer sur le bouton et c'est toi qui own ce truc-là, en fait. Mais sans aller dans l'infra.
Bruno:
[30:49] Ok, je vois. Canon. Il y a aussi un autre aspect qui nous touche, nous, en tant que dev. C'est toute la notion de staging qui est parfois selon l'entreprise, selon les contextes des sujets plus ou moins maîtrisés, plus ou moins faciles à aborder avec ces environnements là comment ça se passe dans un environnement avec Covry ?
Benjamin:
[31:13] Alors tu as plusieurs choix, nous ce qu'on préconise on voit souvent les clients qui ont on va dire deux clusters allez trois clusters ils ont un cluster de dev donc là c'est là où ils vont pouvoir spawner leur preview en, donc ça je vais y revenir, un cluster de staging où ils font tourner leur pré-prod, juste histoire d'isoler et après un cluster de prod où ils font tourner tout ce qui est prod après tu peux faire tout tourner sur un seul cluster, c'est safe il n'y a pas de problème mais l'idée c'est d'avoir des choses imagine tu fais quelque chose de vraiment déjà tu as envie de pouvoir faire scaler de manière différente ton cluster de staging du cluster de prod, et pour des on va dire des règles de gestion de droit etc ça nous semble beaucoup plus pertinent d'avoir des clusters différenciés bah tu vois typiquement pour les upgrades, là les dernières upgrades qu'on a fait donc on a fait un 29 un 30, nous on va dire à nos clients on va vous passer l'upgrade de cube sur vos clusters de pré-prod donc de staging, deux semaines avant de faire sur votre prod comme ça eux ils ont le temps de voir donc nous on va monitorer que tout s'est bien passé mais après eux s'ils ont, s'ils découvrent des comportements bizarres sur leurs apps, au moins ils ont le temps de voir alors que si t'as qu'un seul cluster et que ça se passe pas bien, ça se passe pas bien.
Bruno:
[32:36] Et donc du coup, on peut payer autant de staging dont on a besoin ?
Benjamin:
[32:40] Voilà, exactement. Donc imagine-toi, tu vas créer ton cluster, donc tu as besoin de ton projet, tu vas faire ton truc vite fait, tu vas déployer ton app, et là tu vas dire, en fait, ça serait trop cool de pouvoir avoir une version staging de mon app. Donc soit tu fais un clone de ton app qui est en prod, et en fait, tu vas pouvoir targeter ton cluster et dire, ça c'est ma version staging. Et donc pareil, on a la notion d'environnement. Donc en gros, ton environnement, tu vas avoir ton app, ta base de données, ton front par exemple donc ça, ça fait une grappe, et en gros, dans ton app nous on va exposer le lien vers ta DB, le lien de ton front etc, toutes ces choses là et si tu le clones, en fait on va aussi, réécrire ces liens là donc ça veut dire que tu vas pas avoir besoin de te redire, ah c'est quoi la nouvelle URL de ma DB le nouveau mot de passe, utilisateur de etc, en gros ça tu n'as plus besoin de le faire c'est à dire que ça va marcher automatiquement c'est à dire que ton app de staging elle va taper ta db de staging donc on va tout recréer, et donc pareil sur le cluster tu vas pouvoir dire ça tourne sur le même cluster ou sur un cluster c'est pareil, donc en gros ça prend littéralement 3 secondes.
Bruno:
[33:48] Parce qu'en fait pour vous et de manière générale pour un orchestrateur que ce soit un environnement de prod, de staging, de preview de ce que tu veux c'est pareil.
Benjamin:
[33:59] C'est la même chose vu que t'as pas le même scale sur la preview ou sur la prod, tu n'auras pas forcément les mêmes machines, les mêmes tailles de machine, tu n'auras pas forcément les mêmes ressources. Tu vois, ton appli de prod, tu vas lui allouer beaucoup plus de mémoire ou beaucoup plus de CPU ou beaucoup plus de réplicas que sur ta staging. Donc, ça te permet de faire ça.
Benjamin:
[34:19] Mais donc, ça, c'est assez intéressant parce que du coup, tu clones exactement ta prod, tu changes les quatre valeurs de variable d'environnement que tu as besoin et ça fonctionne. Et après, de la même façon, on a une feature qui s'appelle donc pour les previews env, là en gros c'est t'as ton appli avec ta grappe, et tu vas dire moi j'ai fait une PR là sur cette app et en gros je veux tester ma version de cette app là, donc en gros on va recréer un environnement, parce qu'on sait que tel environnement il a besoin de tel DB tel front et en fait on va spawner un environnement entier, sur ton cluster avec ta version, donc t'auras ta version patchée de l'appli, avec ta version de la DB avec tes données etc ou ta version patchée de l'ADB tu vas pouvoir tester vraiment en silo depuis ta PR, en gros sur les PR par exemple sur Github tu vas dire, slash PR release et en gros il va spawner un environnement de preview, toi tu vas pouvoir aller cliquer on va mettre directement les liens les DNS etc tu vas pouvoir aller voir et à la fin quand ta PR elle émerge on shoot la preview et toi tu peux aller l'arrêter parce que c'est le soir etc mettre des règles pour dire mais preview ne tourne pas le soir mais pour tout ce qui est parti recettage et tout c'est très pratique.
Benjamin:
[35:33] Donc ça c'est le use case des previews et après même pour la partie prod pour faire les migrations par exemple t'as envie de changer de région AWS t'es à Paris mais t'as envie de potentiellement ouvrir les US, tu fais un clone et t'auras ta production qui est répliquée aux US de la même façon que ce soit juste sur le même cluster ou tu crées un cluster différent et tu déploies. Donc, les migrations se font vraiment... Enfin, on a plein de clients.
Bruno:
[36:05] Alors, du coup, sur ces clones, est-ce que aussi, de manière automatique, tu peux mettre en place des réplications d'un clone à l'autre pour que, par exemple, ta région Europe, soit automatiquement répliquée quand t'as une donnée qui est modifiée en Europe soit aussi modifiée.
Benjamin:
[36:20] Pour tout ce qui est environnement de preview et les choses où c'est pas important de perdre la data on va pas spawner des vraies bases de données parce que ça coûte cher, on spawn des versions, conteneurisées des bases de données donc il y a un volume et tout ça mais c'est pas répliqué et après pour vraiment faire de la prod nous on prône le fait d'utiliser le service managé d'AWS ou des cloud providers parce que ça ce sont des, problématiques des cloud providers, de dire je mets ma base de données, je gère la main et les autres comme ça, la réplication c'est comme ça, ça c'est pas nous qui gérons.
Bruno:
[37:01] Je trouve ça intéressant que vous aussi de la manière que le dev va s'épuyer sur vous pour faire tout un tas de trucs et à un moment vous aussi vous dites on va s'épuyer aussi sur.
Benjamin:
[37:10] La personne en tout tu vois on a plein de personnes qui nous disent ah bah tiens j'ai une base de données je veux, je veux la cloner ailleurs ou je veux bah comment je fais bah si c'est une base de données de prod enfin tu vois t'as plein de problématiques de comment tu la migres parce que le temps que tu la migres du coup c'est à dire qu'elle va être offline si tu mets les deux en parallèle comment tu fais la réplication des données pendant que l'autre elle est en train enfin comment tu fais ça c'est vraiment des problématiques qui sont, enfin pas dans notre qui sont intéressantes qui sont très intéressantes mais c'est Alors déjà, c'est très touchy et c'est un métier.
Bruno:
[37:47] Donc du coup dans le volume de ce que vous vous gérez à quel point est-ce que vous utilisez votre propre solution pour gérer parce que du coup il y a aussi un effet de cascade en fait.
Benjamin:
[37:58] Donc nous tous nos clusters à nous qu'on utilise en interne notre control plane pour gérer les déploiements des clients etc tout est géré avec notre solution, donc là au début on gérait un peu tout à la main avec des fichiers Terraform et des déploiements à la main et là plus le produit a évolué ça nous a permis aussi de voir les limitations de notre produit et dire mais en fait, on devrait arriver à gérer ça pour nous donc en fait on a déployé les fonctionnalités pour le faire tu vois, mais on va dire 90% de notre infra à nous est gérée, comme celle de nos clients nos clusters sont managés par nous et après les 10% restants c'est toujours un peu le sujet d'œufs et de poules c'est à dire qu'en gros t'as quand même envie de garder la main si jamais on venait à shipper quelque chose de vraiment très, planté parce que si nous on est plus capable avec notre solution de redéployer notre solution en fait du coup tu vois si le covry serait mort quoi, donc on a une partie on a 10% de réserve sur ça c'est vraiment notre corps corps et on veut pas y toucher enfin c'est nous qui gérons à la main, enfin alors à la main c'est pas vraiment à la main mais on va dire c'est pas managé quoi.
Bruno:
[39:13] Mais donc du coup vous avez un cluster de cluster d'une certaine façon.
Benjamin:
[39:17] Ouais alors on a pas un cluster de cluster on a en fait un on a un cluster avec le control plane, et nos solutions donc en gros nous le control plane c'est donc on a un front end le control plane c'est de dire, ok tel client veut déployer un cluster ou son app sur son cluster et c'est lui en fait qui va spawner les builds et les déploiements et donc ça c'est ce qu'on appelle le control plane et on a un cluster de control plane.
Bruno:
[39:49] Ok je vois, et sur ces sujets de de comment dire de volumétrie, donc toi tu nous dis en fait que ces sujets de scaling au final c'est des sujets que tu peux te poser effectivement day one c'est quoi, la taille moyenne des clusters que vous gérez aujourd'hui ? Est-ce qu'on parle de 2, 3, 4, 5... 5 nœuds ou 2 nœuds ?
Benjamin:
[40:19] Alors là c'est là que c'est hyper intéressant c'est que nous plus ça va plus on est en train de, s'abstraire de la notion de nœuds aussi parce que du coup que ce soit sur, GCP en gros ils ont sorti un truc qui s'appelle autopilot et en gros c'est eux qui gèrent les nœuds et en fonction de ton workload donc je te donne l'exemple, juste pour répondre à la volumétrie on va dire 50% des clients ça va être entre, 3 qui est le minimum et 10 nœuds, après on en a qui sont entre 10 et 20 on va avoir aller jusqu'à 90% et après on a les très gros qui ont nos limites, en sachant que le nombre de nœuds fait pas à foi parce qu'on a notre plus gros client.
Benjamin:
[41:07] Un de nos plus gros clients qui ont des nœuds totalement énormes donc ils en ont peut-être 20 mais les nœuds sont les plus gros nœuds que tu puisses prendre quasiment sur AWS.
Benjamin:
[41:18] Et donc là ça pose plein de questions parce qu'après tu vois nos clients ils utilisent par exemple Datadog donc après tu as aussi des optimisations à faire parce que Datadog tu payes par nombre de nœuds donc tu aurais intérêt à avoir, tu as un scale ou en gros tu as intérêt à avoir moins de nœuds pour payer, moins de Datadog en gros bref et donc côté AWS donc c'est Carpenter la feature qui sont en train de sortir et en gros là l'idée c'est de dire au lieu de dire j'ai 3 nœuds et tu choisis une taille unique pour chacun de ces nœuds c'est de dire, je vais m'adapter en fonction de ton workload, donc ça c'est pareil c'est la tambouille de Amazon ou de GKE, lui il voit ok le client il fait tourner tant d'app il y a besoin de 10 CPU et 46 gigas de RAM et en fait c'est lui qui va, spawner la machine qui va s'adapter au plus proche de ce que toi tu consommes vraiment.
Benjamin:
[42:16] Tu vois ce que je veux dire ? Donc en gros, par exemple, tu vas pouvoir avoir une très grosse machine et à côté, une petite. Tu vas redéployer, ça va demander plus. Donc il va enlever la petite, il va mettre une moyenne ou il va dire, là maintenant, c'est plus cher d'avoir une grosse et une moyenne que d'avoir trois moyennes. Donc en fait, il va changer ça à la volée. Et donc là où c'est intéressant, c'est qu'ils vont gérer aussi, que ce soit Google, Azure ou AWS, ce qu'on appelle les spot instances. Donc c'est les instances à la demande où en gros, tu payes moins cher, mais si quelqu'un paye plus cher l'instance ton instance elle va être rapatriée.
Bruno:
[42:50] Donc ils vont te l'enlever.
Benjamin:
[42:52] Et donc elle va disparaître et il va devoir t'en recréer une et donc ça en termes d'économie pour les clients c'est énorme en gros toute la couche de gestion de nœuds maintenant nous on dit c'est AWS qui le gère.
Bruno:
[43:05] Ou GCP à quel point est-ce que tu penses qu'on va terminer dans un monde où nous en tant que dev on sera tellement éloigné de ces sujets là, qu'on pourra écrire notre code dans n'importe quel langage qu'on a envie et juste le pousser quelque part et du coup notre base de données tu t'embêteras même plus à te poser la question de est-ce que je fais du SQL, du NoSQL, ou est-ce que je range mes données c'est juste tu dis là j'ai un bout d'information que je veux récupérer, là je veux le poser et que juste, tu donnes tu vois au final c'est des lambdas quoi ouais bah c'est déjà un peu le cas ouais c'est déjà un peu le cas avec les lambdas pour la donnée est-ce que à quel point ça va devenir la norme.
Benjamin:
[43:49] Je pense que ça l'est déjà un peu. C'est juste qu'après, nous, on a beaucoup de clients qui étaient sur ces solutions-là, qui après, ils se posent des problématiques, soit de tarifs, parce qu'en fait, c'est beaucoup plus cher, de vendeur lock-in aussi, parce que, tu vois, autant Kubernetes, c'est agnostique, c'est supporté par tous les cloud providers, donc tu prends un cluster kub qui tourne quelque part, tu le prends, tu le déplaces ailleurs, il marchera, quelques exceptions près. Mais tout ce qui est lambda, le cloud run, ça, c'est vendeur lock-in. Donc là t'es menotté à ton cloud provider et tu peux pas trop changer donc je pense qu'il y a aussi un peu ces problématiques là de dire bon bah déjà ça me coûte très cher j'ai pas la flexibilité que je veux parce que tu vois bah typiquement EBS chez AWS c'est une solution où ils font plus d'évolution je crois, et quand t'atteins un certain scale en fait ça ne marche plus et toi du coup bah t'as un truc qui est simple mais tu fais un truc très très très très compliqué, pour arriver à gérer ton use case qui devient monstrueux quoi donc après bah tu veux pouvoir fine-tuner et voilà donc après c'est toujours la même en fait tu veux que ce soit simple mais tu veux pouvoir find-tuner donc c'est toujours un peu ce truc schizophrénique.
Bruno:
[44:56] Qui est le fameux dilemme permanent des devs c'est qu'on veut un truc simple mais pas trop simple non plus.
Benjamin:
[45:00] Voilà c'est ça exactement.
Bruno:
[45:03] Canon merci beaucoup Benjamin pour cette discussion j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeurs.
Benjamin:
[45:13] ? Oui alors j'avais noté j'avais noté, en gros un bouquin pour sortir un peu enfin qui ne sort pas vraiment de la tech mais qui s'appelle Delivering Happiness il est assez vieux mais en gros c'est un peu l'histoire de Zappos la start-up, aux Etats-Unis qui a ensuite été racheté par Amazon mais en gros c'est un peu ils commencent dans leur garage.
Benjamin:
[45:42] Je ne sais plus s'ils sont deux ou trois d'ailleurs mais c'est un peu l'ascension de la boîte et toutes les questions que tu vas avoir au milieu le rachat, l'embauche des premiers employés déménagements etc et je trouve que bon ça s'applique à la tech mais c'était très sympa c'est un récit un peu startupper qui est hyper inspirant ça c'est le premier truc, et ensuite, j'avais noté alors je suis très consommateur de youtube et je suis beaucoup la chaîne CoreDump donc c'est quelqu'un qui explique très très bien, les concepts un peu de base de l'informatique, donc tu vois un thread, un process, etc, donc lui il y a vraiment du contenu de très très bonne qualité, et après de notre côté nous on fait quasiment, enfin on fait beaucoup de Rust et il y a une chaîne Youtube qui s'appelle Tantan, et donc T-A-N-T-A-N et alors là il est un peu barré lui mais il fait du jeu vidéo en Rust, donc moi je connais pas du tout le jeu vidéo mais c'est toujours quelque chose où je me suis dit bah tiens j'aimerais bien savoir comment c'est développé et on va dire qu'il vulgarise un peu ce truc là et il a recodé, une partie de moteur de jeu vidéo en Rust justement donc en gros t'as un peu toutes ces problématiques là et il fait de manière un peu marrante et pédagogique donc je trouvais ça cool Ok.
Bruno:
[46:59] Puis intéressant d'utiliser Rust pour faire du jeu vidéo pour le coup c'est inattendu Exactement On mettra les liens bien évidemment en description et dernière question de loin la plus importante Benjamin est-ce que tu es plutôt espace ou tabulation ?
Benjamin:
[47:14] Je suis un peu embêté parce que c'est une question qu'il faudrait poser à mon linter mais en gros je laisse faire le linter mais je pense que je serais plutôt espace Ok.
Bruno:
[47:22] Très bien. Merci beaucoup Benjamin.
Benjamin:
[47:24] Merci à toi.
Bruno:
[47:25] Et merci à tous d'avoir suivi cette conversation Voilà, l'idée c'était effectivement d'apprendre des choses sur le fonctionnement de Cube, si vous connaissiez pas déjà. Donc j'espère que ça vous a aussi amené à vous poser des questions. N'hésitez pas à vous... à diguer encore plus tes sujets. C'est des sujets qui peuvent être effectivement très prises de tête, mais qui peuvent aussi être hyper passionnants. En tout cas, je vous remercie beaucoup je vous souhaite une très bonne fin d'année des bonnes fêtes de fin d'année, parce qu'on sera prêt dans dans ces périodes-là.
Bruno:
[47:53] C'est aussi une très bonne année 2025 qui arrive. Je vous remercie comme toujours de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.
