Dev'Obs #14 / Kubernetes, révolution ou buzz marketing ?

C'est d'abord une culture. Quand on est en DevOps, tout le monde DevOps et Agile font effectivement partie de la même famille. Sa virtualisation applicative s'est très bien. Aujourd'hui, ça nous prend dix minutes et un café. Ce n'est ni être, ni être, c'est avant tout la communication. Ce mouvement DevOps, c'est tout simplement drivée par la communauté et endossé par les entreprises. J'ai adopté une démarche DevOps, le développement agile. On a accéléré déploiement.

Ça amène une clarté sur le travail de l'être dans une démarche d'amélioration qu'on se retrouve face à des familles naturellement ensemble, ça donne des résultats concrets, des box. L'objectif individuel, ça s'atteint, alors que l'ambition,

ça se partage. Bonjour les DevOps. Alors aujourd'hui, petit aparté inhabituel avant le début du podcast, juste pour vous dire que celui ci, comme vous l'avez sans doute vu, est assez long plus de 3 h, mais il est aussi extrêmement dense et riche en informations, donc n'hésitez pas à l'écouter sans doute en plusieurs fois, revenez dessus, mais je suis sûr que vous apprendrez quelque chose.

Au moins, ça vous donnera plus d'informations sur ce que les gens peuvent penser, aussi bien des conteneurs que de Kubernetes d'ailleurs, et même globalement de l'état de la tech à l'heure actuelle en France et dans la Silicon Valley. Donc n'hésitez pas à venir nous voir, à commenter et également à venir participer. Soyez le prochain interlocuteur, que ce soit de manière ponctuelle ou régulière.

Je suis sûr que vous avez des choses à dire sur le DevOps, une opinion différente ou pas d'ailleurs de la nôtre. Donc n'hésitez pas, venez nous voir. Et sur ce, je vous laisse avec le podcast. Bonjour à tous et à toutes et bienvenue dans le 14ᵉ numéro de DevOps. Alors on est super en retard, ça fait presque un an qu'on n'avait pas fait de numéro donc désolé à tous. En plus, j'ai même reçu plein de messages pour me demander un nouveau, un nouveau numéro. Nous voilà!

Et donc si jamais vous aussi vous avez envie de venir parler d'un sujet autour du DevOps ou même d'ailleurs autour de Kubernetes dans le podcast dans ton cube, n'hésitez pas à venir. C'est vraiment ce qu'on recherche des gens autres que nous pour parler. On n'a pas envie de faire un entre soi, donc c'est vraiment l'intérêt de venir et de proposer des sujets ou quoi que ce soit. D'ailleurs. On sera début du mois de février au FOSDEM. Donc s'il y a des gens qui sont qui sont au FOSDEM,

n'hésitez pas à venir nous voir. On pourrait même faire un épisode spécial à ce moment là. Il y a du temps au FOSDEM donc n'hésitez pas à nous pinguer, on pourra s'organiser un petit moment là dessus et. Et voilà pour les news. Et on commence donc cet épisode sur Alors épisode à troll sur Kubernetes révolution ou buzz marketing et autour de la table, nous sommes quatre. Je vais laisser chacun se présenter en commençant par le nouveau Quentin.

La première personne, la seule personne qui n'est jamais venue avant dans un désert, dans un DevOps. Je vais te laisser te présenter. Bonjour à tous, je m'appelle Quentin Adam. J'ai le fameux pseudo imprononçable sur Twitter, ce qui pour les spécialistes en fait est un pattern. Quand tu es sur un clavier azerty et que tu te faisais bien chier quand j'étais ado.

Et en fait je dirige une boîte qui s'appelle Clevercloud qui fait un outil d'automatisation forte des infrastructures de façon à libérer du temps pour les OPS, permettre au dev d'aller plus vite et renforcer l'infrastructure. Super! Et les deux anciens, les deux anciens. Barthélémy Osmond, un vieux de la vieille du DevOps. Récemment, j'ai rejoint une nouvelle petite start up qui s'appelle Store Lift et qui propose des magasins

autonomes, tout simplement. Avant, tu étais chez Criteo pour rappel, donc un peu de Kubernetes et beaucoup de débrouillardise. Et Jérôme Delahaye? Je suis chez BNP Paribas et on s'occupe de toute la partie cube et maintenant super! Et donc moi Guillaume Letteron et je suis toujours indépendant, je fais toujours du Kubernetes, etc. Et c'est ça fait la transition et c'est pour ça qu'on est là. Alors pourquoi ce sujet aujourd'hui?

Alors il fait suite à un tweet que j'ai envoyé la semaine dernière d'ailleurs, une série de tweets sur Kubernetes, en disant bien que. Enfin, en disant de mon opinion que Kubernetes, c'était donc maintenant assez vieux puisqu'il a même cinq ans et demi, que ce n'était plus un sujet hype et que globalement, maintenant, en 2020, c'était vraiment, enfin c'était pour moi un non-sujet que que Kubernetes.

Et donc s'en est suivi une, une longue, longue thread extrêmement touffue et poilue pour le coup, puisque en fait des arguments, enfin des échanges d'idées plus ou moins bien faits on va dire, ont été, ont été échangés. Et ça me permet d'ailleurs de rappeler une règle qu'on a ici, je pense, assez implicite, qui est qu'en fait je pense qu'aucun d'entre nous troll en fait, c'est à

dire qu'on a des avis différents. Mais ce que j'aimerais ici, et je pense que c'est le cas de Quentin, et c'est le cas entre tous, c'est tout ce qu'on dit, on le pense, on ne le dit pas pour faire, pour faire enrager les gens en face. On a le droit de ne pas être d'accord, mais on ne fait pas pour enrager les autres. C'est juste on n'est pas d'accord et c'est très bien. Et ça ne va pas nous empêcher justement de faire une table ronde comme ça, d'aller prendre un verre, d'aller manger ensemble.

Et c'est quelque chose dont on a le droit de pas être d'accord et pourtant de pouvoir de pouvoir discuter, c'est quelque chose d'important là dedans. Et. Et justement, cette divergence là, en fait, suite à toutes ces opinions, suite à toutes ces discussions, on est arrivé en fait à un. Point, notamment avec Quentin où on arrivait sur des divergences profondes, en fait sur des divergences. On a vu que là, à ce point là,

on n'était pas d'accord. Et je pense qu'au lieu de moi, parler et de dire ce que c'était, je vais laisser peut être Quentin expliquer, lui, la vision qu'il avait de la suite des événements, de manière très succincte, si jamais tu devais te résumer, moi je vais résumer de mon côté, mais j'aimerais bien avoir un autre, un autre point c'est ça. Non mais là, pendant une minute ou deux, juste juste après, on va revenir dans le sujet plus du débat qu'on pourrait avoir et même techniquement,

parce que je sais qu'on m'a aussi demandé d'être un peu plus technique. Je pense que c'est un sujet qui est à la fin, qui est éminemment technique en fait. Je pense que là, je pense que la divergence est assez simple. Pour moi, une infrastructure aujourd'hui doit s'autogérer, c'est à dire que tu as des humains, Donc les humains sont des gens magnifiques mais profondément imparfaits.

Et aujourd'hui, ce qu'on demande à une infrastructure, c'est de délivrer 100 %. Ce qui veut dire que s'il y a des humains sur la prod, ça ne peut pas marcher. C'est statistiquement impossible que ça se passe bien. Donc il faut supprimer les humains de la prod pour supprimer les humains de la prod. Il y a plein de solutions, mais la meilleure des solutions, c'est probablement un usage

massif et statistique. C'est à dire qu'il faut faire un cœur qui soit basé sur soit de la récurrence, soit de l'apprentissage statistique, ce qu'on appelle aujourd'hui du machine learning ou de l'intelligence artificielle. Je sais qu'on s'est fait chambrer parce que notre nouvelle baseline, c'est i-power DevOps, mais c'est

littéralement ce qu'on fait en fait. C'est à dire que nous, on a foutu un cœur statistique qui réagit à des règles statistiques préétablies de par un apprentissage pour faire fonctionner la prod. Et c'est littéralement ce qu'on fait. Et je pense que pour obtenir une infrastructure qui fonctionne bien et qui fonctionne de façon autonome, qui libère les gens à la fois des conflits internes, des boites, parce que je pense que le conflit entre le fameux ce qu'on appelle

dev et ops n'a pas été souleve. Quand on a dit DevOps, ça a été réglé dans certaines boites où ils ont fait le truc qui permet à DevOps de fonctionner, c'est à dire fusionner les budgets et les équipes. Mais tant qu'il y aura deux équipes séparées, ça ne marche pas.

Et alors il y a un autre truc qui s'est produit dans certaines boites, c'est à dire qu'au début tu avais deux équipes et là maintenant il y en a une troisième qui s'appelle DevOps, qui est censée faire le lien, qui a son propre budget, ses propres insights, sa propre façon de bouger, ça ne marche pas du tout. C'est toujours pas la bonne stratégie. Si vous voulez que ça fonctionne,

il faut fusionner les équipes. Et donc moi je pense que pour aller vers ça, il y a eu des choix technologiques de prix il y a quelques années, qui sont à mon avis des échecs qui ont déjà été des échecs dans l'histoire informatique et qui à mon avis sont des dead end et qu'on est en train de payer les pots cassés de ça et qu'on va encore les payer pendant quelques années avant

d'avoir la paix là dessus. Voilà. Alors c'est bien parce que tu arrives justement dans notre premier point et qui est donc la suite de de notre discussion, qui était justement ce dead end technologique. Tu as employé le terme là dedans et donc la question, la question qu'on peut se poser c'est justement donc est ce qu'il y a un sens à l'innovation? Et je vais donner mon avis là dedans qui rejoint le tien, c'est que je ne pense pas, enfin, qui est en contradiction. Je ne pense pas qu'il y a des

dead end technologiques. Je pense qu'en fait toutes les technologies apprennent les unes et les autres. Ces technologies là d'ailleurs s'entrecroisent et en fait il y a une dépendance au chemin qu'on a emprunté. C'est à dire que les technologies de demain ne seront qu'en fait un découle des technologies qu'on fait maintenant. Et en fait il n'y aura personne qui devra faire marche arrière.

En fait, c'est le DTN. Donc l'impasse, l'impasse dans laquelle on sort, dans laquelle on va voudrait dire qu'une fois qu'on est au bout, il faut mettre la marche arrière pour revenir. Et les gens qui sont restés hors de l'impasse ont gagné. Ça veut dire ça, la technologie, c'est dans l'évolution, c'est une réalité. Alors là où je te rejoins, la technologie va toujours en avant. C'est le fameux retour accéléré

du progrès. C'est pas Google ou whatever qui t'explique que toute technologie apporte à la suivante. Et c'est la progression technologique humaine est une courbe exponentielle. Néanmoins, quand tu dis chaque technologie apprend de ses prédécesseurs, c'est parfaitement vrai et notamment ça apprend des erreurs. C'est à dire que la dépendance au chemin, elle existe, mais pour autant elle n'est pas valide. C'est à dire que c'est pas quelque chose dont tu dois en

permanence hériter l'évolution. Par exemple, dites des espèces de Darwin et buissonnante. Donc tu as des buissons et des fois ça finit par un dédale justifié ou non. C'est ça qu'il faut bien comprendre Quand on parle d'évolution buissonnante, tu as des évolutions qui meurent pour de mauvaises raisons

D'orgas d'évolution des espèces. Les trois ou quatre individus qui avaient une mutation pour des raisons complètement exogènes n'ont pas été capables de se reproduire et donc donc non pour des raisons exogènes. Je t'ai dit imagine, tu as, tu as, tu as trois individus qui développent une capacité incroyable à vivre 150 zéro zéro zéro ans. Au même moment, il passe sur une route, c'est la même famille, il passe sur une route sous un éboulis de rochers.

Ils sont tous tués en même temps parce que par contre, autant ils ont une longévité extraordinaire, par contre, personne ne résiste au rocher à ce moment là. Pour des raisons exogènes à leur capacité de mutation, ils sont morts pour de mauvaises raisons. Donc en gros, c'est que ce gène là ne s'est pas transmis et n'a pas et n'a pas et n'a pas, n'a pas réussi à profondément polliniser encore. Utiliser ce terme là, polliniser toute la population.

Et c'est pour ça qu'en fait l'évolution des espèces est buissonnante pour de bonnes ou de mauvaises raisons. Encore une fois, tu peux très bien avoir une espèce avancée qui meurt pour de mauvaises raisons. Ok, alors donc pour revenir dans un contexte technologique, là, dans notre cas, si jamais on le prend dans le cas de Kubernetes par exemple, prenons de l'eau sur des

cas technologiques plus anciens. Si on veut parler de l'évolution de la technologie, prenons le zeppelin à l'arrêt si tu veux des dirigeables est clairement lié à un contexte d'évolution qui a été un problème. Prenons quelque chose de bien, bien plus trivial. Tu es en Europe pour se torcher le cul, on utilise toujours du PQ alors qu'on sait tous que ça étale la merde et que ça ne supprime pas

les choses et que c'est très bien. Alors là, pour mettre dans le contexte, je vois la référence et donc une vidéo de Dirtybiology qu'il faut voir là dessus justement. Mais c'est une excellente dépendance. Si tu veux, c'est une très bonne. Voyez la vidéo sur le PQ et pourquoi on utilise du PQ alors que ça sert. Enfin, il y a mieux, il y a mieux, Il y a les fameuses toilettes japonaises avec des douchette et il y a pire. Faut être très clair sur le fait qu'il y a pire.

Mais toujours est il que l'évolution n'est jamais linéaire et je ne connais aucun système qui a une évolution linéaire parce que là tout système d'évolution génère une certaine entropie. Et en fait tu fais juste un pari statistique que les meilleurs vont gagner. Mais c'est un pari statistique, c'est pas une certitude statistique, c'est un pari statistique et c'est pour ça que c'est buissonnant. Donc on ne peut pas définir que chaque invention est nécessairement meilleure que la précédente.

Par contre, on peut apprendre de ses erreurs. Alors là je suis entièrement d'accord avec toi, C'est pour ça qu'en fait je vais peut être repréciser ma notion de sens. Et c'est là où on est d'ailleurs d'accord, c'est que statistiquement, dans la moyenne, à la fin on arrive vers un meilleur en fait. En gros, les évolutions tendent vers un meilleur.

Et je pense que là dessus, et c'est même d'ailleurs le principe de l'évolution des espèces, même si c'est en fait, c'est la notion de frissonnant que tu dis un peu ce que je disais. Le maelstrom en fait, cette espèce de de choses avec plein de choses qui arrivent dans un, dans un tout, dans le contexte des technologies. En fait, je ne pense pas que, en fait, tu as pris par exemple l'exemple de ces trois personnes qui sont écrasées.

La question est c'est de se dire s'il y a dix zéro zéro zéro personnes qui ont ce gène là, donc ça veut dire une chose ou un événement critique

précis ne peut pas les supprimer. Est ce que ces 10 000 personnes là sont quand même dans quelque chose dans un dead end en fait? Est ce que est ce que d'un seul coup les 10 000 on regarde l'histoire du Blu ray et du HD-DVD? Pas là pour le coup. On était dans un dans un très petit nombre. Personne n'avait HD-DVD en fait, le HD-DVD est mort avant même d'être utilisé, mais il était technologiquement supérieur. L'histoire de Betamax et VHS, c'est la même.

C'est pour t'expliquer qu'en fait il était beaucoup plus cher en fait technologiquement. C'est à dire que oui, pour un technicien, ça veut dire en terme de qualité vidéo. Le Betamax était bien meilleur, mais le fait que le VHS était trop cher, c'est pas lié en fait à la qualité d'une technique. Alors exactement. C'est à dire ça, je suis bien d'accord avec toi, c'est que l'évolution ne serait pas tous taper Windows pendant des années et Internet Explorer six tu vois? Alors voilà.

Alors là alors là c'est super bien, C'est qu'en fait c'est l'évaluation des technologies auxquelles on arrive. C'est que l'évaluation d'une technologie, est ce qu'elle se fait juste par la qualité intrinsèque de sa technique, de sa qualité du code, de son, de sa, de sa. Je sais pas, on pourrait voir plein de plein d'évaluations là dedans. Où est ce qu'elle est plus

globale que ça? Typiquement, le VHS est quelque chose qui marche parce que elle est moins chère à produire et c'est une qualité d'une technologie qui a besoin d'être dans tous les foyers. Alors que si jamais le lecteur VHS était cinq fois plus cher, et bien en fait, il se serait jamais diffusé, même si la qualité de la vidéo était meilleure. Oui mais peut être qu'en introduisant un plus grand nombre, on aurait fait baisser le coût. Mais en fait si tu veux, c'est toujours.

C'est toujours le problème quand on essaie de faire entrer des arguments sociaux dans un dans un choix technologique, un choix technologique qui doit être rationnel en tant qu'ingénieur, à un moment on se pose des questions et puis après on peut faire un arbitrage financier si tu veux. Il y a des il y a des technologies qui sont des sales idées qui reviennent de façon très régulière.

Si la marche du monde est faite autour du pétrole aujourd'hui, c'est pour de bonnes raisons techniques et de très mauvaises raisons commerciales. Parce que c'est tellement plus simple aujourd'hui. Mais on a tous conscience aujourd'hui que c'est une mauvaise idée. Pour autant, on peut pas résoudre notre dépendance au pétrole en trois jours. Bah en fait on y serait même pas. Moi ce que je pense vraiment, c'est qu'on y serait même pas là sans pétrole.

Pour le coup c'est le pétrole est la base de toute notre civilisation actuelle et c'est pour ça qu'on a une dépendance dessus, c'est que justement on a une dépendance. C'est à dire que cette technologie là, on a amené plein d'autres, le plastique, juste le plastique, c'est, Ouais, je parle de brûler des hydrocarbures. Le plastique, pour moi, c'est vraiment un autre essor. Mais brûler.

Des hydrocarbures est très pratique, mais du coup, ça nous a entraîné dans quelque chose où on sait tous aujourd'hui qu'il faut qu'on trouve une autre solution pour faire rouler des voitures. Enfin, c'est pas que rouler les voitures, c'est annexe. Les voitures c'est le pétrole, c'est le transport, c'est le transport et le transport c'est la mondialisation. C'est là le gros problème en fait. En gros, la mondiale est un autre

débat, mais c'est ça aussi. Non mais c'est un super excavateur, c'est Il n'y a plus de pétrole, il n'y a plus de transport, il n'y a plus de mondialisation, on est dans la merde. Le monde actuel c'est basé dessus. Donc c'est ça toute la complexité qui est derrière. D'ailleurs que tu dis, c'est que si jamais on si on se base sur des technologies, en fait le monde avance dans une certaine direction. On s'est basé sur les technologies et c'est très dur de faire ce retour en arrière justement.

Tout à fait, c'est C'est pour ça qu'aujourd'hui je pense qu'on a fait des choix technologiques graves dans notre vie. Alors voilà, maintenant, retomber sur nos pieds parce que on parle de belles choses. Quels sont ces choix graves que tu technologiquement, que tu regrettes ou que tu ou que tu ne supportes pas? Enfin, quelque chose qui te. Et c'est un avis a priori. Là comme ça on pourra donner ton avis et on va essayer de

rebondir là dessus. Je pense que depuis les années 70, à peu près tous les dix ans, il y a quelqu'un qui débarque avec une idée qui est direction. Prenez tous les process des gens qui vont les exécuter alors qu'ils ne connaissent pas les uns à côté des autres sur le même os. Et cette idée là qui déclenche plein de problèmes dont on pourra discuter et on pourra se

demander si on peut les résoudre. Depuis les années 70, régulièrement meurt parce que c'est un concept technologique de mauvais aloi et on en a vécu son sa dernière occurrence avec l'apparition de Docker et l'apparition de docker lead directement à Kubernetes. Alors je tout de suite rebondis sur le moi. Je prends l'autre côté du miroir qui est si on ne le met pas sur le même os. Dans les années 70 et jusqu'à dans les années 90, c'était on le met sur des machines différentes,

voire on a peut être. On avait peut être la technologie du mainframe qui était un peu dans le même temps, on avait le même logiciel, mais on a on a une ségrégation par le hardware et qui n'est qui ne pouvait exister que par le hardware. Et cette ségrégation là, à mesure de la montée en force, en puissance du hardware, n'était plus valide parce qu'on n'allait pas ségrégué par le hardware. Quant au hardware, il y avait cinq GHz et 128 Go de RAM, c'était pas possible.

Donc soit on faisait des micro machines qui faisaient cinq cm, soit on ségréguer de manière autre. Autrement en 2003 t'avais pas 128 giga de RAM et laisser l'apparition des VT instructions poussé par Intel dans le CPU qui te font une ségrégation hardware tout ce que tu avais demandé. Alors donc là justement c'est assez, c'est assez marrant, c'est que on s'est posé la

question tout à l'heure là dessus. On connaît les entreprises qui détestent les instructions VT et la virtualisation, c'est à dire qu'en fait elles sont dans le même posture, c'est à dire qu'elles disent non, nous on interdit la virtualisation, mais complètement. C'est un dogme absolu pour plein de raisons qui peuvent avancer typiquement la latence, la latence, rajouter la pseudo latence rajouter par par. Alors tu vas m'expliquer d'où vient la latence de la VT? Je sens que ça va être très

intéressant. Alors alors. Alors détrompe toi, je me suis battu dans cette entreprise là dont tu viens de boire, dont tu viens de boire l'eau à l'heure actuelle. Regardez le live, c'est un dogme absolu dans cette entreprise qui fait qu'on a déjà installé des haproxy monocoeur sur des 24 cœurs, 128 Go de RAM. Je suis pas là pour écouter les dogmes imbéciles de dos. Mais justement moi en fait si tu veux, la virtualisation a été critiquée à une époque en disant elle rajoute de la latence fine où est

ce qu'elle rajoute de la latence? Ah mais c'est toujours les zayo zayo, les Zayo network, les aïeux. D'accord, donc on rajoute de l'IoT, de la dépendance sur les IO. Pourquoi est ce que ça rajoute de la dépendance sur les IO? Moi je pense que ça en rajoute même pas si jamais on essaye l'apparat. Non, non, non. Mais posons une vraie question pourquoi est ce que des choses comme VirtualBox ou les premiers VMware ajoutent de la dépendance

de temps sur les IO et le network? Que c'était un hyperviseur pour tout le monde qui passait et qui reprenait tous les IO qui les centralise? Et il rajoute ça, il rajoutait une abstraction surtout. C'est pas un problème d'abstraction, l'abstraction n'a jamais posé de problème, le CPU a toujours géré très très bien la séparation des OS qui ne se connaissent pas. La racine si vous voulez sauver votre vie dans le CPU pour ça, c'est ce qu'on appelle les VM.

Exit la VM, exit. Donc vous voyez les niveaux de sécurité dans un CPU. C'est le moment où globalement tu sors de ton enclave sécurisé. Quand on dit tu sors de ton enclave sécurisé, c'est pas un problème, c'est le moment où tu dois parler au CPU pour avoir la main sur autre chose. Sauf que c'est très bien de pouvoir booter un OS dans le CPU peinard et

de pas avoir d'overhead ou minimale. D'abord parce que je sais pas comment ça se passe dans vos infra, mais moi le CPU est rarement bande, on est tous bound par les algos et rarement par le CPU. J'ai pas dit que ça arrivait jamais, j'ai dit que c'était beaucoup moins souvent, surtout dans des infra web où fondamentalement on a des bases de données qui lisent sur des disques durs et qui

répondent de HTTP sur le réseau. Enfin, fondamentalement, j'ai eu des CPU dans les trucs à base de Cassandra Elasticsearch, ils consomment du CPU, alors regarde pourquoi il consomme du CPU. En général, c'est lié à des problèmes, mais ça peut arriver, ça peut arriver. Des fois tu as du calcul à faire dans la vie, mais en général tes problèmes de perf dans la vie c'est des algo.

Ce qui a rajouté des problèmes de lenteur, c'est que pour être capable de faire de la virtualisation, autant le CPU, gérer la virtualisation, autant le reste du hardware non. C'est à dire que ton network, je dirais pas la virtualisation. C'est pour ça qu'Intel au début avait imaginé que tu mettes un CPU 30 cartes réseau dans TA dans ta babasse et roulez jeunesse. Tes disques durs ne gèrent pas la virtualisation, ton écran gère pas la virtualisation.

Personne d'autre ne gère la virtualisation, ce qui fait qu'on a créé ce qu'on appelle des couches d'émulation où on faisait croire qu'il y avait du matos et au début, on faisait même croire qu'il y avait du matos réel, donc des Broadcom. Notamment. Je sais pas si vous vous souvenez de la grande époque où on configuré les Nvidia pour que ça émule un chipset Broadcom. Et là évidemment, oui, tu émule du d'électronique qui

n'existe pas, c'est lent sa race. Sauf qu'entre temps, on a introduit des drivers qui permettent d'utiliser des instructions supplémentaires, des instructions qui te permettent d'avoir une communication directe entre l'host et la virtualisation. Maintenant, juste, je voudrais qu'on soit très clair sur cette histoire virtualisation contre container à cet endroit là, Tout, tout, tout les benchmarks que j'ai vu à la grande époque de l'apparition des containers.

Vous savez, les machines virtuelles light sont des benchmarks qui ont été faits en mode host, c'est à dire sans aucune sécurité des IO. Alors évidemment, tu es rapide. Sauf qu'aujourd'hui, si jamais tu fais un test de ta sécurité des IO dans un mode où t'es tout le monde dans le même OS et on parlera des autres problèmes de tout le monde dans le même OS, Tu es obligé de le faire user Landside donc avec une lenteur de check délirante et en plus là absolument

pas soluble dans le hardware. Donc tu la dépendance à l'IoT? Oui, si tu la supprimes et que tu dis en fait fuck la CPU. Oui effectivement, je te confirme, tu n'as plus de dépendance de problème, mais si tu la réinstalle, t'es bien baisé dessus quand même. Donc là. Donc là, si on résume ton ton, tu penses vraiment et c'est d'ailleurs un argument qui se tient, c'est à dire dépendre de la sécurité du kernel, de plein de fonctionnalités du kernel pour segmenter les usages, c'est quelque chose.

Là je viens juste de te dire que c'est un problème de sécu, de perf, que ton problème de perf était là. On va parler ensuite des problèmes d'isolation, de sécu, mais c'est en fait elles sont liées. En fait, c'est ce partage même du conteneur parce que tu pourrais très bien avoir des conteneurs qui n'ont pas ce problème là potentiellement, mais le fait même qu'elles partagent un socle de base,

sinon c'est pas un conteneur. Si jamais elles ne partagent pas ce socle commun, cet OS en commun, c'est plus du conteneur. Donc là, si jamais je viens, c'est donc ce grief là. Et personnellement je l'entends très bien, voir même plus que ça.

Je pense qu'en fait tout le monde est d'accord avec toi pour une raison, c'est que par exemple, tous les cloud providers, il y en a quasiment aucun on va dire aucun qui propose du vrai conteneur de service, c'est à dire qu'en fait elle te donne une VM, c'est la tienne, c'est pas celle d'à côté. Cette VM est isolée via les institutions. C'est ce que font les autres plateformes de services dans tout le marché des plateformes de services.

Je suis le seul qui fait que de la vertu dans tout le marché. Ouais mais. Mais en fait tous les autres le font. En fait, si jamais demain même j'installe un Kubernetes sur GCP, tu me donnes des VM, des VM que j'espère être isolé via des instructions processeurs. Donc en fait personne à l'heure actuelle me donne accès à un Kubernetes partagé. Alors là c'est un problème de dogme, de sécurité parce que du coup on n'a pas parlé des vrais problèmes de sécurité entre en engendre.

Mais admettons. Partons sur cette histoire d'isolation, je pense qu'on va dans la sécurité alors que au final, je voudrais juste qu'on parle de cohabitation ou de partage de ressources. Parce qu'au final, aujourd'hui, je suis développeur. Les problématiques de sécurité. Déjà de. Les problématiques de dope en général sont assez éloignées, même si ce n'est pas volontaire, les problématiques de sécurité sont encore plus éloignées. Je parle de pas dans la pratique, c'est comme ça.

Moi ce que je veux comprendre c'est qu'est ce que ça m'apporte de faire du multi process versus de la virtualisation versus du container versus de la virtualisation et du conteneur? Enfin, aujourd'hui, ça a une valeur. Tu disais tout à l'heure l'idée c'est que les développeurs aillent vite et je pense que la conteneurisation et la VM isation ont en plus. D'amener des problématiques de sécurité, amener des problématiques de l'instruction VT, etc.

d'Isolation. Elles ont amené énormément de flexibilité pour ces développeurs là et je pense que c'est là la force de ces choses là. Et il faut parler de sécurité dans le cadre de plateformes de services. Mais quand on est dans une entreprise, qu'on a ses serveurs, qu'on n'est pas hébergé sur un cloud, je suis désolé, mais quelle est la différence entre faire du multiprocess et faire du conteneur ou faire de la virtualisation? Et aujourd'hui il y en a, C'est beaucoup plus compliqué de faire.

Du comment dire de la. Comment dire? Je vais y arriver de faire de la virtualisation versus c'est pour moi, c'est en terme de complexité, c'est

number one en terme de complexité, c'est de faire du conteneur parce qu'aujourd'hui c'est peut être trendy, mais aujourd'hui, en deux clics, on y arrive. Et en le plus simple c'est quand même de faire du multi process et d'y aller comme un dégueulasse sur son serveur qu'on a installé à la main. Voilà pour moi la valeur ajoutée, elle est là. Et les problématiques de plateforme de hub pour qui parle Adobe, c'est c'est pas un détail,

mais c'est pas ça qui fait driver. C'est pas un détail, mais c'est pour ça qu'il faut parler de cul. Pourquoi il faut parler de cul? On peut parler de plein de choses sur la mutualisation des ressources, mais parlons en de façon simple tu fais, tu lances plein de process, tu as un react dans un coin et tu as ton serveur Php-fpm, ton React prend plein d'écriture, il va exploser son nombre de ulimit.

Ton serveur Php-fpm ne sera plus capable de répondre une fois de temps en temps à des requêtes parce qu'il a pété le nombre de ulimit. Parce que ça c'est ça. C'est une limite qui ne devrait pas être partagée entre ces deux applications là. Elles devraient même pas savoir qu'elles existent l'une l'autre. Prenons un autre problème de ressources partagées. Non mais on illustre, c'est très bien. Tu as une application qui qui fait dans le qui fait du chiffrement.

Donc en fait elle va t'épuiser l'acide d'entropie de ta machine. Et comme l'acide d'entropie, elle est partagée avec tout le monde, ça veut dire que toute l'entropie de tous les autres trucs qui va être utilisée en chiffrement sur la totalité de la machine est épuisée et donc t'as plus de sécu. Cela dit, à l'époque, il y a longtemps parce qu'il y a longtemps, on n'avait pas les capacités CPU d'aujourd'hui, on avait des circuits hardware

dédiés à la génération d'entropie. Ça existe encore, il faut le configurer, ça existe encore, je suis désolé et on devrait être capable, même dans le cadre de VM et même dans le cadre de conteneurs, de pouvoir configurer des machines spécifiquement dédiées à la génération l'entropie de l'entropie dans les VM. C'est un énorme, c'est un énorme sujet. Par exemple, c'est un sujet beaucoup moins lourd que dans le même OS.

Alors pour le coup, je me souviens plus à quel moment, mais il y avait des VM pendant un temps qui n'était incapable de booter parce que juste elles attendaient le ssh de lancement et il avait une faille Debian. On peut faire notre vie entière à parler d'une faille Debian moi, moi, moi je parle plus, je tire sur une ambulance. C'était pas la faille Debian. Je vois très bien le truc où en fait les nombres étaient même pas.

Je te parle même sur l'exemple que tu me donnes n'est pas n'est pas lié à des gens qui faisaient des choses bien. Il se trouve que Debian a manipulé l'entropie plein de fois et ça a donné plein de plein de trucs chelous parce que pendant longtemps ils ont cru qu'il fallait augmenter la rapidité de génération d'entropie et donc effectivement il y a des problèmes sur du SSH. Néanmoins, là ce n'était pas un problème de VM, c'était un problème

de driver. En fait si tu veux. Le problème c'est que les gens confondent les problèmes de VM, donc du VM exec dans le CPU avec les problèmes de drivers, de l'encapsulage de la machine, le VM, ce qu'on appelle le VM, c'est un problème fondamental que vous devez décorréler. Est ce qu'il peut y avoir un problème dans vos drivers? Oui. Est ce que c'est pour ça qu'il faut compiler vous même les hyperviseurs de façon à réduire vos

surfaces d'exposition? Oui aussi. C'est pas parce qu'il y a plein de gens qui font n'importe quoi qu'une technologie est mauvaise sinon. Enfin, le web entier serait pourri. On faisait tous du frontpage à l'époque, tu vois, c'est c'est un problème. Si tu veux, à un moment faut regarder les choses de façon rationnelle. Quand je te dis il y a un problème avec les containers, je ne te dis pas qu'il y a un problème dans l'absolu. Il y a des cas d'usage où c'est

très cool. Les containers, tout Macias, ils tournent sur Container. Le premier cloud public ever à avoir proposé du docker, c'est Clevercloud. On est une des seules boites dans le monde à packager Docker. Il y a nous, RedHat et Docker donc c'est pas compliqué, on passe notre temps à faire ça. On s'est engueulé un nombre de fois incroyable avec les mainteneurs parce qu'on sentait bien qu'on était dans les rares à

compiler le bordel. Hormis eux. La liste des options du kernel qu'il faut pour compiler pour faire fonctionner Docker sur un truc, ça sort de chez nous, donc on connaît particulièrement bien ce bordel. On te dit il y a plusieurs problèmes, il y a un problème d'entropie, on peut parler de tous les autres problèmes d'entropie qui ont été liés. Il y a un truc qui est sûr, c'est que si tu fais du conteneur, tu auras des problèmes d'entropie.

Tu as un problème de ressources limitées non mutualisables qui se retrouve mutualisé. Donc là je te citais les limites, mais en vrai il y en a plein d'autres des ressources limitées non mutualisables que tu peux avoir parce que c'est un autre problème. Après tu as un problème d'isolation. Ton problème d'isolation, il est statistique. Il y a 430 failles du kernel annuellement, il y en a à peu près 30 annuels qui

sont des élévations de privilèges. C'est à dire que tu étais pas root, tu deviens root, ce qui veut dire que tu as conteneur EPC. Bon, il y a 52 semaines dans l'année, il y en a 30 pendant lesquelles tu es condamné. Fais ton choix. KVM Deux failles en dix ans, il y a une des deux failles. La première, j'étais même pas concernée tellement c'est vieux. La première dont je me souviens, c'est une faille dans le driver d'émulation de disquettes trois

pouces et demi. Alors je sais que le web entier s'est enflammé parce que tout le monde utilise des des distrib dans lequel tout est compilé. Mais enfin moi ça m'a pas touché. C'était pas compiler le driver de compiler, d'émulation de disquettes trois pouces et demi parce que ça n'a rien à foutre en prod chez moi. Donc si tu veux un pur point de vue statistique, tu admettras

qu'il y a un problème d'isolation. Alors je suis entièrement d'accord avec toi et mieux que ça encore, c'est que j'adore la virtualisation.

Enfin pour avoir été chez Cloudwatt et avoir fait de l'open stack sur du KVM etc. Et même avant avoir des infras très très lourdes sur du KVM, le cumul leadworth, le machin etc. J'en ai bouffé et j'adore ça. C'est peut être un truc que les gens crachent beaucoup sur OpenStack même il a énormément de problèmes, mais il a répondu à énormément de soucis et je pense même maintenant peut être

parce qu'on va revenir là dedans. C'est bien que tu aies parlé de conteneurs, mais c'est que moi, par exemple, je pense que donc la dépendance au choix dont on parlait, c'est que je ne vois pas Kubernetes sans la virtualisation. Qu'est ce que ça veut dire pour moi? Et ça va être la définition que je vais dire, c'est que Kubernetes n'est pas un casse, ce n'est pas un conteneur de service, il ne fait. Il a même une notion de conteneur, à mon sens que très lointaine.

C'est avant tout un manager d'infrastructures. Il doit se reposer sur des ressources. D'ailleurs, il gère des ressources humaines. Aujourd'hui, il lance des conteneurs alors même pas utilise les conteneurs, je vais dire pour son exécution. Alors depuis, c'est un outil. Même pas, même pas depuis hier, j'ai vu qu'il y avait un kubelet codé en Rust qui fait du. C'est un Toy project. Il y a d'autres trucs Microsoft qui a pondu le virtual Kubelet qui te permet de prendre l'API de Kubelet

et de lancer plein d'autres trucs. Et c'est comme à chaque fois il se branche à des casses pour des pures casses. Non, je pensais même par exemple à Kata container kata container pour le coup, qui lance, qui utilise des instructions VT en fait. Donc pour ça il lance des micro VM basée sur le projet Clear Linux et à l'intérieur de ce micro kernel donc qui pour le coup là est émulé avec et utilise des instructions VT via KVM à l'intérieur de ce micro kernel Linux,

il va spawner un conteneur. Donc en fait on a toujours la primitive de conteneur mais isolée hardwarement pour le coup, si jamais ce mot existe matériellement est peut être meilleur d'ailleurs. En effet, matériellement par par les instructions BT. Et c'est très bien que tu en parles parce que ça va me permettre de parler des autres problèmes avec les conteneurs, parce qu'à chaque fois on parle de l'isolation. Moi je pense que c'est une

connerie de faire de l'isolation. Juste un point sur l'isolation et sur le fait que tu es dans la même boîte. Du coup on se fait confiance. Ça c'est un truc simple. On a écrit un article il y a très longtemps chez Clevercloud qui s'appelle Mettre fin à la métaphore de la forteresse. Si tu considères que faire de la sécu, c'est que si on est tous copains, alors on se connaît et on peut se toucher les couilles. C'est ton problème.

Tu vois, moi je touche pas les couilles de mes collègues de travail. C'est la même chose dans tout le coin en fait, à un moment donné, la sécurité, ça se fait en profondeur. Si tu as quelqu'un qui a un logiciel au hasard, tu es dans une grosse boite. Il y a un progiciel moisi dans un coin qui se fait attaquer, démonté et pris en pris en attaque. A partir du moment où il est corrompu, s'il est sur la même bécane que les autres, il tue les autres, il est corrompu. Ça, pour moi, c'est un drame.

Donc en défense, en profondeur, l'argument du oui mais on est entre nous et pas entre tierce. Dès que le nous commence à être plus de quatre, il y a un vrai problème de sécu et il y a un problème d'exigence vis à vis de la sécurité. Je suis entièrement d'accord avec toi et c'est d'ailleurs un combat que j'ai eu dans beaucoup de missions que j'ai. C'est que moi par exemple, je déteste avoir un cubain partagé même entre des équipes,

un cubain, une équipe. On viendra ensuite à Kubernetes si ça te va. On peut parler d'un autre problème des conteneurs qui est un problème fondamental. Aujourd'hui un conteneur Linux, c'est quoi? C'est un gros paquet de binaires. Un zip layer, mais c'est un zip que tu partages dans lequel il y a tout ton OS sauf Tooth in the kernel. Ok. Fin moi j'aimerais comprendre pourquoi on m'explique que c'est

plus safe d'avoir des versions. De Spring Boot, par exemple Spring Boot. Je rappelle le framework qui a été testé sur toutes les versions de Java dans un sens. Dans un autre en haut de la VM de Chirac à la GM de chez Oracle. La totale. Et d'avoir des dépendances non testées de la j'ellipse. Et du kernel ensemble. Ou pire, une dépendance jamais testé, des combinaisons non testées ou ce n'est même plus une ellipse de mec qu'on remplace. La GSC part en se disant ça va être cool.

Et qui ensuite me disent c'est plus fiable ce que vous croyez. Quoi que les développeurs de la GTM, ils font leur taf avec Musl ou avec Eclipse? Alors encore une fois, j'invoque le miroir magique qui dit je prends le revers du miroir et le revers du miroir, c'est quoi? Parce que j'ai l'impression que tu tu prends tous les problèmes et que tu les analyses avec le spectre,

avec ton analyseur sécurité. Moi je prends l'analyseur développement, je prends l'analyseur feature et je suis désolé mais justement, gérer les dépendances en local, c'était une hérésie. Ça a été pendant 20 ans une hérésie pendant 40 ans, une hérésie. J'ai jamais géré Gérer les dépendances en local. Attends, attends, il y a une différence entre si on prend tous les binaires, on en fait un gros nœud autour et qu'on les frappe sur le serveur et qu'on les bisous pas.

Gérer les différentes versions de l'IP, c'est les différentes versions de Python, les différentes versions de tout ce que tu veux. Je te dis que c'est une catastrophe. Une erreur, ça s'appelle Debian, ça s'appelle. Voilà, c'est tout ce que tu veux, mais c'est ta défonce aujourd'hui, nous, on n'a pas ce souci là. Chez nous, on met à jour des milliers de machines sans que personne s'en rende compte. C'était une réponse et je pense

que c'était une bonne réponse. Que ce soit la virtualisation ou la conteneurisation, ça dépend, ça dépend en fait, tu mets en place des versions non testées de trucs qui sont beaucoup plus majeurs. Donc là j'ai flippé, tout le monde voit à quoi ça sert la glibc ou pas. Vas y, explique, parce qu'on a des gens qui. Donc la glibc, ce qu'on appelle la librairie standard, c'est c'est le truc qui globalement va plus ou moins, quel que soit le langage

dans lequel vous allez parler. Sauvegarde, ça dépend qui compile en fonction de comment il compile. Voilà, pour rappel, vous avez une dépendance à J'ellipse très souvent et tout ceux qui ont fait un from scratch avec un binaire GO le savent, ils ont pas bien compilé. C'est l'évocation du fait que go clame ne pas en avoir.

On pourra avoir plein de discussions sur Go après, mais si vous voulez la dépendance à IPC, donc la glibc, cette librairie standard, c'est celle dont vous allez vous servir pour faire essentiellement ce qu'on appelle les appels systèmes, donc les appels systèmes, c'est Je voudrais écrire sur un fichier. En fait, quand vous écrivez sur un fichier, ça n'est pas votre programme qui sait comment écrire sur un fichier. Vous ne savez pas comment c'est fait.

Vous êtes peut être sur Windows, peut être sous Linux. Donc voilà, si vous êtes sur un Linux, vous êtes peut être sur du btrfs, peut être sur de Xt4, peut être sur de l'overlay FS. Enfin, je vous laisse aller constater la quantité de FS disponible en Linux. Vous ne savez pas écrire sur sur le fichier, donc votre programme ne sait pas. En général, il rappe quelque part dans les profondeurs de ses dépendances, il frappe la glibc et la glibc.

Elle même ne sait pas en fait écrire sur le sur le sur le disque dur ce que sait faire la glibc, c'est un appel système qui lui va écrire sur le disque dur parce que le kernel, lui, sait comment il a été configuré et comment il fonctionne. La Gillipsie va gérer vos dépenses au réseau, gérer vos dépenses à tout le hardware.

Elle va gérer vos dépenses au temps. Bref, tous les petits sujets en informatique tels que écrire de la donnée, parler sur le réseau, savoir quelle heure il est. Les trucs pas important de l'informatique, ce qui veut dire très simple, toujours très simple. Depuis le début, on sait faire. Et on rappellera que pour l'anecdote, le premier version de Linux qui est sortie le plus grosse partie du code, c'était juste afficher la date. Je crois juste la calculer.

C'est c'est chiant, c'est le truc le plus infâme du monde. Et imaginez quand on ira sur Mars. Et du coup, si vous voulez, le boulot

de la gillipsie dans l'opération, c'est de faire ces appels là. Ce qui veut dire qu'en fait votre gillipsie et votre kernel, ils sont excessivement proches. Evidemment, la gillipsie est codé avec un nombre de garde fous incroyable pour essayer de ne pas spammer dans le kernel. Et le kernel a lui même des gardes fous. Par contre ces gardes fous, en fait ils vous font perdre du temps, ils vous font perdre énormément de temps, donc ne pas les employer bien. Et par ailleurs, il y a des bugs dans

la gillipsie, il y a eu des soucis. Alors il y a une grande spécialité de Debian qui est de rester six versions en retard de la gillipsie en se disant que celle là était bien battletech comme ça. Il y a des erreurs qu'avait quatre ans qui ont été corrigées il y a quatre ans, qui sont découverts à un moment, souvent en se disant mais pourquoi vous n'avez pas mis à jour? Parce que nous, on aime bien les vieilles versions bien stables.

Donc voilà. Et par ailleurs, il y a des gens qui ont décidé que la gx7 est mal écrite et qui l'ont intégralement réécrit. Ça s'appelle Muzzle. Enfin, il y a plusieurs. Il y a Micro Ellipsis qui a été plutôt pensé pour de l'embarqué, donc l'idée était de dire on fait une toute petite JPC pour des cas d'usage spécifiques Damzel qui est même pas binairement compatible. Mais il faut de toute façon tout recompiler qui n'est pas du tout foutu pareil et surtout qui est codé par deux mecs.

Qu'on soit très clair sur la situation. La Gillipsie, c'est un code patrimonial de l'informatique mondiale qui date des années 70 avec des tests, des gens qui ont bossé dessus. Muzzle c'est une blague? D'accord, D'un point de vue gestion de projet, tu as deux gus dans un garage qui codent ce truc et donc on te dit on va tous utiliser Alpine, Linux, Alpine, Linux Racing, c'est quoi Muzzle? Donc on va se retrouver avec un truc où on dit on va lancer MySQL,

MySQL, il fait quoi? Il parle sur le réseau, il parle au disque dur, il passe son temps à faire des appels à JPC qui elle même fait des appels sur le kernel. Et donc on va utiliser quoi? Un truc avec lequel les gens qui font MySQL n'ont jamais rien testé et on va te prétendre que c'est beaucoup plus sec parce que tu comprends du MacBook Pro, du développeur à la prod, c'est le même binaire. Et maintenant, posons nous la

question est ce une bonne idée? Je n'ai jamais vu qu'on prônait, c'était safe, on disait que c'était pas unsafe. Ce qui est différent de dire c'est safe, mais surtout les avantages. Enfin, c'est comme n'importe quel choix, il y a un coût, je sais plus comment on appelle ça bénéfice risque. Aujourd'hui, on prend sa voiture. On a décidé de manière sociale que prendre sa voiture, c'était bien. Pourquoi?

Parce que le bénéfice de prendre la voiture était largement supérieur, au risque de se planter en bagnole et que rouler à 130, c'était à peu près là, alors qu'on sait tous que tout le monde va mourir à 130 si jamais il y a un accident, tout le monde va mourir à 130. C'est pas grave, mais c'est un médicament, c'est un bénéfice risque. C'est mais c'est bien, mais c'est bien, c'est bien. Par contre, le bénéfice risque sociologique. Enfin moi je vous parle de comparer des technologies,

c'est un bénéfice des technologies. On doit, on doit, on doit voir leur capacité. Au delà de ça, je te dis ça c'est un major Flow. Le deuxième meilleur flow du truc, il est simple, ça veut dire que tous les binaires que tu compiles, comme tu n'as aucune idée de comment ils vont être exploités, bah en fait tu compiles les binaires les plus open possibles, c'est à dire que ça doit marcher d'une GameCube. À l'émulation un peu cradingue que tu

as sur Mac. Je te suis? Mais non. Non mais c'est un vrai souci, c'est tout. Ce que tu compiles, c'est toutes les options puisque tu ne sais pas ce que tu pourrais avoir besoin d'avoir accès. Donc du coup, tu compiles le fameux driver du disquette trois pouces et demi. Tu vois. Alors que fondamentalement, aujourd'hui emprunte sur un cloud, ça devrait pas être là. Tu compiles sans utiliser aucune

spécification de ton processeur. La plupart des images docker aujourd'hui, je les fais tourner sans aucune discussion sur le Athlon XP moisi que j'avais quand j'étais au lycée. Et ça, ça veut dire que bonjour, que tous les mecs d'Intel qui bossent en R&D, ils ont rien branlé. Ces quinze dernières années, il n'y a jamais eu de nouvelles instructions, il n'y a jamais eu rien.

Je paye mes processeurs 1 600 $ pièce pour le plaisir de me servir de trucs qui en fait pourrait être fait il y a quinze ans. Parce que je ne lis pas les changelog Intel, je ne lis pas les changelog du kernel, je ne lis pas tous ces trucs là. Donc si tu veux, j'ai eu une bonne idée là dessus. Effectivement, tu dis il y a un bénéfice. Moi ce que je te dis, dans un monde où on parle d'écologie, moi je te parle de 30 35 % de perf à gagner juste en changeant

ton fichier de configuration. Et là je ne t'ai pas parlé des problèmes sécuritaires parce qu'un kernel banane Ubuntu full ouvert, ça fait 360 mégas avec l'activation en plus des modules qui est à peu près 50 % des failles de sécurité graves du kernel si on en suit l'accidentologie de ces dix dernières années. Un kernel chez Clevercloud, ça fait un mega deux. Donc ça veut dire qu'il y a du code qui n'est pas là. Ça veut dire qu'on a nettoyé les choses.

Ça veut dire qu'on n'est pas en train de faire n'importe quoi. Donc si tu veux, il y a un moment, quand tu parles de bénéfice risque, je te dis mais il n'y a pas de problème. Parlons des bénéfices cachés. C'est pas parce qu'on a mis l'accent unique sur certains points en marketing qu'on ne

peut pas parler des autres. Alors alors tu es d'accord avec moi que tu pourrais très bien même checker Cloud et d'ailleurs vous le faites et ce serait tant mieux, parce que c'est en fait le sujet dont tu viens de parler de cette optimisation des processeurs pour être un gros lecteur de Phoronix. On va essayer de le prononcer comme

ça. J'ai jamais su la prononciation. C'est un sujet que j'ai beaucoup et c'est d'ailleurs ma plus grande, mon plus grand grief envers Debian, Ubuntu et tous ces paquets là où en fait tout est compilé complètement avec des options arriérées comme tu, comme tu le disais, arriéré dans le sens elles sont pas merdiques, c'est juste elles sont très vieilles et avec des options très très parce qu'il faut une volonté universaliste et vous pouvez reprendre votre PC de 98 et installer Ubuntu, ça marchera.

Donc en gros, en fait le truc c'est que les conteneurs n'ont ni changé. En fait non pas changé l'ordre établi, c'est à dire que les gens qui sont passés avant d'une distribution d'un PC et une babasse installée avec une Debian et je te mets un jar dans les dents et ça doit marcher. Ils sont passés à des conteneurs. En fait, ça n'a rien changé pour eux. Est ce que ça a changé? Par contre pour eux, c'est le format de déploiement d'artefacts. Par contre là où je suis d'accord par

contre, du coup, ça n'a rien changé. En fait, si tu veux, à un moment, quand tu regardes une technologie, il faut regarder ce qu'elle apporte et ce qu'elle aurait pu apporter. Le format de packaging applicatif, le fait de dire on va faire ça parce que du coup on fait un format binaire. Donc si tu veux un format binaire, enfin, c'est quand même pas à vous que je vais apprendre que de faire des formats binaires,

c'est une sale idée. Enfin, on a toute l'expérience de Microsoft Word, de BMP, ça fait un moment qu'on est sur les formats binaires et le fait que bon, pour finir, c'est quand même pas si pratique que ça, et ben là c'est la même. Et je suis désolé, je reçois des calls pendant le live, c'est très chiant, les gens ne regardent pas ou alors ils ont voulu dire de parler très bien. Donc en fait le format, le format binaire ici pose un problème. Il pose plusieurs problèmes en fait.

Ton premier problème c'est effectivement la non optimisation des binaires et du coup ça la grave dans le marbre. Le second problème, ça pose un problème de portabilité maximale, c'est à dire qu'on dit à partir de maintenant, toutes les applications ne fonctionneront que sur du 386 ish, peut être 86 sur 64 sous Linux, mais on n'a pas réglé le problème de portabilité.

Aujourd'hui, nous on a réglé nos problèmes de portabilité avec un format sémantique qu'en plus on plante au jouant en loto, en loto afférents parce qu'on sait que les gens ne veulent pas écouter. Notre format redéfinit portabilité parce que c'est à dire que tu prends ton application et tu peux la faire tourner sur autre chose, sur un Raspberry, sur un PC, sur un autre OS, sur sur une autre architecture logicielle quoi. Donc ouais, c'est un objectif,

moi c'est pas mon objectif. Quand on dit on va vous fournir un truc qui package définitivement les applications parce que ce sera portable, C'est parti. Je n'ai jamais entendu une partie de la page d'accueil dans l'argumentaire Docker, mais alors justement, c'est lui, il l'a dit par ailleurs. Non, non mais non mais non, mais c'est vrai! Et pourtant dans les faits,

c'est pas un objectif en soi. Non mais pour prendre ton exemple des Raspberry Pi, et ben moi je suis désolé mais les conteneurs c'est génial parce que justement ça m'a permis d'avoir plein de logiciels compilés en arm64. Alors ok, il y a eu le problème des armes achevées. Est ce que HF est ce que est ce que j'ai des intrusions par 64? Oui, voilà. Et ça c'est un problème de des connards de chez ARM qui ne

savent pas faire. Enfin personne, plutôt les constructeurs de processeurs qui font de la merde avec. Est ce que je t'ai les instructions de néon ou pas, etc. Bref, connard de chez Nvidia qui ont fait qui ont fait ça et. Et en gros, le truc c'est que quand même le format docker a plus popularisé des architectures type Arm64 et je suis sûr d'ailleurs que Sfiv pourra aussi devenir populaire parce que justement je pense qu'il faut encore une fois, il faut regarder ce que ça a apporté.

Je termine mon conteneur, Il n'est pas porté, s'il vous plaît. Alors bon, l'avantage c'est que justement, par cette multiplication, cette facilitation d'utilisation de plateforme un petit peu orthodoxe, pas orthodoxe justement, le Tooling a pu évoluer et fournir typiquement des docker multi-plateforme, enfin des images multi-plateformes, multi-plateformes. Alors voilà, c'est le tu peux pousser un truc qui a le même nom et qui dit que tu fais du multi-plateforme.

Tu n'as plusieurs images qui sont multi-plateformes mais qui n'ont aucun lien entre elles. Exactement. Mais c'est pas grave, mais ça veut dire que le packaging que tu fournis, ça veut dire que le format que tu fournis, le tout n'est pas capable de le gérer intrinsèquement. Mais c'est mal, c'est mal. L'universalité, enfin l'universalité absolue dans le discours, dans le discours, dit au début, mais en fait, en fait, en gros c'est tu peux me dire ok,

c'est pas grave, c'est une figure. Bon, il y en a qui l'ont vendue, moi pas, mais du coup on s'en bat les steaks. Très bien, c'est des sacs de pommes de table, on est d'accord que c'est pas portable le Hello World Python, il va tourner partout pareil le Hello World. C'est le cas aussi des conteneurs des conteneurs. Essayez de faire un conteneur qui tourne sous Windows et vous verrez un peu la galère que c'est. C'est c'est c'est pas un objectif en soi.

Je veux dire, c'est peut être un objectif, c'est peut être pas un objectif dans le monde, Non non, c'est pas un objectif de trois pecnos je vais dire Qui ça? La portabilité des formats applicatifs, la portabilité des formats applicatifs, ça intéresse tous les éditeurs aujourd'hui. Tu t'appelles pas Elasticsearch? Un format compatible avec tout ça t'intéresserait? Aujourd'hui, tu te retrouves à faire X conteneurs, alors quand tu as des moyens, why not? Mais en fait, ça n'a pas réglé

ce problème là, c'est tout. En fait, c'est encore une fois, je ne sais pas. En fait, si tu veux, tu me demandes c'est quoi que tu reproches à cette techno? Je te dis. J'ai l'impression que tu reproches beaucoup de choses qui sont que tu dis. Ils disent ça, ils veulent faire ça, mais ils ne le font pas. Du coup ça pose un problème. Tu vas me dire, moi l'intérêt que je vois au conteneur beaucoup et qui en fait est en lien, peut être ça pourrait ressembler à la portabilité,

mais en fait ça l'est pas pour moi. Moi c'est la reproductibilité, c'est reproductible en fait, via l'immutabilité justement, ça veut dire quoi immutable? En fait, le fait que toutes mes dépendances, à un moment donné, soient contenues dans un package, quelle que soit la façon dont je l'ai fait. D'ailleurs, je ne suis pas très fan du Dockerfile, je parle vraiment d'un concept très vaste. On parlera du layer après qui

pose un autre problème en fait. Mais mais c'est pas reproductible puisque tu exécute un script, le script va chercher des trucs qui sont posés sur les repo et t'as aucune putain d'idée de ce que moi je parle. Justement, ça dépend du script. Moi je parle vraiment du format d'image. Okf Oui normalement c'est ça, je dis voilà, je te donne. J'ai fait il y a dix ans un format

d'image normalement. Et alors? C'est vrai que par contre tu poses le problème de la l'eapc avec le kernel et c'est un vrai problème mais qui arrive très peu souvent. J'ai plus de problème de temps entre mon paquet python et le python que j'ai maintenant avec un autre paquet etc. En termes de statistiques, pour le coup, bah ça m'arrive plus souvent un problème avec Python qu'avec les statistiques. On a besoin de grands nombres et du coup ton expérience personnelle n'est pas une nécessité.

C'est pour ça que j'ai dit moi et je le dis je. Bien sûr, quand on parle et on est tous d'accord avec soi, on est ultra biaisé parce qu'on se connaît que nous et les gens qui nous entourent et les gens qui nous entourent nous ressemblent trop. C'est clairement un problème. Mais en gros, moi ce que je vois à l'heure actuelle dans ce format là, ce format a plein de problèmes, mais il en a beaucoup moins que les autres formats.

Simscript Ah non non non. La différence entre un Dockerfile et un chef, c'est que avant chaque commande tu as mis run en majuscule. Mais fondamentalement, on est entièrement d'accord, on a besoin de rien. Non non non non mais moi je parle pas de doc, je parle du format de sortie, c'est à dire ce truc que tu pourrais faire avec le binaire, tu pourrais faire avec. Donc cet artéfact qui est la représentation de ton application, c'est pas une représentation, c'est un binaire,

mais il a besoin du kernel, donc en fait il est, il a en fait en gros on a juste descendu avant je te donnais juste un binaire et après c'est à toi de faire tout. Après je t'ai donné un accord. Sauf que. Sauf que si tu veux aujourd'hui ta reproductibilité ou tout ce que tu veux d'autre. Si aujourd'hui je te supprime le Dockerfile qui en lisant en plus comme aujourd'hui, le format a été pensé de telle façon qu'on est obligé de mettre du double ordre un peu partout et c'est un peu pénible.

Mais en le lisant, tu es capable de comprendre globalement ce que le mec essaye de faire. Si aujourd'hui tu prends juste le truc et que tu te dis bah ça fait quoi cette appli? Ta seule solution c'est de monter le filesystem et de introspecter, c'est à dire que tu es dans un binaire, tu n'as aucune idée et ce n'est pas un format sémantique. La différence entre le sémantique et le binaire en informatique est très simple.

Tu peux descendre du binaire quand tu viens du sémantique et par contre quand tu es dans le binaire, tu es bloqué et ta seule solution c'est de passer du machine learning dessus pour essayer de comprendre ce qui se passe. Je sais, la seule chose à laquelle j'en suis réduit aujourd'hui pour essayer de gérer ce problème là. À l'époque où Docker est apparu, il y avait des réflexions pour

créer des formats sémantiques. Et en fait, si tu veux, l'apparition de ces choses là a tué toutes ces réflexions là à cause de l'overhaul marketing. Alors après tu peux me dire c'est pas grave, je te dis, c'est un problème, il voulait le régler, ils l'ont pas réglé. Tu peux me dire on s'en fout très bien, on s'en fout, c'est un problème. Le deuxième problème, c'est le format de layers qui sur

le coup paraissait très malin. La réalité, c'est qu'aujourd'hui tu prends les 100 images les plus downloader du docker hub et Sneak te dit il y a au moins 30 failles dedans et pas des petites genre Ghost Puddle, enfin des trucs genre toutes tes data à poil sur internet quoi. Vraiment un truc violent. Et ça à mettre à jour, c'est hyper pénible parce que le système de cascading n'a jamais été pensé pour penser à des mises à jour qui soient

faites par des hommes. Pourquoi? Parce que Docker n'a pas fonctionné, Parce qu'il permettait de faire mieux. La prod Docker a fonctionné parce que ce qu'il promettait aux devs, c'est d'aller faire chier les ops. Tu veux pas me mettre à jour mes technos? Et bien très bien, je vais donner un run et tu vas l'exécuter. Et c'était le cas et comme moi j'en ai rien à foutre et bah moi je sais pas faire de la mise à jour on s'en tape et donc on aura des binaires pas à jour,

pas compilé pour tagadatsointsoin. Parce que de l'autre côté je gère une infra aujourd'hui où on n'a que des binaires à jour, que des binaires optimisés pour chaque profil d'architecture qu'on fait. Et à ma connaissance, on est dans les rares à faire ça. Après je te confirme, on est dans notre coin et comme d'hab on est dans notre coin et tout le monde nous regarde avec des grands yeux Quand on dit qu'on fait une seule grosse base. Tu l'as dit, tu l'as dit toi même,

vous êtes les seuls. Et en fait, à l'heure actuelle, oui, cette technologie de conteneurs, elle a plein de problèmes et je pense qu'on était dans les dans les tout débuts de Docker. Et oui, à chaque fois on se regardait en se disant mais pourquoi? Mais en fait en vrai, elle a quand même répondu à des problèmes, elle y a peut être mal répondu ou elle aurait pu faire mieux.

Comme elle a répondu à une question managériale qui était une question de mal management des équipes qui permettait à une équipe qui aujourd'hui a la main, parce que c'est très simple, les boîtes, elles ont besoin d'évoluer très vite leur soft. C'est pour ça que moi, la composante CentOS, je me la suis tapée dans plein de boîtes et je me la tape encore dans plein de boîtes. Et donc oui, mais c'est ça un problème, c'est un problème de management, C'est pas un problème technique, mais

ça me semble entièrement d'accord. Et en fait, en gros, je pense que en fait, ce que tu ce que tu es en train de dire et ce que je pense concrètement, c'est que vous êtes sans doute demain il va y avoir un merge et c'est là la notion de je pense, de linéarité dans ce combat, dans ce combat, c'est qu'à l'heure actuelle on a pu avoir une espèce de patch qui nous a permis, là, de tenir dix ans de plus et que demain, en effet, basé sur cette

technologie là, on a perdu des années à faire des technologies qui, du coup posent des soucis, ça a réglé des problèmes, mais ça en générant plein d'autres. Et moi, si tu veux. Ce qui m'énerve dans cette situation là, c'est que tous les problèmes que ça génère au moment où c'est apparu, les ingénieurs systèmes ont tous dit ça pose un souci quand même et personne ne les a écoutés, ça oui,

mais ça en a résolu beaucoup plus. Nous, on était, on était dans ce cadre là, à ce moment là, ça n'a pas résolu, etc. En chef, c'est on on a fait, on est vraiment là dedans. Il faut vraiment se remettre dans le contexte, c'est ça répond à un vrai besoin, c'est et en plus, et en plus cette technologie n'est pas orthogonale. C'est vrai qu'elle a permis de ne pas se poser certaines questions comme tu le dis,

mais elle est pas orthogonale. C'est à dire que même maintenant avec des conteneurs, on peut faire des conteneurs sécurisés. C'est possible, C'est peut être plus compliqué, mais c'est possible. Mais ce n'est même pas plus compliqué qu'avant. Oui, en recompilant soi même par exemple, c'est c'est, c'est ces conteneurs ou en n'utilisant pas docker par un système de layer en supprimant. Mais moi je déteste. Enfin je sais pas ce que tu es

en train de me dire. On est en train, on est capable de générer des binaires, de les mettre dans un zip et de se les envoyer. Oui ça je suis d'accord avec toi. Mais si la seule chose qui fait qu'il faut reconnaître des conteneurs c'est on peut faire ça, ça me va.

Moi il y a un deuxième problème qui me pose souci dans l'histoire, c'est que si tu veux, je sais pas comment vous ça se passe, mais nous on gère des décès et faire un système de distribution basé sur un point de centralisation alors que quand tu perds un décès entier, il faut tout repoper en un coup ou donc tu as besoin de peer to peer littéralement Parce que sinon ton bottleneck c'est la carte réseau de la babasse qui distribue en HTTP. J'avoue que là, encore une fois,

j'étais malade. Alors là pour le coup, là pour le coup, voilà le problème. En attendant, alors là, on arrive dans un point très important de l'écosystème Kubernetes. Vous avez mis en prod le bordel des Chinois. Lequel? Lequel? Lequel? Parce que là, pour le coup, parce qu'il y en a plusieurs. Moi j'ai dit on s'est dit par exemple ils l'ont, je te parle pas, tu parles, tu parles du multi, c'est pire parce que moi j'ai mis en prod tous ces machins là, tous ces respects, il y en a pas

un qui marche. D'accord? Donc moi je veux bien si tu veux, à chaque fois que je dis ça, c'est un truc qui est pareil, on dit si ça ça marche, tu l'as mis en prod non? Alors moi j'ai mis en prod qu'on soit clair, ces machins là ne marchent pas. Moi ça fait dix ans que je fais du peer to peer sur mes infra et ça ne marche pas avec ces systèmes là pour de bonnes raisons, parce que leur système, il est fait encore une fois de façon à penser à une forteresse.

C'est à dire que la totalité de ces systèmes là sont pensés des dans mon réseau. Donc t'es un copain et donc la faille de sécu. Mais non mais je suis à 100 % d'accord avec toi et c'est même et c'est même quelque chose qui est en

même temps et justement je pense. Alors voilà, voilà mon avis là dessus ultra personnel, c'est que je pense que votre expérience chez Clevercloud que vous avez, elle est extrêmement bonne, et justement, il y aurait tout intérêt à ce que cette expérience là, elle puisse profiter en fait au reste de l'écosystème, c'est à dire en fait moi, depuis le début, depuis le début, je me donne des TOC en permanence en expliquant aux gens comment ça

marche, mais en fait pas comment ça marche, comment ils font mal, mais comment en fait, avec ce qu'ils ont, ils vont mieux faire. Ah non non non, attends, il y a un truc qui est important quand tu as une baraque qui a été construit sur de la boue, sans fondations, si tu mets un immeuble haussmannien dessus, ça ne marche pas. Il y a un moment parce que tu utilises à peu près les mêmes références que moi et c'est la base. De la base, c'est un problème.

Alors si tu veux, oui, on donne des tôles et on ne donne pas du tout des tôles de défonce. Encore une fois, on a été les premiers à accepter cette techno en disant il y a toutes les techno qu'on supporte en Europe. Sur Clever, il y a tout le reste que vous pouvez faire en docker et il y en aura. Vous n'arriverez pas à rentrer dans du docker. Et c'est vrai. Et on finira certainement un jour par faire du VPS pour les gens qui ont absolument besoin d'aller faire du SSH et des choses dessus.

Par contre, la question elle est quand tu regardes un format, est ce qu'il a répondu au problème? On vient de dire qu'il y a un problème d'isolation et de sécurité. On vient de dire qu'il y avait un problème de mise à jour par la virtualisation avant. Donc en fait, on peut se reposer sur la virtualisation pour la sécurité et la contextualisation, pour le pour le ce qu'on fait. Je lance du docker la lance dans une machine. Est ce que j'essaie que j'ai que à peu près tout le monde, y a personne?

Ah non, nous on lance chaque containers dans sa vertu, On fait un peu du kata si tu préfères, mais à notre sauce, on finira probablement par rejoindre le projet Kata. On bosse déjà beaucoup avec Intel sur des sujets, mais ce qu'on veut expliquer par là c'est si tu veux, quand tu me dis ça a résolu le problème, ça n'a pas résolu les problèmes d'isolation, ça en a créé, ça n'a pas résolu les problèmes de portabilité puisque à mon sens,

ça en a plus créé qu'autre chose. Ça a vraiment pas résolu les problèmes de faire des binaires trop compiler largement alors qu'on avait tout pour les résoudre ce problème là. Je rappelle on a l'open source, l'Open source a triomphé. On a quand même un marché dans lequel aujourd'hui, la plupart des softs, c'est normal d'en donner des sources. Ça va même jusqu'à Elasticsearch qui libère les sources des parties payantes en disant si tu as un truc

à corriger ou si tu veux faire ta propre compile, fais le. Tu vois? Donc l'open source a triomphé. Et du coup, on fait quoi? On distribue des binaires dont on regarde pas le contenu Et ça c'est un autre problème avec le système de packaging. Je te signale qu'aujourd'hui le lien entre ce qui a été compilé et le binaire que tu télécharges n'est pas fait. T'as aucune putain d'idée de ce qui est lié.

Ce qui veut dire que quelqu'un qui décide de pousser sur le docker hub dégage des portes dérobées, Il peut le faire. Il n'y a rien dans le format, dans la conception du protocole à ce moment là. Quand je télécharge la lib, une lib dans Debian et une lib dev dans Debian, j'ai pas la garantie que la lib a bien été builder avec la lib dev. J'ai dit qu'on ne tirait pas sur Debian, c'est tirer sur une ambulance. Non mais encore une fois je sais même

pas si on sait que c'est le meilleur. Debian est complètement merdique en Perl, mais si je télécharge depuis un miroir, je suis pas sûr que le miroir n'y est pas. Je suis d'accord avec ça, il y a des checksum après moi encore une fois, je fais pas de Debian pour de bonnes raisons. Chez Clever, il y a une règle, elle est simple si jamais on s'aperçoit, ça fait quasiment 1 h, 1 h et quelques qu'on parle. On a toujours pas parlé de Kubernetes, on rappelle que c'était ça le titre.

Mais c'est bien parce que ça rappelle, ça rappelle la chose. Donc le grief sur les conteneurs. Et donc moi je rappellerai juste l'aspect enfin, en fait, le mon tweet était vraiment que sur Kubernetes en particulier, et je dissocie en fait. Personnellement, je vais donner mon opinion en fait. Et comment je vois Kubernetes? Je le dis un peu, c'est pour moi un gestionnaire de plateforme, un gestionnaire de plateforme, c'est à dire qu'il va vous permettre de décrire avec de la sémantique.

Et alors pour le coup, de la pure sémantique, de la pure sémantique déclarative, ce que je veux dans ma plateforme, il se trouve que la primitive en dessous quoi, c'est sémantique, déclarative, c'est déclaratif, c'est déclaratif. Ah bah tous les tous les manifest que je vais faire de ce que je veux le manifest kubernetes d'un pod il dit binaire l'actu download là ouvre tel port, file reprend tel afterlife de pod.

C'est quelque chose qu'on aime pas. Les manifest de pod, on ne les manipule plus, on manipule à la rigueur des déploiements, on manipule des choses qui exploitent les manifeste. Ça veut dire quoi? On va dire que à l'heure actuelle et à l'heure actuelle, on utilise des pod et ses potes sont en effet des conteneurs etc. Et en tout cas ils sont déclarative dans le binaire. La primitive de base de cube CRS. Alors je pense qu'on est tous

d'accord au bout d'une heure. Du coup on est d'accord sur le fait que un conteneur n'est qu'un binaire à partir du moment c'est un contexte. Non mais non, c'est non, c'est pas un binaire, c'est un contexte d'exécution. Et avec le binaire, oui. Si tu veux un binaire oui non mais d'accord, ça veut pas le faire, mais du coup tu sais pas ce qui tourne dedans. Mais c'est pas le but justement, tu n'en as aucune au niveau de conscience. S'intéresse que à Kubernetes on

s'en fout. Non mais en terme oui non mais je suis bien d'accord. Mais en terme d'architecture tu sais pas quel protocole on parle, Tu sais pas comment c'est codé, tu sais pas comment le mettre à jour, tu sais pas s'il y a de la donnée dessus, tu ne sais pas si la donnée est répliquée, tu ne sais pas si quand tu arrêtes le pod, tu peux le faire violemment ou pas. Parce que si tu le fais violemment ou pas, c'est la déclaration, c'est la

déclaration, c'est la déclaration. C'est à dire que la personne a si heureusement tu dis que tu déclares le protocole dans la déclaration, Non, non, pas le protocole. Est ce que tu déclares le modèle de runtime, la déclaration, le modèle, le protocole, donc le protocole que tu parles dans une déclaration, que ce soit réseau ou quoi que ce soit?

Donc le truc qui te permettrait de savoir si tu es en train, si tu fais un protocole que tu peux interrompre, pas interrompre un protocole, tu peux le load balancer pas load, balancer, load balancer du http va load balancer de l'UDP. C'est possible dans certains cas,

pas possible dans certains cas. Alors là pour le coup, le port, le port c'est défini par défaut, c'est du TCP port, c'est pas, c'est pas sémantique. Le port. Enfin moi je te fais écouter de la http sur les ports de 1 à 8. Oui mais justement moi ce que je veux c'est que et c'est déclaratif, c'est à dire que quelqu'un me dit tel conteneur, je l'ai buildé de manière magique. Voilà, j'avais une potion magique, j'ai sorti un conteneur, ce conteneur là. L'avantage c'est que je le ferai pas

pour touiller la potion 20 fois. C'est à dire que ce truc là, cette potion là, je peux la dupliquer, je peux la cloner, ça sera exactement la même, sans aucun bit de différence ce truc là. Maintenant, je te dis que pour le boire, pour le faire tourner, et ben à la fin, ça va être comme ça et ça va être sur ce port là précis. Moi je te donne toutes ces déclarations là, je te la donne et tu peux le faire. Je sais pas si c'est un mode

d'emploi. En termes d'architecture, tu n'as toujours pas aujourd'hui Kubernetes Ice Cube. Dis moi comment je l'explique. C'est justement cette boucle entre dev et ops, tout le monde voit le huit, dev hub, etc. Et bien moi quand je vois une boucle, il y a un point au milieu. Ce huit là, il y a un point au milieu. C'est un point remarquable. Qu'est ce que c'est? C'est donc une frontière entre deux mondes le monde du dev, le monde de l'App.

Moi, quand j'entends frontière, maintenant j'entends api, j'entends api, j'entends la déclaration. J'emploie contra, j'emploie API au sens très très large. Et bien maintenant, Kubernetes c'est ce truc là, c'est ce truc qui dit qu'il y a des devs qui font un truc et il y a des ops qui savent l'opérer. Alors oui, ok, ils ne savent pas ce qu'il y a dedans. Et justement, Kubernetes permet de ne pas avoir le fait qu'il ne sache pas de base en fait qu'ils sont incapables de réellement comprendre

comment ça pète ou pas en fait. En fait, en fait, l'histoire elle est très simple, soit soit, soit. Tu considères que ce que tu dois faire pour opérer un truc, tu as juste à fournir du CPU. Et dans ces cas là, expliquez moi à quoi vous servez aujourd'hui, hormis filer trois coups de molette dans ce machin qui est

un moyen stable, tu vois? Et on pourra parler après des designs de Kubernetes notamment l'API Server et sa façon d'être bizarrement master et de ne pas être capable de clôturer ces problèmes. Mais ça c'est encore une fois, ce sont des problèmes dont on peut parler un tout petit peu plus tard. Je suis complètement fan, mais les serveurs. Donc d'accord. Aujourd'hui tu prends un API serveur, tu butes, qu'est ce qui se passe? Je prends une équipe de daube, tu la bute. Qu'est ce qui se passe

aujourd'hui dans un système? Tu es dans un système, Tu as déployé sur 50 bécanes, dans un serveur, un API server, ton API server, tu tues pour x raisons la machine sur lequel il tourne, tu disparais. Aujourd'hui, l'API Server il était master, ce qui veut dire qu'un serveur n'est absolument pas Master si elle est Master. Non du tout. Alors là, pour avoir déployé des API serveur sur une centaine de machines et des master slides, je te jure que tes déploiements en cours partent

en cacahuète parce qu'ils partent. Non mais si ils sont, ils sont dans le vent! Non non non, non non! Les serveurs? Pas du tout. Le contrôleur manager oui, ils ont une élection de leader, de leader. Le scapulaire pareil, il y en a. Élection de leader qui est d'ailleurs à se taper le cul par terre. Mais ce que je peux vous définir comment ils font une élection de leader, c'est très bien. Toi tu peux donner un chiffre aléatoire, c'est toi,

c'est Debian huit trois. Ah merde, moi je pensais à quatorze. Bon bah faut qu'on recommence jusqu'à ce qu'on soit d'accord. T'es sérieux mec? Genre vous avez rien trouvé de mieux? Non mais c'est oui mais ça marche, ça me fait les pieds, les pieds serveurs il y a. Alors pour le coup, c'est peut être le seul composant dans le cube où il n'y a aucune aucune. Effectivement, le manager, en fait le manager et le serveur

ont une relation complexe. Mais ce que je veux dire par là, c'est que c'est un système où tu n'as pas de vraie distribution du rôle. Je Si tu veux, le système de déploiement et d'orchestration de cube. Je l'ai regardé il y a un peu plus d'un an. J'ai décidé de réécrire le système de déploiement chez nous depuis le début. Nous on fait un système d'orchestrateur qui est full distribué. C'est à dire que chez nous, tu peux tuer des bouts de orchestrateur et de l'orchestrateur, il se passera rien.

Les déploiements vont continuer à faire leur vie, il y aura aucun problème, il n'y aura aucune interruption de prod même. Tu sais que si tu tue le contrat manager, il n'y aura pas d'interruption de prod, c'est juste qu'il se passera plus rien. Le cluster de la prod de déploiement en cours, tout ça. Alors on a on a un temps de pause dans les déploiements, mais tout ne tombe pas, c'est pas parce qu'il n'y a personne pour les surveiller. Et encore une fois, ça dépend du nombre de déploiements

que tu fais à la seconde. Mais si tu veux, moi j'ai un moment, j'ai des problèmes à régler, ça entre autres. C'est un problème, je ne peux pas me permettre de m'arrêter. Alors on a été lire le truc et on était horrifiés. Par ailleurs, il y a un autre problème qui est que Cube repose sur un truc qui s'appelle Etcd pour faire sa

conférence et assume que TCD marche. Et Sauf que si pour le coup on va plus dans le monde des systèmes distribués Etcd, ça fait marrer tout le monde parce que TCD il n'est pas capable d'assurer une résilience en cas de forte charge en cas de l'expert.

Il n'a pas été jusqu'à MongoDB. MongoDB a fait marrer encore plus les gens parce que quand on l'a soumis à des stress tests MongoDB, il n'a pas seulement perdu de la donnée, il n'a pas seulement dit de la donnée qui était vieille, il n'a pas seulement imposé de la non réécriture de données. MongoDB a généré de la donnée, c'était, c'était. C'était un nouveau type d'erreur dans un système distribué. Personne n'avait vu ça. TCD Aujourd'hui, il tient pas. Il y a très peu de systèmes de

logs distribués qui fonctionnent. Il y en a un qui a été basé d'ailleurs d'après les réflexions de Google et qui s'appelle Zca et qui marche admirablement bien. C'est ce qui fait tenir Hadoop, c'est ce qui fait tenir des tonnes de choses depuis des années. C'est des tonnes de problèmes. Il avait des problèmes à un certain moment, il a été designé pour certaines choses et pas pour d'autres. La différence? Zookeeper. Mais pour le coup, c'est dit dans

la façon dont on peut l'utiliser. En fait, le problème qu'ont eu les gens, c'est qu'ils ont voulu tout. En fait, ils ont cru que Kubernetes c'était mes OS et donc ils se sont dit Chouette, j'ai un Schindler, et ben je vais pouvoir mettre mes 100 zéro zéro zéro machines dessus. Il y a des TOC dans des gens de la tech qui parlent de ça et j'ai mis mes 6000 machines d'un seul coup, avec plein de choses différentes dans Kubernetes et ça a pas marché. Voilà. Comment ne pas faire parce que juste

ils ont même pas regardé pourquoi tu dis ça? C'est ça la promesse du truc. La promesse c'est de te dire on va gérer ton infra. Non, jamais. Et vraiment. Et là, d'un coup, il. Lire tous les tweets de Kaiser Tower depuis au moins quatre ans et tout ce qui ne va pas attendre le Kaiser Tower. Je pense qu'il est atteint pour tout le monde que Chelsea Tower et a atteint le à peu près 20 mètres au dessus du sol quand il marche. Et ça fait très longtemps que Kaiser

ne comprend plus ce qu'il écrit. Mais justement, c'est très bien. C'est que je pense que les gens qui ont fait du bruit n'ont jamais imaginé le point où il en est devenu. Maintenant, c'est toi même qui m'a dit que tous les Major Pass fonctionnaient sur Kubernetes, Mais non, c'était un problème. Ouais alors il y a un problème,

c'est que c'est faux. Alors en gros non mais la notion, la notion moi je connais aucun pass qui tourne sur cube mais la bah si il y en a pas forcément des bien il y a Openshift voilà. Et sur Shift fonctionne sur un fork de cube donc admettons je te l'accorde, mais un moi j'ai jamais vu de déploiement très massif de openshift et ensuite c'est pas un des major pass qui tourne et ne vient pas sur cube. Nous sommes pas sur Cube mais heureusement Appengine fonctionne pas sur Cube et heureusement.

Non mais c'est heureusement dans un, dans un dans un certain moment. Il y a aussi juste une question de l'histoire, c'est que, à l'heure actuelle, Kubernetes peut commencer à devenir un pass, mais parce qu'en plus il est vraiment, profondément, littéralement. Ce que tu viens de me dire, c'est qu'il ne faut pas partager

son cube et en faire un indoor. Le problème que tu as quand tu fais de l'informatique, c'est qu'il faut que tu partages des ressources et que tu les partages entre plein de projets. Et alors toi tu dis non, Il faut restreindre le périmètre des projets et faire du cube un cube ou faire du cube qui est doublé. Admettons. Ça veut dire que très cube, la demande globale, c'est quelle que soit la façon dont tu le fais, admettons.

Enfin, littéralement, c'est ce qu'on va fournir, parce que effectivement, tu fais jamais du cube, tu fais toujours du cube avec les six ou sept ou quinze ou 30 projets rigolos du moment de la SNCF, c'est tous les projets, c'est marqué Alpha, mais tous les noms des call en prod. Ça me rappelle la grande époque du JCP où vous collez les alpha sur les ORM en prod, c'était bien Ruby qui n'a jamais dépassé le 0.0, Aucun projet n'a dépassé le 0.0 quelque chose.

Je connais plein de projets Ruby qui sont en prod et qui marchent très bien et qui sont toujours dans zéro zéro. Ouais non mais enfin c'est encore une fois c'est un projet SNCF pour le coup. Ouais non mais enfin moi j'ai une façon très simple de savoir quand nous on fait des choix technologiques. J'ai une façon très très simple de savoir Le projet fait partie de la SNCF à -100 points.

Il y a quand même de fortes chances pour que ce soit une béta écrit par trois personnes qui se voient dans un bar à San Francisco. Parce qu'il y a un autre sujet, c'est que la SNCF n'était pas à San Francisco, tu rentres pas dedans. Donc il y a un vrai vrai

marketing géographique. Typekit c'est des chinois alors ils ont émigré, ils sont à San Francisco. Je les ai vu d'ailleurs dans leur premier meetup à San Francisco. C'est hyper bien, c'est l'écosystème Rust et Clever. On utilise du Rust depuis toujours. Chez Clever, on a pondu un truc qui s'appelle Norme qui part sur Combinator. Et très sincèrement, quand tu fais du Rust, si en dépendance transitive il y a pas un moment où tu tires, nomme ses cheveux parce qu'on est quasiment toujours dans les

dépendances transitives. Donc on connaît très bien l'écosystème Rust et on a beaucoup de projets qui sont écrits en Rust, donc on connaît très bien les gens de Typekit. Effectivement, eux sont rentrés dans la SNCF, ils sont quand même dans la vallée et et fine, tu vois ce que je te dis juste, c'est que la SNCF, en tant qu'organisme de gouvernance, est un organisme de gouvernance valley centric. Et pour être tout à fait honnête, San Francisco centric.

Déjà la vallée c'est louche, tu vois, genre San Francisco, admettons. Tu vois, c'est vraiment la façon dont est gérée cette fondation. Moi je trouve ça un peu grave, mais toujours est il que effectivement, on va te fournir de moyens de qualité parce qu'il y a des gens qui sont rentrés dans un pattern où Cube est devenu un framework. Fine Cube est devenu leur framework. Je ne comprends pas pourquoi se

servir de cube comme framework? Parce que si ton problème dans la vie c'est de faire du système distribué, je peux te proposer une demi douzaine d'autres solutions qui à mon avis sont plus fortes. Tu prends du Erlang, tu feras du système distribué, ce sera très bien, tu auras un son, ok, tu fais ça, pique le Erlang. Mais non, c'est pas ça qui va te permettre de faire du distribué

avec des langages différents. Erlang est vraiment très bien, il n'y a pas de fait des trucs avec Erlang que tu feras jamais dans un cube. Parce que OTP qui est un système d'acteurs, est très intéressant. Si on prend un système d'acteurs d'un projet en lien chez DotNet, en Java, tu en as plusieurs. Le plus gros est probablement AKA. Ils ont fait énormément d'Aka et c'est un truc incroyable.

Je te dis, un caca ça fait tourner tout Fortnite Fortnite c'est un énorme cluster aka avec du aka persistance alors que moi aka persistance, j'aurais même pas osé, tu vois. Mais mais tu vois, ça c'est du système distribué. Quand on me dit on va coder du système distribué, tu les lancera. Le protocole dans lequel ils vont se parler, c'est HTTP. Idéal pour faire du système de distribution. On a fait mieux. Exactement. On a fait mieux et les gens

feront mieux. Et c'est ça. Tout le propos que je fais, c'est que, à l'heure actuelle, dans plein de prods, on allait En fait, à mon avis, ce qui se passe, c'est que tu as trop vu de gens bons, de gens doués, des gens qui savent faire de test, des développeurs qui comprennent ou il y a un bon lien entre les deux, etc. Pour avoir été dans plein de boîtes et même celles encore de la bouteille où tu que tu que les gars sont des tanches.

Mais que ce soit des gens de l'Obs, il y a deux trois choses qui sont pas si mauvais que ça. Je te promets que c'est parce que t'as pas vu leurs prods et c'est bien. J'ai vu des bouts de la prod pas si mauvais que ça alors qu'elle est très très très très très bien leur prod. Mais bon, en gros c'est des gens, nous on a des gens qui sont venus nous voir pour nous dire j'ai un blob à partager sur 15 000 machines, on m'a dit que c'est un blob de je sais

plus quinze méga de quinze kilos. Je vais le mettre sur le même cache parce qu'on m'a dit que c'était rapide et tout le monde a validé. Tout le monde a validé ce choix là, tout le monde, tout le management, tout le staff de tout. Un mec derrière toi et les loups et loups. On nous a demandé à la fin en mode je comprends pas, ça marche pas. Bah oui, parce que même cash c'est pas et pas une base de partagé, c'est juste à la limite on peut le garder et c'est le maximum qu'on puisse faire.

Mais en gros, c'est juste pour revenir au fait que tu as sans doute trop vu de gens où en fait c'est très bien, tu as fait des choix technologiques, humains, managériales, etc qui sont censés censés, c'est à dire qu'ils vont dans un, dans un, ils vont dans un tout et ils sont. Ça permet d'aller dans le bon sens, dans la bonne direction. Ce qu'on voit dans la plupart des boîtes où on passe à l'heure actuelle dans l'univers de la tech, c'est que

malheureusement ce n'est pas le cas. On pourrait discuter du pourquoi c'est pas le cas et tu as donné notamment l'exemple comptable. Et c'est vrai, c'est pour être à leur échelle dans un. J'ai donné une interview dans un podcast au début du mois où j'explique pourquoi on fonctionne comme on fonctionne et c'est sans doute, c'est sans doute extrêmement bien. C'est juste qu'à l'heure actuelle c'est pas le cas dans la plupart des boîtes et malheureusement, clairement malheureusement.

C'est juste qu'à l'heure actuelle, ces solutions là permettent d'être une solution transitoire, d'amener les choses. Et la principale chose qu'on dit d'ailleurs dans Uber, c'est que c'est un stresseurs de organisation. Mais le problème que tu que tu prends là, c'est que à force de faire du battage autour. Et bien en fait, on est tous obligés de supporter ce machin.

Et en fait, si tu veux, le modèle sémantique de description des services n'est pas sémantique, il est, il est, il est focussé autour des binaires des ports, il est en fait il passe son temps à faire de la tuyauterie. Tu mélanges le modèle sémantique avec ton problème de plomberie et si tu veux c'est possible. C'est juste que aujourd'hui je ne vois pas comment dans un contexte non cube, tu reprends les fichiers qui sont disponibles.

C'est à dire que les fichiers qui sont disponibles et qui sont censés décrire des choses, pour moi ils ont la même valeur que tes fichiers chef, on saura pas quoi en faire le jour où on décidera de changer de runtime. Parce que la description sémantique qu'ils ont décrit des ports et du binaire. Mais par exemple, le jour où tu décides de procréer le tout par du Quick, t'es incapable de le gérer parce que tu sais pas ce que tu peux mettre dans du Quick et pas du Quick.

C'est un peu réducteur parce que dans une description d'un déploiement, tu ne mets pas que un port et tu ne mets pas que tu vas voir, tu donnes de sémantique, tu t'oublies tout. Alors on va déjà passer sur les volumes, les volumes physiques, les accès, enfin les espaces définis. Même pas ton volume. Si t'as besoin d'aide, t'as pas besoin d'un iOS, tu as besoin de garanties. T'as jamais fait ça.

Ça c'est le principe de la story. Tu. Oh non, non, non, non, non, non, non, bien sûr que non, non non, Là, ce que je te dis, la story, c'est tu peux faire des tags. Mais tu. Non, tu ne fais pas de besoin de garantie. Tu choisis la sécurité que l'option à fond. Mais en fait, en même temps tu

ne peux pas demander. Donc on est bien d'accord, c'est pas quelque chose de sémantique dans sa description, c'est quelque chose de sémantique dans son contexte, non, mais c'est à dire que du coup ça veut dire que tout est storage class, elles ne sont pas transposables dans un autre modèle, elles sont transposables uniquement à ton organisation. On est en train de parler de truc qui a été conçu encore une fois par des gens qui n'ont pas de monitoring globaux.

Google n'a pas de cluster de monitoring global, il y en a, il y a plein de borgmann les uns à côté des autres et chaque projet a son truc parce qu'on est en train de parler de gens où effectivement ils ont résolu le problème de dire on va régler le problème global, pas on règle pas le problème global et chaque équipe se démerde. C'est pour ça que moi je trouve que c'est très bien en fait ce modèle,

chaque équipe se démerde. Moi c'est quelque chose que je prône, c'est à dire que les organisations globales. Mais moi à l'heure actuelle, vraiment, et ça c'est un fait vu et vraiment expérimenté, c'est que dans une organisation extrêmement grande ou à la tête, c'est un connard,

et bien ça se passe mal. Et en fait je préfère avoir des organisations atomiques, mais c'est juste un point de vue statistique, c'est que j'ai plus de chance d'avoir comme ça quand je suis dans une organisation pyramidale, un connard à la tête qui risque de tout niquer que si jamais j'atomise mes petites équipes, je fais en sorte qu'elles soient et qu'elles soient un peu moins.

J'ai une nouvelle pour toi. Ton problème il n'est pas technique parce qu'en fait tu es d'accord pour dire que cette techno, elle marche moyen? Non, elle marche, elle marche très bien dans son cas d'usage. Une fois que tu as fait. Une fois que tu as ta. Tu as renoncé à plein de choses que ça aurait pu régler. Tu te dis c'est pas grave, ça les règle pas ton problème, il est pas là, il était juste posé, il n'était pas réglé avant, il y avait. J'avais pas de solution pour le régler.

Mais oui, on avait fait mieux. On a créé plein de nouveaux problèmes en les faisant. Encore une fois, vous n'avez pas testé ce que nous on fait, mais on règle les problèmes. Ton problème, il n'est pas là. Ton problème, il est. Tu as toujours bossé dans des environnements managériales toxiques. Arrête de bosser avec ces gens là. C'est pour ça que je suis devenu

indépendant. Non, non, non, non, non. J'ai arrêté de bosser avec ces gens là. Tu continues à bosser avec ces gens là dans un contexte où ils te payent juste plus cher et où quand ils te font trop chier, tu claques la porte. Mais manifestement, tu n'as pas arrêté de bosser avec des gens pas toxiques. Puisque tu passes ton temps à dire je vais essayer de préserver l'équipe d'un éventuel manager débile. Et donc en fait, tu es toujours dans cette théorie de jeu politique à l'intérieur de ta boite.

Et c'est exactement ce que je disais au démarrage sur sur Docker. Vous n'êtes pas en train de régler des problèmes techniques, vous êtes en train de régler des problèmes managériaux, de comptable de ce que vous voulez. Moi je règle des problèmes de technologie, c'est à dire que mes clients, ils m'envoient des applications et ils me demandent qu'elles soient avec de la bonne sécu, avec de la bonne performance et plus jamais en entendre parler. Et ça, c'est ce que je délivre.

Et c'est pas ce que délivre Cube en fait. En gros, tu as réglé un problème algérien à leur place. Par ailleurs, il se trouve que je règle le problème managérial. Du coup, j'ai un deuxième problème managérial qui est Et du coup,

on fait quoi de nos jobs? Et moi ça c'est un sujet dont j'ai envie de parler parce que là, pour moi, les mecs de l'innovation, de l'innovation, alors toi tu as réussi à faire l'innovation qu'ils auraient du faire, mais alors moi c'est genre toutes ces boites où je suis passé et certaines très grandes et qui avaient des équipes de. Tu parlais de 100 000 personnes chez Google, mais là c'était des équipes avec des milliers de personnes et qui faisaient de la merde.

Ça on l'a tous vu dans les boîtes où on est passé et je suis bien d'accord là. En fait tu es dans un cas d'usage, dans un cas de contexte où tu as résolu le problème managérial dans ton équipe, tu bosses avec le CAC 40. Je tiens quand même à le préciser. On bosse avec des ministères, on bosse avec des organismes internationaux, tu résous, tu leurs résous ces problèmes là, C'est tout à fait. C'est à dire que c'est possible à faire si tu les emmènes dans le bon sens.

Et du coup en fait tout le monde a envie d'être heureux au travail. Et donc moi je ne vais pas me contenter d'une solution technologiquement inférieure parce que le problème de cette solution là, si tu veux, c'est que moi, ça accapare mon temps et celui de mes équipes plutôt que de fournir des choses qualitatives parce que le marché nous drive à utiliser ce machin. Et je rappelle que la grande vision dans la SNCF et dans Kubernetes, c'est quand même Elm. Elm c'est quoi tar.gz avec des

containers dedans? Encore une fois, on est en train de faire ça. Elm est détesté par toute la communauté Cube, Ce n'est pas un projet qui est dans le Nord, c'est pas le système de packaging aujourd'hui Customers qui est nouveau que je connais pas. Ah non, Custom et Customize pour le coup est quelque chose qui est intégré dans le Kubectl Kubectl. Ca c'est Customize et tout le monde déteste elle et vraiment met n'importe qui dans la communauté Un peu inclus dans

l'équipe avec des tests. Elle n'a jamais été inclue dans aucun SIG de que j'ai tapé le packaging ELM de base. Non non non non non non non non non Mais alors alors moi, pénible, N'importe qui qui me connaît mieux, n'importe qui qui me connaît sait qu'on a juste réinventé un yet another Ansible avec un templating en go, etc. Donc on est d'accord pour dire que c'est de la daube, c'est de la daube, jamais de la vie. Si quelqu'un. Non, il faut utiliser un truc qui s'appelle customers je suppose avec

un K, ça fait comment ce truc là? Alors customise le concept, C'est un système d'overlay, mais ça démarre bien. En fait, c'est un système d'overlay, c'est à dire que quelqu'un décrit son application à un moment donné, il décrit comment il le décrit via des manifeste que pour le coup on est vraiment. En fait il décrit pas une application, il dit utilise tel binaire et ouvre tel port mais fait le test. Encore une fois, c'est pas une description applicative.

Alors non, parce qu'une description applicative en théorie, si. Et ça marcherait. A la fin, tu pourrais avoir un truc qui est capable de te dire ton système d'information fonctionne comme ça, te génère un schéma, te mets les liens importants, on peut citer l'API break, ça va merder, etc. Et aujourd'hui je ne vois pas comment faire ça avec un cast. Mais peut être que de la même manière on a vu Open API ou on a vu L'okf, l'Open Container Foundation, on va avoir une description.

Donc là la croyance non mais on en a déjà un. Il y a je crois deux projets dans la SNCF pour essayer de standardiser ça. Pour le coup, même pas. À chaque fois que les gens se rencontrent dans un bar à SF, ils créent un projet alpha à la SNCF. Donc oui, il y a certainement des projets. Est ce que pour autant ils vont être successful? Mais probablement imaginer que pour écrire des trucs avec les builtin. Mais je pense, Mais j'ai une petite requête quand même parce que là je

dois dire un avantage, mais bon. En tout cas un fait sur Kubernetes, c'est qu'il est avec Docker, c'est que ce sont des technologies qui sont accessibles, elles sont au delà du fait qu'elles soient promues et et vantées et marketées. Elles sont accessibles, elles sont simples, elles sont simples. Aujourd'hui, ton premier déploiement cube, ce n'est pas un truc qui s'effectue en quatre minutes, c'est un truc. Si tu prends la bonne personne

en quatre secondes. Excusez moi, mais ton premier déploiement cube, il faut écrire un putain de manifeste. Il faut faire une image, il faut avoir un cluster en admettant que tu utilises. A la rigueur, c'est une ligne, c'est kubectl create create et c'est terminé en une ligne de clé. Je suis désolé, tu n'as même pas besoin de faire de YAML. Je compare encore une fois avec un pass comme nous et tu fais un git add remote git push. L'outil que tu utilises tous les

jours en tant que développeur. Alors tu vois Cloud machin, qu'est ce que tu as lu? L'article que j'avais fait sur mes concepts de phrases complexes? Je termine, je termine ma remarque. C'est le concept de. OK, c'est une technologie qui est installée, qui est accessible, qui est documentée, qui est simple et qui est partagée par tout le monde. Comment? Si moi je ne veux pas utiliser cette technologie là et je veux me rapprocher des concepts plus sécurisants, plus partagés, plus que

vous proposez, est ce qu'il y a une. Une manière, une méthode, une documentation, une fondation qui me permet de collaborer, de travailler, de travailler de la même manière que vous. Mais bien sûr, tu t'inscris sur notre système. Non, mais sans passer par votre système. Mais tu peux, tu peux le télécharger, le mettre chez toi, mais ça veut dire demain. Là, je vais trouver des gens compétents pour pouvoir le maintenir avec moi, bien sûr. Bien sûr, aujourd'hui, c'est le service qu'on voit.

Est ce que tu me demandes? Est ce que tu peux l'avoir gratuitement et ne jamais, jamais, ne jamais? Moi j'adorerais le faire en open source. On fait énormément d'open source chez Clever et j'adorerais le faire en open source. Pourquoi est ce que Clevercloud en entier n'est pas open source aujourd'hui? C'est très simple. Je ne connais pas de boîte open source qui gagne de l'argent sans se faire racheter. Non, non. Qui gagne de l'argent tout court?

Je veux dire, il y a des boîtes de service qui ont acheté des boîtes d'open source. C'est le cas d'IBM qui a racheté RedHat et RedHat. C'était déjà essentiellement une boîte de service. Et aujourd'hui, je connais des vici qui foutent la pression à des boîtes. Je connais des boîtes qui ont créé des beaux produits et qui vendent du cloud service et c'est c'est ce que fait Elastic. Et ils galèrent parce que face à eux, il y a Amazon qui pille leur propriété intellectuelle.

Et prenons des cas comme docker. Techniquement, la boîte a manifestement pas de revenus et donc avait un problème avec le modèle open source dans le cas présent pour générer plein de problèmes. Et c'est pas compliqué. Moi sur l'histoire de l'open source de Clever, c'est une question que je pose régulièrement à des salles remplies et je dis moi j'ai envie de mettre Clever open source demain, qu'ils utilisent la salle entière qui sera prêt à payer pour ça? Zéro personne. Je suis désolé les gars,

il se trouve qu'on mange. C'est con, mais on mange. Donc est ce que par contre, en utilisant Clever, tu permets à des technologies plus fortes d'avancer et nous permet d'open source et plus de trucs et nous permet d'avancer? Oui, clairement. Par contre, à un moment tu ne peux pas me dire votre discours à vous, il parait cohérent mais je peux pas l'utiliser gratos. J'attends et je parle même pas de gratos, c'est à dire c'est d'utiliser

les mêmes fondamentaux en fait. En fait, la logique moi que davantage on fait de la virtualisation notre distribution Linux, pour le coup, elle est complètement open source, c'est que tu peux l'utiliser. Les fondamentaux qu'on utilise, ils sont, ils sont là. Enfin c'est pas très compliqué. Est ce que tu vois, on a construit tout le monitoring sur du. Est ce que c'est clé en main? C'est pas clé en main. Aujourd'hui, Kubernetes c'est clef en main, c'est en main. Si tu l'achètes à clé aujourd'hui

qui fait du Kubernetes Vanilla? Tout le monde fait du geek, donc c'est la même histoire, non? Enfin, en tout cas, parmi mes

clients, il y en a peu qui font du GPL en même temps parce qu'on dépasse un certain nombre de certains, mais il y en a, il y en a beaucoup, enfin vraiment à l'heure actuelle, des gens qui font vraiment du geek. Malheureusement, en France, on va faire simple, tu vas dans la moindre conférence de dev, tu fais qui utilise Kubernetes, tout le monde lève la main et tu fais qui utilise Kubernetes sans gcos,

sans minikube. Maintenant tu vas dans une conférence de DevOps, tu dis qui utilise machin et tu verras qu'il y aura 50 % de gens qui font du in-house sur du bermuda, du cube spray et du cube spray, et du Archos et du machin, etc. Tous les jours tu t'adresses pas aux bonnes personnes et c'est vrai que ça dépend beaucoup du profil, mais moi, à l'heure actuelle, à l'heure actuelle, la plupart des gens qui me parlent et c'était même le cas de la BNP etc, c'est que il faisait du IN ou en tout cas,

et la plupart des boîtes françaises ne veulent pas payer et elles veulent faire du Linux gratuitement et c'est un problème français. Et avoir le savoir faire interne plutôt que de mais même pas parce que les gens ne veulent pas regarder les sources genre je suis d'accord, si jamais il y a quand même des sources quand tu les regardes, tu arrêtes, tu arrêtes d'utiliser le soft. Encore une fois, nous on fait tout source basse, donc on fait

beaucoup de lectures de sources. Il se trouve que si tu veux, parce que c'est vraiment très bien dans ce que je dans ce que je reproche à Cube, il y a trop de son orchestrator.

Je comprends pas comment tu peux gérer de grosses infra dessus l'orchestrateur quand on a voulu changer notre orchestrateur le ce qui est douleur, ce qui est la partie, la partie scheduling de cube, moi j'ai été la lire il y a un an et des bananes parce que je voulais réécrire l'orchestrateur de le scheduler de Clover et je me suis dit si ça se trouve, on pourrait utiliser Cube. Non? Mais alors ce qui est douleur de clavier, sans déconner,

c'est le cube. Le ski douleur. Son algo, c'est celui qu'on avait en 2014. Le ski Douleur de cube, Pour le dire clairement, pendant très longtemps, n'étaient même pas inclus dans le projet. C'est à dire qu'en fait c'était un projet optionnel qui était mis comme étant ne l'utilisez pas, il est débrayable à n'importe quel endroit et il est dit clairement que si jamais vous voulez faire de la prod, il faut en utiliser un autre.

Je connais au moins trois boîtes qui vendent des scheduler cube propriétaires en disant le scheduler de cube ne marche pas, tout le monde le sait et ce n'est pas un problème. Vous pouvez utiliser l'autre. Kubernetes est juste une boîte à outils. C'est fait aussi avec plein de projets qui se mettent dans la boîte à outils. Vous auriez pu créer le propre orchestra. On a on a notre propre. Il aurait pu très bien se brancher dans Cube. Alors le problème de le brancher dans

Cube, il est sémantique, c'est à dire que. Vous passez juste à côté. Vous frôlez le concept d'extensibilité de Kubernetes et de Standard API. Et c'est pour moi, c'est là où est la vraie force, c'est là où tu me dis ton déploiement. Il gère pas ça, il gère pas ça, il gère pas. Le concept de je suis, de savoir ce que c'est qu'un bord, il gère pas. Et non, tu peux étendre l'API exactement comme tu veux. En fait le truc c'est que pourquoi moi je le ferais?

J'ai un truc qui marche, j'ai pas besoin de cette couche là. Enfin, quand tu me dis tu devrais l'utiliser, je te dis non parce que quand tu marches avec quelqu'un, ne serait ce que le concept de tu vas embaucher quelqu'un, il connaît très bien, il connaît l'API Cube. Très bien. Voilà. J'ai un opérateur spécifique qui gère le protocole réseau Tartempion et qui interprète ce truc là.

Tu as besoin, tu as besoin. Après, tu peux réutiliser tous les soucis, tu peux réutiliser machin des langages communs. Pour tous les métiers de l'IT. Bon d'accord, faudrait que je réécrive le scapulaire, faut que je réécrive le runtime parce que là, je peux pas, je peux pas me servir, je peux pas me servir du container et pour le coup tu viendras directement. Je suis toujours pas d'accord

pour utiliser des modèles. Enfin j'ai ellipser tous les binaires et le kernel à part moi je suis toujours pas d'accord donc vire vers je sais plus quoi là. Non mais non mais on va arrêter avec les il est bien dans son nom mais en fait. Donc il faut que je réécrive un runtime parce que si tu veux, à chaque fois qu'on me dit il y a un truc déjà dans le cube mais tu as déjà fait. Oui mais il marche aujourd'hui donc je vois pas pourquoi j'irais me taper une API.

Enfin, encore une fois, tu as déjà regardé à quelle vitesse bouge l'API de Cube? Franchement, les mecs ont aucune notion de versioning de l'API, elle bouge à tous les commits, c'est incapable. Ça me rappelle la grande époque de Docker à une époque, une époque de docker. On avait un client, le client, le client est flingué la tête. Non non, le client go est une merde. On est entièrement d'accord dessus. Sa compatibilité avec l'API est absolument si on compte donc l'OS

qui est douleur est de la merde. Le client GO est une merde. On compte tous les trucs où tu finis par me dire ouais mais non mais quand même. Alors alors alors le truc, le truc, le truc, tout est moisi, on est d'accord, c'est une techno de daube. Mais non, mais en fait. En fait, j'ai l'impression que tu montes une espèce de cathédrale et t'as envie qu'elle soit parfaite mais malheureusement qu'elle soit parfaite. Je fais de la prod, l'informatique, si ça pète, j'ai un problème.

L'informatique c'est pas parfait. Et bah en fait en gros non mais la question la question c'est est ce que c'est du lourd? Tu l'as ton runtime, tu l'as. Moi je te pose, je te repose la même question maintenant. Moi qui suis chez des clients, j'ai des clients, ils ont rien, ils sont à table rase, ils sont à poil. Et t'es en train de me dire était en train de me dire il ne faut

pas qu'il le fasse en interne. Mais mais moi, la question de la différence, voilà peut être là les américains, les américains qui balancent des bêtas dans la cncf quand ils se font prennent un café ou une bière à San Francisco, Eux, ils s'en foutent que ce soit parfait, ils s'en foutent que l'application elle soit hyper secure. Eux ils veulent, ils ont un problème, ils ont une potentielle solution, une feature, ils la font,

ils font la MVP, ils la font paf! Nous capturent l'espace marketing au sein de la SNCF pour assurer que personne d'autre ne puisse concevoir quelque chose autour de ça. Peut être on est sur autre chose. C'est leur stratégie, c'est leur vision des choses de ce soft. Nous, ce soft, il a existé parce que Google avait envie de jouer Docker et ça très bien. Toi, non, tu es parfaite. Donc non, non, Kubernetes, ça a fâché ça.

C'était Google qui était très fâché à propos de Docker parce que Docker avait fait des conteneurs et que c'était Google qui avait fourni tous les patchs dans Linux kernel pour faire des conteneurs. Enfin une bonne partie. Non, non, non, c'est avec LXC avant, mais alors bien avant. Et qui en a fait une tonne pour en avoir fait. Regarde de près d'où venaient les patchs de spacing du kernel. Je te jure que Google est Google

repose sur les conteneurs. Oui, voilà, les conteneurs Google, encore une fois, c'est leur monde à eux et c'est très compliqué d'en parler. Mais ce que je veux dire par là, c'est qu'il était furax. Et il se trouve que quand Docker a poppé, tu vois, il était. Mais tellement furax qu'ils se sont dit on avance. Ils ont proposé un rachat qui n'a pas été accepté par Docker et du coup ils les ont pris en grippe et Kubernetes.

L'objectif était d'empêcher Docker d'aller anyway à la prod et ça a été la fameuse guerre des Orchestrateurs qui a duré huit dix mois, dans laquelle ils ont fini par gagner pour une raison simple ils ont plus d'argent et c'est aussi simple que ça, parce que c'était aussi bien meilleur que Swarm. Si jamais il faut faire ça, alors là, technologiquement, tu peux pas me dire que Swarm était même un tant soit peu, mais alors même pas de très loin.

Je suis d'accord avec toi technologiquement Swarm, j'ai toujours trouvé que c'était daubé par contre. D'un point de vue usabilité de l'utilisateur. Je suis désolé, c'était beaucoup plus simple et j'ai même envie de te dire une chose c'était l'argent. Mais oui, bien sûr! Mais en fait le truc il est toujours là. Même moi j'ai l'impression de répéter en boucle les mêmes histoires.

On me dit la composabilité, la modularité, la maintenabilité et surtout, une fois que tu as un standard, tu pourras prendre des blocs, en remplacer. C'est le discours qu'on avait sur Java cinq ou 1.4 au sein du JCP. Et en fait c'est Websphere ou Weblogic. Franchement, ça a jamais été la même chose. Dans dix ans ce sera la même chose, Dans 20 ans, il n'y aura jamais une universalité comme il n'y aura jamais un système informatique qui marche.

C'est une illusion, on est d'accord. Le Standard, en fait, c'est un foutage de gueule dans le cas présent. Et donc du coup, tu en veux, tu en veux un descriptif? Un standard sémantique? Oui, mais alors sémantique et sémantique? J'ai l'impression de voir le xkcd qui est oh là là, il y a quinze standards, c'est nul. Je vais créer un standard pour tous les unir tous. Il y a maintenant seize standards. Non, non, c'est pas vrai parce qu'on a déjà des standards sémantiques qui fonctionnent.

Aujourd'hui tu fais ta dépendance de projet en Maven où tu décris tes dépendances de projet. Ça fonctionne et aujourd'hui tu as plusieurs softs qui s'en servent et ça marche très bien et c'est un format qui n'a pas bougé du tout. C'est pas du tout une description sémantique. Tu dis explicitement la librairie dont tu as besoin, tu ne dis pas il me faudrait un truc qui fasse

de la DB. Et bien si, justement. Parce qu'en fait, vu qu'avec les plugins tu modifies ces trucs là, tu es capable de le faire. Et justement avec des plugins qui sont des opérateurs, tu peux le faire. Ben non, bien sûr, ça n'a rien à voir parce que tes opérateurs ils gèrent des binaires mais pas forcément les opérateurs. Alors moi j'ai créé des opérateurs dans la vie qui ne font rien, mais alors vraiment rien du tout, comme des binaires. Moi je te paye pour ça.

Les mecs ils disent non, il fait des opérateurs qui font rien. Si vous voulez me payer, vous pouvez payer, je fais quelque chose et alors? Sans aucun frais. Mais non, justement, le concept même d'opérateur est justement les serveurs pour moi est une beauté absolue et qui devrait d'ailleurs sortir du projet Cube tellement elle est bien. Mais vraiment, elle devrait devenir

bien. Ils sont en bêta, tu vois? Non, non non non, Moi je parle vraiment de l'API Server. Et puis maintenant il y en a beaucoup qui sont sortis de bêta pour le coup et et non l'API serveur en elle même, sa notion de déclarativité de gestion, même interne, mais vraiment,

mais à plein de niveaux. On n'est pas dans ton cube donc je vais essayer de pas trop en parler technologiquement maintenant, on pourrait refaire quelque chose là dessus que sur l'API server, mais justement je trouve son modèle déclaratif de gestion du workflow etc dedans, mais extrêmement dramatique. Enfin, il y a dans combien de déclarations de service cube? Tu as une espèce de truc avec un slip et un end et ce genre de choses? Enfin, t'es quand même au summum

de la question de la catastrophe. Alors personnellement, si jamais un jour je l'ai fait dans ma vie, il faut tout de suite me taper. Et je ne l'ai jamais fait. Jamais, jamais, jamais, jamais de la chance. Parce que moi, tous les gens que j'ai vu faire du cube, tu te finis par des trucs dans un watch. Parce qu'encore une fois, le Watch ne sait même pas ce qu'il fait, ce qu'il essaye de checker. La seule chose qu'il renvoie,

c'est un code de retour. Encore une fois, je te renvoie, il te renvoie, il te renvoie le la ressource que tu voulais et un numéro d'incrément à l'endroit où tu es, comme souvent. Et après tu viens get cet endroit là et tu l'as. Et après quand tu refais un Watch revient à partir d'un niveau D'incrément et il va te dire non, c'est vraiment purement bien fait.

Tu sais exactement quelle est la ressource qui est updater etc. C'est c'est pour le coup tu fais un Watch le Watch vraiment, le TPIY, le watch de ressources, le watch d'objet en ce sens que tu parles des objets cube, je parle des objets cube.

Ah oui non mais alors là pour moi non mais en fait non parce que en fait ça c'est fourni sous forme d'une API à pull, alors que ça, ça devrait être un flux ça on est dans un cas Cqrs est une notion de flux, pour le coup, bah c'est une notion de flux qui ne se comporte pas comme un flux puisque tu es en train de l'appeler. Donc en fait il y a quand même un souci là dessus, mais c'est lié à ce qu'il t'envoie. Il t'envoie oui, mais justement il

t'envoie, il t'envoie, il t'envoie. Une notion de Watch donc en fait oui, c'est du pull, mais ça ressemble furieusement à un push quand je peux watch une resource et surtout quand elle est quand elle est dedans. La différence c'est que t'as pas de reproductibilité de ton cas Cqrs Tu vois ce que c'est que cqrs? Ben oui, mais tu vas encore pouvoir. Je pense qu'on a des gens qui savent que c'est une façon de définir votre

flux de modification de la data. C'est à dire que quand on s'est mis à avoir beaucoup de place sur les disques durs, on s'est rendu compte que ce qui était intéressant, c'était moins le monde tel qu'il était que l'évolution des logs. C'est comme ça qu'on a fini par faire du machine learning. Parce qu'en fait, le machine learning, c'est une évolution numérique en fait. Autrement dit, il te faut un flux dans lequel tu as l'ensemble des

événements de modification et cqrs. Ça veut dire ou je sais plus le c'est mais c'est selection query et et je sais plus non plus. Mais toujours est il que ton flux cqrs, c'est le flux de l'ensemble des ordres qui concerne ta donnée, qui vont, qui vont, ce qui vont se linéariser et qui sont dans un état. Non, tu ne peux pas changer l'état. l'Ordre dans lequel c'est fait, c'est ordonné, c'est propre et c'est ce qui te permet de reproduire le même dans un système

où tu n'as pas ce genre de log. Ça veut dire que tout étape de forensics sera extrêmement pénible. Et c'est pour ça que si tu veux, j'ai un problème global avec la SNCF, c'est que tu as énormément de projets qui sont pensés pour le ça va bien se passer et notamment Prometheus qui est l'autre sujet dont on pourrait parler des années

où il y a un énorme problème. Le truc n'est pas capable de prendre de la data, ce qui veut dire que ton forensics, tu ne l'auras jamais de ta vie. Et donc en fait, pour moi, tu as un agrégat de projets entiers qui sont pensés dans un axe qui pour moi ne règlent pas les soucis. Alors oui, quand tout se passe bien, vous êtes démodé. Oui mais en fait le truc c'est que moi je les ai réglés les soucis à mon échelle.

Et aujourd'hui le problème que j'ai, c'est qu'il faut que je prenne mon modèle qui marche, qui est sémantique, qui est propre et que je le casse en permanence pour faire rentrer un carré dans un rond et qu'on me dit en permanence sur Twitter Quoi, tu n'utilises pas Kubernetes? Mais pourtant tu devrais l'utiliser et d'ailleurs tout le monde dans ta branche le fait alors que

personne dans ma branche. C'est à dire qu'on a un problème de bruit autour de cette technologie là qui peut régler des problèmes, mais des problèmes pas si grands, pas si pertinents, pas si importants que ça. Alors c'est une technologie qui certes dans certains cadres peut aider. J'ai été foutu de la prendre sous cube pour rigoler. C'est très pénible parce que du coup c'est le machin qui sonne le

plus souvent dans mon monitoring. Mais vas y je t'assure, c'est ça dépend mais j'ai vu des install cube complètement merdiques. Il y a des gens qui font des talk meetup pour expliquer comment faire du cube. Tu regardes ce qu'ils ont fait, mais surtout pas le problème de parler d'une techno qui by design. Tu as tellement moyen de t'en servir n'importe comment.

Prendre une technologie respectable actuellement, tu vois, prenons Rust, c'est quand même un techno où dès que tu mets un point sur la ligne jaune, le compilateur t'engueule. Ça, c'est une technologie que je trouve incroyable qui va changer le monde. Bon d'accord, mais alors recompile Kubernetes en Rust et je te promets

que tout le monde te suit peut pas. C'est un tas de galimatias, de lignes de go. Et par ailleurs, il y a un autre problème dans le fait de recompile quoi que ce soit dans Kubernetes, c'est que le projet est tellement politique que ça me rappelle la grande époque de l'open stack où le moindre commit dans OpenStack, tu as plus de négos politiques que de technologie et c'est la même chose. Tu veux faire passer aujourd'hui des commits donc tu ne peux pas.

Je confirme. Et donc tu es sur un projet qui est fauxpen source dont les implémentations les plus utilisées sont en fait des implémentations qui ont été bricolé en interne. Donc GK en est une et c'est pour ça qu'il va en Antho parce que CG Canyon c'est littéralement En fait c'est pas cube donc tu es sur, tu es sur un mouvement assez blessant tu vois je trouve, tu ne peux pas aller commiter dedans et en plus le truc est d'une politique.

Enfin genre tout ce qui faisait OpenStack pour avoir connu la grande époque de OpenStack. Clairement, Kubernetes essaye de ne pas ressembler à OpenStack pour une raison et une énorme qui est. Tu pourras dire que le Cncf ressemble au projet Tante sur sur OpenStack, mais à ceci près que déjà un il n'y a pas de verrou technologique. C'est que avant, on se souvient OpenStack, tout devait être fait en Python et uniquement en Python et qu'on est tout Python.

Beaucoup de projets de la SNCF qui sont fait en autre chose que le client. Le meilleur projet de la SNCF, clairement. Je veux dire, si tu as besoin d'aller écouter des logs à peu près une ligne de logs à la seconde, ça marche. Et pour les parties critiques, bah non mais non, il y a les parties classiques. Non c'est vrai, c'est vrai que la plupart, la plupart des systèmes, il y a une espèce de pattern sur les collecteurs de logs parce que c'était la même chose, c'était du rugby.

C'est juste que Logstash les mecs avaient dit non mais c'est en Ruby, mais c'est fait pour tourner sur git Ruby. Du coup ça semble aussi donner la parole, genre il fallait quand même vraiment il y a des gars, il y a les gars qui ont c'était fait pour tourner sur Jruby alors ça a toujours été fait pour tourner sur Git Ruby en first Deployment, ça a toujours été pensé comme ça et et c'est pour ça que ça tenait la charge.

Et oui, la machine Ruby, enfin Ruby en tant que langage et en tant que écosystème a plein d'intérêt et Ruby en tant qu'écosystème, surtout en tant que écosystème, ça a été génial. Et merci à Word et merci à plein de trucs. Cela dit, la portabilité du Ruby, certes en Step One, elle fonctionne en step deux. Dès que tu commences à utiliser des trucs un peu touchy, tu étais sûr que tu es obligé de recompiler pour pour des plateformes X ou Y enfin rencontrés de près.

Il y a un autre souci la librairie Elastic. Certes en rugby elle est merdique, elle appelle l'alizé et compagnie, mais ça c'est un autre souci. C'est qu'en fait en rugby, comme tu as des problèmes de perfs du renard, du coup tu as des gens

qui vont faire des pas chassés. Le problème c'est que c'est des développeurs rugby qui vont faire le patch, donc pas nécessairement des développeurs C. Après, j'ai beaucoup de griefs contre C, donc après on peut me lancer sur C. Et donc du coup tu te retrouves avec un problème qui est que tu as un mélange des deux et tu as ce problème là.

Et du coup ce problème là, il se répand à un moment où tu compiles en jruby et là du coup les parties en C, tu es obligé de les appeler en jihna et. Et les conteneurs, c'est bien parce que à ce moment là et non les conteneurs ne règle pas le soucis. Ta stack techno est toujours une énorme merde, c'est juste que tu as fait un joli paquet rose au moment où c'est tombé en marche. Tu as fait des photos? Ah putain, vas y! Genre gros modèles justement, les photos, les photos.

Ben nous on a fait ça, donc pas de photos encore, mais ça va. Encore une fois, vous êtes, vous êtes dans la perfection et dans la. On n'est pas dans la perfection. Nos clients à nous, ils sont répartis dans 50 pays dans le monde, Ils sont des milliers, différents, ils codent pas du tout tous pareils. Et donc ce que je veux dire, c'est que mon modèle à moi, il fonctionne à large échelle, c'est à dire qu'il fonctionne avec des gens qui ne se sont jamais

rencontrés, qui à large échelle. Le client est ce qui marcherait à large échelle d'entreprise, c'est à dire vraiment vous en tant que tel. C'est à dire je te mets 100 000 développeurs, 100, c'est une question, c'est ce passage à l'échelle entre guillemets. C'est une blague? On est entre nous, c'est si tu veux, si demain on me donne 100 ou 200 développeurs de plus que j'ai sélectionné. Non, non, c'est la question.

C'est pas ça. Si, si, demain on prend ta technologie et on la balance chez Microsoft, je prends ta technologie, je la mets à la BNP. Il se trouve que ma technologie est à la BNP et ça marche. Je reçois la BNP, bien sûr, mais tu me demandes à la Belle parce qu'elle est à la BNP et ça marche avec des scale scale à la BNP. C'est à dire ça marcherait si tu mettais plus de serveurs, Enfin si tu veux. L'idée, c'est que l'idée c'est qu'à partir du moment où tu répands ta

technologie, tu n'en es plus maître. Donc tu es obligé de. De la diluer, de prendre des raccourcis et de et de faire des choses. Non mais toi, aujourd'hui tu es maître parce que tu es. C'est ton offre commerciale, c'est ta technologie, c'est ton c'est ta vision. Mais et qu'elle convient à mon entreprise, Elle convient à des objectifs business, techniques et compagnie. Mais aujourd'hui, Kubernetes, ça ne peut pas convenir à une

vision vu par essence. Par nature, c'est fait pour tout le monde et puis pour tout le monde, sauf sauf les clients qui n'ont pas le droit de commiter. Et maintenant je veux bien qu'on entende le disque, mais c'est en fait, c'est mon vrai projet OpenSource. Premier kernel Linux 1200 développeur qui collabore sur des cernes de trois mois et qui réalise des trucs avec des gens qui ont des problèmes extrêmement variés.

Tu as des gens qui font de l'embarqué, tu as des gens qui font des serveurs haute performance, tu as des gens qui font du temps réel, tu as des gens qui font des HPC et tu as des gens qui font tourner des Raspberry Pi. Les besoins sont extrêmement variés. Résultat des courses, le machin fonctionne les mecs, pour le coup, non, c'est exactement pareil et pour le coup d'expérience,

mais vraiment d'expérience. Moi je connais des gens qui mettent du Kubernetes dans des avions et dans des avions de ligne dans des Airbus. Oui, alors là moi je les prends plus. Alors ne prends plus les Boeing non plus. Non mais non, mais à l'heure actuelle, ça fait tourner le système média. Oui, tu vois. Enfin donc encore une fois, on est sur le marketing du du t'as vu, ça fait tourner des avions, on va tourner des avions, ça fait tourner.

Le X était dans des avions bien fait donc ça fait tourner Google, sauf quand ça fait pas tourner Google, on est d'accord, ça fait ça. Alors pour le coup, je me suis dit qu'il l'utilisait chez Google, il l'utilise et en plus c'est même pas moi qui disait ça. Sous entendu c'est même pas moi, c'est pas moi qui avait cet argumentaire là. Je t'ai dit que l'argumentaire ça tourne chez Google était pour moi un argumentaire faux.

Je me souviens du débat pepettes vs chef vs sensible et tout le monde était ah ouais mais moi mon truc il est utilisé chez Google mais en fait tout le monde pouvait répondre la même chose. Donc donc le machin est là, ça fait pas tourner les avions parce qu'en fait ça fait tourner les systèmes médias des avions dans des avions. Et en fait en gros, c'est juste le spectre.

Tu m'as dit tout à l'heure les Raspberry Pi, les Raspberry Pi, il y en a qui mettent des cubes sur des Raspberry Pi et ça marche très bien. Non mais je sais que ça tourne sur des Raspberry Pi. Ce que je veux dire? Tous les endroits que tu m'as dit tout à l'heure, ça marche. Oui, mais lancer des binaires, c'est lancer des binaires. La différence est que le kernel fait quand même beaucoup plus de choses vu qu'il gère le hardware. Heureusement. Donc on n'est pas du tout sur les mêmes choses.

Quand je te dis c'est un projet qui est open aujourd'hui, tu peux aller contribuer dans le kernel, c'est facile. Je vois quand même un avantage, on t'en a pas parlé avec l'extensibilité et compagnie, mais surtout, c'est un outil. Et comme par essence, n'importe quel outil, que ça aille du marteau au tractopelle jusqu'à la fusée Saturn V, c'est fait pour. Pour démultiplier la force et l'effet d'une personne. Et aujourd'hui, cet effet là, il est complet.

Pour moi, c'est une réussite totale bien sûr, et la scie cloche aussi. C'est juste qu'aujourd'hui on me présente le truc comme étant le couteau suisse. A mon humble avis, c'est une scie cloche, éventuellement c'est une scie cloche qu'on pourrait déplier, ça coupe des trucs. Non, ça ira pas plus loin.

Il y a cinq ans de ça, il y a cinq ans de ça, quand il a été créé, oui, c'était un outil qui répondait qu'à une seule chose à l'heure actuelle, vu l'extensibilité de l'API Server, clairement, c'est un couteau suisse. Il est devenu ici avec, il est devenu, il est devenu cette humanité. Bon ça il y a toujours pas d'unification du monitoring. Je vois pas comment les opérateurs. Le premier opérateur ici, il est

stable, il est opérateur sérieux. On peut vraiment faire du monitoring sur Prometheus, c'est vraiment Monitor, c'est dynamique, on est vraiment en train de parler de ce machin là. Oui, vraiment. Et alors là, pour le coup, par rapport c'est vrai que je parle de boite où le monitoring passe dans des logs et c'est des boites. Encore une fois, c'est pas parce qu'il y a des gens qui font n'importe quoi, mais justement c'est la majorité,

c'est la majorité. Et alors du coup on va aller vers un truc médiocre alors qu'il y a des trucs très bien, Aller vers du mieux c'est, c'est pas médiocre en fait, c'est ça le mieux, le mieux en fait. En gros, à l'heure actuelle, c'est que tu as une vision, tu vois le haut du panier, on est tous d'accord avec ceux du haut. Oui, mais tu comprends, tu comprends que le problème qu'on a est que aujourd'hui, à force de faire le battage de cette techno là, c'est que nous, pendant ce temps là,

qu'est ce qu'on fait? On attend que les gens améliore leur truc, contribuer, contribuer à ça. Comment on fait pour contribuer à cette technologie? Parce qu'aujourd'hui personne ne fait sa vie dessus. En fait, si tu veux, c'est très simple, un hébergeur pour un hébergeur, c'est plutôt simple, c'est pour un éditeur de logiciel, C'est pas simple du tout ton hébergeur, tu peux très bien gagner de l'argent en proposant des Kubernetes, C'est non. Je vais en gagner un peu et ça va

me coûter une fortune en support. Aujourd'hui, chez Clever Docker, c'est à peu près 8 % de run time, 40 % de demande de support. Ça, c'est la réalité des conteneurs. Tu vois, moi c'est pour moi, c'est catastrophique. Pourquoi c'est le cas? Alors moi je suis entièrement d'accord avec toi. Et enfin avec ça, c'est le pourquoi. Pourquoi?

Parce que, en fait, la notion même des conteneurs et la notion même de Kubernetes, c'est que, à la différence du passe, c'est que à mon sens, c'est phrasèmes complets. Alors qu'est ce que, qu'est ce que j'ai inventé en notant ce mot là? C'est que tout comme dans la dans les phrases complètes, en fait, c'est que tu connais le Turing complet. Ouais, et ben en fait c'est la même

chose pour de l'infrastructure. C'est que moi, demain tu me donnes un passe dans lequel je peux pousser mon code, c'est que est ce que je peux pousser n'importe quel code dans n'importe quel langage sur ton passe? Elle est là la question Almost almost? Et c'est ce almost là qui te répond avec du docker. Le problème c'est que Docker en fait, si tu me dis n'importe quoi dans n'importe quoi docker, tu ne peux toujours pas les supporter dans Docker et donc ça ne marchera pas.

Alors c'est que si par ailleurs ce que tu appelles le complet, c'est se balader avec un t shirt qui dit je suis la personne qui jette les pull request des gens de systemd, c'est être complet. Je suis pas sûr que ce soit les plus grands instants de gloire. Non mais c'est pas c'est pas le nom. Puis en plus comment ça anecdote a toujours été la personne open et en plus elle ne l'est pas forcément.

Mais tout comme Turing n'était pas. Enfin genre Turing n'était pas une personne à mon avis agréable à fréquenter tous les jours, je sais pas voilà. Mais je sens tout ça. Je comprends pas pourquoi.

Alors c'est juste fallait trouver un nom et voilà. Et tu avais de la chance, j'ai le choix entre être Hightower et Fraselle. J'ai choisi Fraselle. Non mais je plaisante, si tu mets Cube dans un avion parce que là du coup, je peux croiser Casey. Sans déconner, tu comprends de quoi parle de quelques années? Parce que honnêtement, Keyser, très sincèrement, tu sens que le mec qui il passe un temps fou à discuter avec des gens etc. Mais je pense que ça fait très longtemps qu'il n'a pas tapé la

moindre ligne de code pour le coup. Alors c'est peut être parce que j'ai pas tapé assez de lignes de code, mais ça date d'hier donc peut être c'est pas assez longtemps, mais si clairement. Enfin moi je comprends ça parce qu'en fait le truc c'est que en effet, c'est une notion d'écosystème et sans doute que notre écosystème, et c'est ce qui se passe à l'heure actuelle dans même la compréhension qu'on a de Kubernetes. Même expliquer Kubernetes à

quelqu'un. Maintenant, expliquer que ce n'est pas un cas, je passe mes journées à ça, donc sans doute que oui, on est parti trop loin. Kubernetes c'est. Alors j'en suis ravie. Pour moi, Kubernetes est en train de le faire. Enfin, il fallait qu'il fasse depuis le début qu'il est en train de OpenStack, mais c'est d'une complexité monstrueuse. Et aujourd'hui, il y a des gens qui vont faire main basse. Justement, on aimerait devenir un framework et fin de l'histoire. Mais il faut dire que j'ai vécu

les deux. Comment on peut dire que Kubernetes est complexe? Kubernetes c'est fondamentalement c'est quatre composants, peut être cinq si on compte Etcd, mais c'est l'API, c'est le scheduler, le contrôleur manager et un ou plusieurs kubelet. C'est des trucs dedans et pénible en fait. Non, non, non, non, non, non, non, non, non. En termes de en termes de complexité. Juste de comprendre comment les choses peuvent faire tourner dans Cube. J'ai failli manger un OpenStack,

j'ai jamais fini la doc. Enfin non, mais il faut juste en arriver là. La première version de serveur et pendant des mois, les gens attendaient au dessus D'openssl. Et un jour je suis rentré dans le bureau et j'ai fait Bon les gars dans un mois et demi machin dégageait alors Alors bon, moi mon premier projet Cube c'était d'installer OpenStack avec Hibernate et ça marche très bien. Mais vraiment très très bien.

Bon, la boîte qu'il a fait est en train de tomber, mais encore pas à cause de problèmes techniques, mais à cause de problèmes managériaux. Et c'est encore le cas. Tu as, tu as, tu as. Le rituel est vraiment un logiciel vraiment très simple. C'est pour ça que c'est une brique que tu peux mettre facilement sur des Raspberry Pi que je veux dire sur Cube. J'ai cru que j'allais mourir, mais le problème c'est pas c'est

pas grave, c'est pas. Je vais te dire, je connais des clusters à base de 259 qui ronronne et qui sont gérés par une personne en carton parce que c'est des clusters. Là pour le coup d'une centaine de nodes de cubes à des personnes pour les gérer et ça je le reconnais et le truc tourne et il est extrêmement propre, je peux te montrer. Et en plus le pire c'est que ça peut tourner très vite. Tu es en train de démontrer ce que je pense depuis le début. Personne.

Faire une mise à jour, personne s'occupe du monitoring. Quand je te parle d'avoir des gens en carton, c'est parce que ça veut dire que c'est les gens, c'est pas leur boulot au quotidien, ils font tourner les machins et par contre ils ont la responsabilité du fait que ça. Ce qui veut dire que la mise à jour est possible quand il y a plus personne. Et ça je le vois très bien.

Des boîtes qui mettent des trucs au cube et qui se disent à partir de maintenant ça va, on fera pas les mises à jour d'image de base, on fera pas les mises à jour de cube, il y aura des mises à jour de que dalle. Mais, mais, mais, mais c'est. Ces gens là faisaient déjà de la merde avec Debian avant et moi à l'heure actuelle. Mon principal problème quand j'amène Cube et c'est justement ce stress, maintenant ils font de la merde avec Cube.

Génial, On continue à tenir mon discours qui est de dire je pense que ce n'est pas une légende, c'est de la merde. Les gens qui faisaient de la merde avant, ils continueront de faire de la merde après, c'est pas grâce à l'outil qu'ils en font plus. Donc je reprends l'exemple de techno, ils en font moins qui enferme les gens, Tu prends, tu prends du SQL, tu mets des contraintes dans toute la base. Je fais un jeu de contraintes propres dans la base, personne est capable de détruire la base.

Je prends le concept de boîte à outil de cube faire juste les mecs, faire juste le redéploiement en cas d'échec, faire juste je sais pas qu'est ce qu'il peut y avoir d'autre, Le scaling et compagnie, Les actions c'est une charge. Ouais ouais, des trucs comme ça. Et faire juste des actions de base, mais de base sur n'importe quel n'importe quel déploiement d'une application à la con, d'un webservice ou peu importe. En admettant à l'époque, à l'époque,

avant que tout ce qu'on a dit, donc en fait n'importe quoi. Ah d'accord. Donc on met entre parenthèses la sécurité aujourd'hui. C'est le cas dans les entrevues, vu que le système est mathématique, on met, on met entre parenthèses la réutilisabilité de la sémantique ISO périmètre déclarative. Et ça, en terme de sécurité, permet déjà de savoir qu'aujourd'hui il y a des innombrables petites actions.

Je termine ma phrase s'il vous plaît. Il y a d'innombrables petites actions qui sont qui sont chipées avec l'outil. Tu vas me dire avec aussi n'importe quel outil, ça pourrait être nomade et peu importe, mais très bien utilisé en nomade. Je ne suis pas contre, mais qui sont shippé avec l'outil qui aurait été faite par des scripts à la con, par des trucs inventés à la maison et par des trucs bien plus dégueulasses que Kubernetes. Je pense qu'en fait j'ai enfin touché du doigt le problème.

Vous êtes traumatisé d'avoir vu des infrastructures, mais lamentable face au mauvais sens du management et des infrastructures sans amour. Je vous invite à venir voir ce qu'on fait. Parce qu'en fait l'histoire c'est que moi, quand je juge une technologie, je ne dis pas ça a tellement été nul à chier ce qu'on a fait jusqu'à présent, que gagner, ça m'intéresse. Moi, ce que j'ai envie, c'est de

faire des technologies qui gagnent. J'ai envie de faire autre ethnologie qui règle définitivement des problèmes. Vous savez combien Adobe chez moi ne fait pas 40 pour gérer l'ensemble de Clevercloud? Oui, ça me paraît pas déconnant. Gérer 8000 machines, il n'y en a pas. Il y en a parce qu'ils n'ont pas le titre, vous savez. Non, non, personne n'a comme boulot de se connecter à une machine. Une connexion SSH en Admin, chez

nous c'est une alerte de monitoring. Lol non je te disais tout à l'heure le zéro ssh c'est une philosophie, mais moi moi le talos, c'est le système dont je t'ai dit tout à l'heure c'est un système, il n'y a même pas de shell dessus. Genre le système c'est un init qui boot un process en API et une fois que tu lui as communiqué, il se coupe Talos. C'est Il y a même pas de Shell et même pas dans tout l'os, y a même pas de shell pour s'y connecter. Se connecter sur une machine, c'est une hérésie.

J'ai toujours dit et j'ai toujours dit dans toutes les boites on est passé tant mieux que vous y seriez arrivé. Mais bon, c'est pas ça la définition d'un os. La définition d'un OS, clairement, c'est pas le gars qui se connecte en SSH, même pas le gars qui est d'astreinte. Ça c'est le techos d'astreinte. Là dedans, nous on l'appelait, je sais même plus comment on l'appelait. Mais ouais, mais l'OP c'est celui qui a la capacité à comprendre le sous de la base.

Et la brique sous jacente c'est et vous chez vous c'est génial, c'est que vous avez eu des gens qui sont capables de comprendre la prog et qui ont construit un peu ce qu'il y avait au dessus. Ben ça c'est génial pour moi, mais c'est vraiment,

vraiment très bien, C'est là dessus. Et quand aujourd'hui les gens bon, ils sont chez toi, enfin moi dans toutes les bases, mais n'importe qui peut être bon, c'est un problème de travail, mais si tout le monde peut être bon, moi j'ai vu des tonnes de boîtes et moi ma pensée c'est que tout le monde peut être bon. Et je pense qu'aujourd'hui, quand on prend des ops et qu'on leur dit ta mission à partir de maintenant, c'est d'avoir une communication sensée avec les dev sur l'entrepôt de données.

Pourquoi, Dans quel sens faire de l'archi avec eux, expliquer comment on achète du matos, calculer les TCO parce qu'on va pas parler des envolées de coûts sur sur les clouds publics et en particulier Amazon faire de la protection de la data parce que je parle même pas de la qualité aujourd'hui de la protection de la data européenne vis à vis des Etats-Unis. Enfin tu vois, on a un certain nombre de problèmes et aujourd'hui on leur dit pas ça, on leur dit Bah va

faire joujou avec ce nouveau toy, ça s'appelle Kubernetes, tu vas réapprendre le monde et en fait rien ne va changer. C'est à dire, au lieu de faire apt get install, les maîtres font kubectl quelque chose. Ok, cool. Mais alors, alors, Alors on ne va pas régler le problème. Alors détrompe toi. Alors moi c'est par exemple quand je fais des formations Kubernetes, quand je fais des formations Kubernetes, j'ai trois tracks, j'ai une première track, une première et une deuxième

track dev et une track SRV. Et alors la distinction entre les trois, elle est claire et je pense qu'elle répondra à ton besoin. Celle que je déteste c'est la track op et en fait je l'ai appelée OP parce que ça c'est les gens qui vont maintenir le cluster.

Et c'est ça d'ailleurs qu'on me demande le plus, c'est celle c'est comment j'installe mon cluster moi les gars, ils sont en train de se palucher, de savoir est ce que je vais utiliser Ansible, Terraform machin etc. Parce que je leur dis à chaque fois c'est installer le cluster, c'est 1 % du temps, le plus important c'est le run, c'est qu'est ce que vous allez mettre dedans? Mais je le fais quand même, les gens le demandent. La frag dev c'est comment? Je déploie comment?

Enfin pas comment je déploie, c'est comment je travaille et q26 comment j'arrive à débugger et comment j'arrive à aller chercher des logs, comment j'arrive à avoir du monitoring. La plupart du temps, les gens ne savent même pas ce que c'est. Donc là je demande ça, mais avec la plus importante que je fais le moins. Mais la track la plus importante c'est la tracasserie.

C'est de dire tout ce que tu viens de dire c'est comment je maintiens, mais comment je maintiens mes applications, comment je le monitor bien, comment je fais mes upgrades, comment je, comment je j'audite ma sécurité, comment je fais ça? Ça pourrait être la personne qui fournit des dashboards de reporting de l'activité qualitatif et qui aurait une discussion positive avec les devs sur le fait d'implémenter des métriques à la fois techniques et métiers dans

l'appli qui cracherait des métriques. Les crashs en Prometheus, se crasher en stase, en JMX, je m'en fout, nous on fournit tous les modèles. Mais tu vois par exemple aujourd'hui grapher un utilisateur c'est connecté, mais juste ça. Tu vois cette action de login, Il y a combien de boîtes dans lesquelles c'est fait? Zéro Parce qu'au lieu de ça, les mecs sont partis faire joujou. Alors à qui fera du cube, à qui fera du nomade, à qui faire du machin?

Et moi, ce que j'offre aux gens comme techno, c'est à un moment où ils ont plus besoin de faire ça. C'est à dire que ta track de comment on gère le cluster, c'est pas un problème, laisse les robots le gérer. Pourquoi ça ne marche pas comme cube?

Parce que ça n'a rien à voir. Nous on fait de l'AA, c'est le bordel, c'est ça qui est. C'est ça qui est bien, c'est que à l'heure actuelle et d'ailleurs c'est le talk de Leslie Tower à la dernière keynote de la Kubecon San Diego, Il va dans ton sens, il dit et moi ce que j'arrête pas de dire, arrêtez de vouloir proposer Kubernetes par défaut aux utilisateurs Kubernetes, c'est un builder d'infrastructure. C'est que moi, si jamais demain je voulais te concurrencer,

j'utiliserai en brique sous jacente. Mais aucune sécu, aucune perf, mais aucune rien. C'est juste des conteneurs, mais non, le container ou n'importe quoi comme ça. Et je règle pas tous les problèmes. Non mais si vous voulez faire la même chose, faudrait que tu réécris. C'est ce que tu as fait, Tu as dû réécrire. Je le réécris en utilisant la sémantique mais juste. Le problème c'est que la sémantique de cube a été pensé uniquement pour un seul déploiement.

Le jour où tu m'amèneras un modèle de runner propre, je te dirais parlons en. Le problème c'est qu'aujourd'hui il n'y a qu'un seul runner dans Cube, c'est de faire du container. Et en fait, la sémantique de cube est orientée uniquement là dessus. Parce que cube c'est une solution pragmatique qui part de

la base et qui a été remonté. Et en fait aujourd'hui, quand je te dis tu manipule des binaires et des numéros de ports, ta beau m'expliquer c'est une modélisation, c'est pas une modélisation, T'as pas modélisé ton problème pour redescendre dessus, Tu me dis moi j'ai besoin de lancer des binaires sur tel port et du coup. C'est ça que je mets dans le manifeste. Et en fait, si tu veux ton problème il est là, c'est que tu me dis ce serait extensible, Fine, fait le, montre moi.

Moi aujourd'hui, j'ai analysé la sémantique du truc dans l'espoir de pouvoir utiliser le machin à la place de me faire chier à en maintenir ce que moi ça m'amuse pas du tout d'en maintenir un. Qu'on soit très clair sur l'opération, ça me casse les couilles parce que ça me coûte de l'argent. J'ai décidé de ne pas m'en servir parce que la sémantique du truc était pétée, parce qu'encore une fois, c'est un modèle empirique qui n'a pas été monté d'après des gens

qui faisaient de la vraie prod. La première version, c'était des gens qui en fait voulaient concurrencer, c'était des dev réels qui écrivaient ça chez Google pour concurrencer les gens de chez Docker. Et petit à petit, ça agrège. Mais il n'y a pas un moment où tu as un comité technique de gens qui se sont mis à penser le truc de façon à ce que ce soit bien pensé dès le début. C'est une accrétion, non?

Dans le tas il y a des trucs bien, je te dis pas le contraire et c'est pour ça qu'on va le proposer à nos utilisateurs. Parce que je pense très sincèrement que le plus d'usage qu'on aura, et ça, ça peut te faire chagrin si tu veux, moi, l'usage qu'on me demande aujourd'hui, le plus, c'est d'utiliser Cube pour pouvoir lancer le Elm qui permet de lancer Open face. Et c'est magnifique.

Alors en fait, ravi, là pour le coup, ils ont perdu si jamais ils font de l'open face. Mais c'est Ah mais non mais d'accord, mais donc les gens ne devraient pas faire d'elm mais les gens ne devraient pas faire de machin et les gens ne font pas ça. Non mais les gens font du open face avec du matos dessus, tu vas voir. Mais bien sûr, mais, mais, mais, mais parce qu'on a une trans, parce qu'on a une transition. Et moi, à l'heure actuelle, quand les gens tu vois, genre des trucs géniaux quoi.

Moi j'écris pour trouver une bonne techno, c'est bien, sauf que c'est quand même hyper opiniated, c'est à dire que Jenkins x Si tu le fais pas tourner sur Gke, ça marche pas. Et si tu fais pas avec du github même pas entreprise, ça marche pas. Donc c'est marrant, il y a de bonnes idées, c'est très amusant mais ça va être bien pour l'instant. Si tu veux, ça correspond quand même au cas de start up dans la vallée. Moi je regarde GitHub, moi je regarde Tekton surtout.

Tekton est très intéressant mais pour l'instant Tekton ça marche pas. Ah mais je suis d'accord, je regarde Tekton, j'ai bien dit je regarde. Ouais non mais si tu veux que tous les projets de la SNCF me font un jour, ce sera génial, On va en profiter, ce sera génial! Alors ok, je fais de l'agrégation dans Prometheus, j'ai huit verres pour le cul pour le cul et pas dans le SNCF.

C'est pas non, c'est dans la. Dans la série Fondation de la série Cl Fondation. Non, non, je crois que c'est Tekton pour le coup, comme ça appartient à Google, ils veulent pas du tout. C'est fact-checking. Non non non non mais tu peux checker Mais en fait je suis sûr de mon coup maintenant. Moi je suis la série Fondation. En fait, Jenkins avec quelques autres ont lancé une fondation, mais c'est quand même beaucoup de Jenkins.

Enfin Cloudbees qui la pousse et c'est une fondation autour du SI, c'est aussi une fondation fille de la Linux Fondation Machin et en même temps non, non. Alors à voir, Mais à mon avis et à mes souvenirs, Tecton appartient encore à Google et ne veut pas la filer, tout comme qu'est Native, Native et Tectum. C'est les deux projets que Google a dit. No way, on vous le filera jamais Et c'était très récent ça pour le coup, mais mes jambes avaient été intégrées.

Parenthèse Prometheus, c'est quoi le le grief contre Prometheus? Parce qu'avant Prometheus c'était quoi? Il y avait Centreon, il y a eu un petit coup de influence mais influe, ça vivote, même si c'est moyennement parce que tu prends toutes les technos de monitoring de merde parce que c'est vrai. Oui, aujourd'hui c'est un énorme pas en avant. Enfin pour moi et je suis d'accord, c'est un énorme pas en avant.

Si tu pars d'un fichier dans lequel tu écrirais tes trucs et tu ferais passer du grep dessus, c'est un énorme pas en avant. Il y a des fois le truc dégueulasse qui faisait des trucs des dashboards, ça te dit? Non, Tu parles de la réimplémentation de c'était pas ça? Mais non Graphite, non, je parle pas de graphite, il y a des trucs comme ça. Oui, il y avait Shinken, mais tout ça c'est au dessus de tout ce qui était Nagios. Mais oui, Non mais attends!

Mais en fait le truc c'est soit tu considères le marché des outils de monitoring et là pour moi, face à ça, les bonnes qualités c'était du juridique, des choses comme ça, tout ce que tu veux, mais très bonne qualité. Soit tu considères le marché du Time Series DB et en fait ce que tu fais c'est de la time série et tu l'analyse. Et en fait oui, ça veut dire que peut être ça vient moins bundle, mais je pense aujourd'hui que ce sont

des solutions qui sont en dessous. Prometheus Les problèmes avec Prometheus sont simples, si tu lui en colle trop dans la tronche, il est pas content, il sait pas agréger parce que le moteur de stockage de Prom il est pété. Ensuite le moteur de stockage de Prom est empty, il n'est pas capable de prendre de la donnée

qui a plus de quatre minutes. Ce qui veut dire que si tu as un incident et que tu es un peu favorisé, ta donnée au moment où tu remets to live et où la donnée arrive sur le serveur Prometheus et tu as envie qu'elle aille sur le serveur Prometheus parce qu'en fait c'est ce qui va te permettre de faire ton forensic. Bah en fait le serveur te dit va te faire foutre donc du coup tu pourras pas le faire de Francis qui pour moi dans un système de

monitoring est assez rédhibitoire. Et après il y a le dernier point qui est plus un problème d'analyse. En promutuel tu as huit. Moi, celui que j'utilise, c'est un truc qui s'appelle Wharton. Il y a 900 verbes et quand j'ai besoin de faire de la mise de tendance, de la window tendentielle beaucoup de machins et où en plus je peux rajouter des notions géographiques parce que etc. J'ai un truc qui tient la route mes premiers. Prometheus répond que la première brique qui est enfin

Prometheus n'a jamais voulu. D'ailleurs tu dis que le modèle de stockage est pété, C'est juste. Il est tel qu'ils ont voulu qu'il soit. Il répond que à un problème, à un problème et un besoin qui est je le co-localisé avec mes applications et après derrière tout ce que tu dis, d'analyse etc, ça doit être fait par quelqu'un d'autre et ils l'ont toujours dit,

ça a toujours été le but derrière. En effet, c'est peut être pas très tu vois, il n'y a pas d'outil scientifique en terme de mais parce que justement ce truc là doit être fait par quelqu'un, extraire les données une fois qu'elles sont dans Prometheus et de plus ça pose un vrai souci, c'est plus lourd comme opérateur.

Une fois on l'a testé, on a joué avec, tu sais faire des choses, Tu vois, moi j'ai jamais compris pourquoi il y avait de l'engouement pour ce truc, bien meilleur que beaucoup d'outils et beaucoup plus pratique à mettre en place. Parce qu'en fait, dans la notion même de technologie et d'amélioration, la misère, nous on est au dessus d'Adobe. Après, je vais être franc avec vous Wharton, aujourd'hui c'est un Java jar.

Tu n'es pas obligé de le lancer au dessus de nous, nous lance au dessus d'Adobe pour X raisons liées à notre charge et Machin a plein de trucs. Mais le problème c'est comment aller chercher la donnée Prometheus. La seule chose qui répond, c'est comment aller chercher la donnée dans son système de label. C'est quand même le truc over super puissant pour aller chercher de manière horrible. C'est juste Prometheus plus Service Discovery, c'est tout ça.

Enfin moi c'est le protocole où tu fais du pull. Je suis toujours pas d'accord parce qu'il est pas fait pour ça, il est fait. Après il y a d'autres outils, il y a deux. Non, non mais non. Le pull, le problème du pull. Il y a un vrai souci sur le pull. Le problème du pull, c'est que tu Tu vas charger. En fait, tu ne laisses pas l'applicatif décider quand est ce qu'il t'envoie de l'info et donc tu vas le charger à des moments probablement incongru.

Et donc au lieu de rentrer dans une gestion saine de ton applicatif qui par exemple peut être lié à ton GC, tu vas là, tu vas le charger des moments qui sont. Le problème du pull, c'est que du coup le mécanisme de pull peut être lui même. La problématique que tu repères dans ton monitoring, c'est là où ton acceptation en Satoshi et moi. Alors c'est quand même des cas aux limites. Je dis pas que c'est des cas impossible, mais de là où ton monitoring c'est des cas que

j'ai rencontré plusieurs fois. Oui mais comme tu as dit, comme tu as dit au début, c'est ton expérience n'est pas l'expérience de tous et à l'heure actuelle Prometheus oui pose des problèmes, mais en gros c'est comme à chaque fois c'est une espèce de loi de Pareto. C'est à dire que si jamais de 80 % du problème, j'ai déjà à un moment, à un moment. Enfin, soyons clairs, tu peux pas budgétiser dans Prometheus, tu ne peux pas lui dire j'ai besoin de points bien réguliers pour me faire un joli,

mais ça c'est clair et net. C'est pas oui, ça n'a pas été conçu. C'est quand même un souci si tu veux, aujourd'hui, quand tu as besoin de faire ça, tu peux pas faire de prédictibilité, tu peux pas, tu peux pas tracer des courbes dans le tu peux pas suivre des cours et c'est pas pour ça qu'ils disent d'utiliser les compteurs et pas les jauges. Enfin typiquement, tu peux pas faire de prédictibilité dans Prometheus. Il y a un deuxième problème et

pour moi le problème. Donc il y a un problème d'accès à la donnée qui n'est pas computer. Et comme tu n'as pas de drain facile de la donnée de Prometheus, ça reste pénible. Et après il y a un problème rédhibitoire pour moi qui est l'histoire de Forensics. Tu ne peux pas imaginer un système de monitoring incapable de prendre les données d'il y a une heure.

Je suis désolé, c'est pas possible parce que ça veut dire que tu n'as pas de forensics, donc ça veut dire que tous tes événements sont incapables d'être compris, même dans la fédération et même dans la fédération. Regarde comment fonctionne Prometheus, mais enfin c'est pareil, regarder pour avoir mis en prod pas mal de fois mais tu peux pas prendre de la vieille donnée, je t'assure, c'est lié à son modèle de stockage. Je te. Je te.

Je te jure que Prometheus Bound se la donner qui a plus de quatre minutes, c'est lié au système de stockage de props si tu le stocke ailleurs. Non mais c'est dans le sens où il prend, il bufferise, ensuite il crée des bugs de temps et ensuite il te les compacts et il te fait des fichiers avec. Il lui envoie de la donnée. Il ne peut plus réécrire dans des fichiers sur lesquels il a déjà flusher. Et donc tu ne peux pas faire de forensic sur une infrastructure monitoré par Prometheus.

Après les gens font ce qu'ils veulent, tu peux me dire oui mais le forensic on s'en bat les couilles et de toute façon les mecs à l'époque ne faisaient pas de forensic dans leur infra donc c'est déjà un mieux.

Ok, il y a pas de problème, mais si en fait c'est vrai que ça va être la réponse qu'on a. Oui mais en fait je vous refais ma réponse encore une fois, on ne va pas défendre toutes les technologies médiocres, mais en fait en disant que les mecs mais c'est pas grave mais c'est médiocre, elles sont pas utilisables. Voilà, c'est ça. Et très sincèrement Warp aujourd'hui tu sais, une technologie que je trouve d'une accessibilité. Oui, il faut prendre deux minutes pour lire la doc.

Oui les mecs ont un problème parce qu'ils sont huit dans la boite et non pas 160. Et donc effectivement parfois il faut aller voir un tout petit peu plus loin. Mais si au lieu de passer son temps à taper de la queue comme un castor, à faire du rabattage sur tous les projets à la mode et qu'on allait s'intéresser deux minutes aux technologies plutôt que de prendre les technos à la mode, ça pose. Un souci. Enfin c'est quand même ouf, je suis pas dans un podcast où vous

boudez, Non mais sérieux! Et hop! Et c'est ainsi que j'apprends que votre système de monitoring ne peut pas faire de forensique. Enfin, vous vous rendez compte du truc? C'est dramatique, Vous faites vos choix sans jamais regarder le code du machin. T'as lu le code de Prüm? Tu t'en sers pour faire ton monitoring, tu lis pas ton code. Enfin, c'est aberrant.

Vous pensez comment? Mais parce que. Parce que en fait, en gros, ça va répondre au besoin qu'on a à un moment donné qui est que celui ci sait que si tu as un, si tu as un problème dans ton infra, tu n'auras aucune idée. Mais non, parce que mon Prometheus, il est co-localisé avec mon infra. Et en gros, si jamais, si jamais le. Si jamais le Prometheus ne marche pas, c'est que mon infra ne marche pas et en gros les deux ne vont pas marcher.

Donc en gros les logs que je vais avoir ne servent à rien à ce moment là. Donc clairement, moi un Prometheus à l'extérieur d'un cluster Kube, c'est une hérésie. Voilà, Donc c'est à dire que ton Prometheus doit être co-localisé avec tes applications, s'il lui arrive quelque chose, il doit lui arriver la même chose. Derrière, tu mets la fédération avec quelque chose d'autre et oui, lui il pourra avoir des problèmes à récupérer et encore non, je ne vois pas.

J'ai l'impression que tu l'aimes et lui ne fera pas de trafic. Mais c'est tu reproche à à la fin, tu reproche à quelque chose qui est, qui est communautaire, qui est déployé. Enfin le comment dire quelque chose qui est de la popularité de quelque chose. Tu lui reproche sa popularité, ça devient au bout d'une certaine popularité, tu dis Mais merde, il y a que ça, il y a du battage et du marketing.

Alors certes, il y a beaucoup de marketing, mais je pense qu'il y a des réelles raisons que le marketing peut apporter. Il y a cinq ans, parler de Kubernetes, c'était c'était une barrière, enfin c'était une barrière. Moi, je me suis fait virer de boîte pour avoir parlé de ça alors que les gars utilisaient des grosses merdes. On a eu l'effet inverse en fait.

C'est à dire que maintenant, en fait, moi j'étais au début anti inverse de mode de rejet qui est lié à il y a trop de popularité, c'est qui on passe à côté de toi, tu passes à côté d'autres choses mais on est dans la totalité là dessus. Les avez vous avez dit? Oui, je te comprends tout à fait et je suis d'accord, mais c'est moins moisi. Si on faisait un monde n'est pas là. Oui non mais d'accord, dans ces cas là, pourquoi vous en parler plutôt que. Enfin, vous vous rendez compte?

Du coup, vous vous retrouvez dans des infra où vous passez un temps fou avec des gens où en fait on pourrait les remplacer par une install du soft et les mecs pour aller faire des trucs utiles. Mais avec qui vous êtes en train de comparer des gens à des grille pain? Mais c'est le cas, non? C'est le cas à l'heure actuelle et clairement même pour eux. Pour connaître des gens qui passent d'un passe à Kubernetes, clairement ils gagnent du temps.

C'est le cas à l'heure actuelle. Et ben ouais, on pourrait dire sur quoi ils étaient sur. Ah bah voilà. Et mais, mais, mais. J'ai écrit un article un jour qu'on n'a jamais publié chez Clever, qui est le plus gros problème du pass. Ça a été le demi succès des Roku parce que le plus gros problème du pass, c'est Kroku a fait un tel toy de Fisher Price que pour l'éternité ce sera un toy.

Et c'est pour ça que maintenant nous on dit qu'on fait de la it automation, qu'on dit qu'on qu'on fait de la de la High Augmented DevOps. C'est parce que le terme de plateforme de service a été tué par les seuls gens qu'on fait un peu de sous dessus. Ils en ont même pas fait beaucoup. Ils en ont fait un peu mais. Et oui, c'est un drame.

Pour autant, si tu veux, prenons le nombre de conteneurs, de systèmes de conteneurs et d'opportunités de conteneurs qui merdouillent. C'est pas parce qu'il y a un pass qui a été mauvais. Non mais la question c'est est ce que les mecs étaient sur Heroku mais vient tester du clever à la place? Tu vas voir, c'est du one drop, t'en entendra plus jamais. Mais non, parce qu'en fait, en fait, ils ont besoin de tester. En fait non mais. Mais en fait le truc c'est que par exemple, t'as déjà testé?

Je vais tester mais le clevercloud le problème, moi je trouve ça vraiment génial. Moi je suis pour l'hétérogénéité des solutions, c'est à dire en fait à un problème son sa solution. Des gens qui me disent j'ai besoin de faire tourner que une application que j'ai codé moi même, que je sais comment elle marche etc et que j'ai pas envie de me faire chier avec les briques sous jacentes. Je vais sur Clever et je sais que mon truc restera toujours accessible dans

le cloud etc. De par les internet. Très bien moi avoir une première oui mais moi mon email dans un avion je vais pas mettre clevercloud dans un avion. En fait c'est quoi en fait mon prérequis pour le faire là? Moi je te parle, c'est quatre machines ARM, quatre machines ARM de aucune raison que tes machines ARM marchent par chez nous. On a une version où on a fait du. On n'a jamais lancé d'offres commerciales parce qu'aucun client

n'a jamais eu envie de faire tourner du ARM. Est ce que tu as une offre? Comment on appelle ça Edge? Non, pour l'instant, chez nous, ça dure, ça dure. C'est à dire? J'ai pas une connexion qui est fiable. Exactement. En fait, ce qu'on est, ce qu'on est en train de pondre sur cette solution là, c'est une solution qu'on base aussi sur notre fonction de service,

donc notre fonction de service. On boot une machine virtuelle pour chacune de tes de tes exécutions de fonction pour te permettre une isolation pure à la WS. C'est des lambdas à la WS, il te boot ton temps de lambda parce que Firecracker met 135 millisecondes à peu près à booter ton appli. Et après tu as le problème de ton appli parce qu'en fait ils sont restés dans un système oui Non mais nous c'est autre chose. Et en fait nous on a un unique

kernel. Enfin c'est compliqué. Enfin, j'ai donné un talk là dessus au Blanc de Lyon si vous avez envie de voir. Et puis on pourra revenir pour que je vous explique ce qu'on a fait là dessus. Mais on se construit là dessus. On se construit sur un système de bufférisation qui a été construit

justement pour des cas de edge. Le produit aujourd'hui n'est pas prêt, mais il est construit justement pour des gens qui font de l'IoT avec au cœur un système de réacteur d'Io capable de faire de l'auto compute, enfin toutes les technologies que tu as faites, etc.

Enfin, elles sont vraiment géniales. Enfin, je te veux, je te linkerais des articles que j'ai fait justement là dessus pour expliquer une kernel à des gens qui savent pas ce que c'est à des et de dire vous devriez en faire etc. Vous devriez en faire plus. Moi je dis pas aux gens qui devraient en faire, Je pense que c'est une assez mauvaise idée les trois quarts du temps. Oui, les trois quarts du temps, mais c'est extrêmement amusant à faire.

Mais, mais, mais même juste de savoir, même juste que ça existe en fait. Déjà, ce serait bien. En fait, j'ai même un article pour te dire Kubernetes, ce n'est pas ce que vous pensez et la première chose que je dis, c'est que je réhabilite la virtualisation et j'ai tout un article entier qui réhabilite là dessus en disant arrêtez de penser que c'est lent, arrêtez de penser que c'est de l'overhead. Arrêtez de penser rapide. Oui, bien sûr, mais je le dis et voilà. Et je le dis là dessus pour

plein de raisons. Moi KSM Alors il y a plein de problèmes KSM mais j'aime bien KSM. Je trouve l'idée de KSM génialissime. Alors KSM c'est kernel, same, same memory ou un truc comme ça. Enfin bref, ça vous permet de booter sur une même machine. Plus de VM que plus de VM avec plus de mémoire que la capacité totale. La mémoire est balooning dans le kernel on va dire aussi ça même nous on l'utilise pas. Il y a même en plus le

ballooning c'est encore en plus. Mais la seule chose que le fait du copy on write sur la RAM mais c'est ça, c'est KSM qui le fait ça. Ouais, nous on le fait pas que ça, que ça m'a un peu pété en perf. Mais oui mais on le fait au niveau de l'hyperviseur. Mais vous avez, vous avez, vous avez des solutions. Donc en fait c'est. Tu as fait dans ta boite un peu ce que j'aurais rêvé faire il y a de ça cinq ans on va dire là dedans ou je ne sais pas,

et c'est vraiment très bien. C'est vraiment une chose où vous avez pris les problèmes de manière ingénierie, vous les avez fait avec les technologies disponibles à ce moment là et vous les avez fait bien, et vous avez répondu deux choses. La preuve votre solution, elle tourne. Voilà, c'est ça. Moi, ma question c'est encore et toujours maintenant quelqu'un qui aujourd'hui 2020 se pose les mêmes questions là, avec un avec zéro, avec rien.

C'est à dire il n'a pas déjà codé son kernel, il n'a pas déjà sa distribution, il n'a pas déjà tout ça. Quels sont les choix qu'il peut prendre? Et bien en fait c'est là et moi c'est là où j'interviens. Et c'est là en fait que tout le monde arrive. Quelles sont les solutions qu'ils peuvent prendre? Kubernetes peut être pas parfait, mais en tout cas, ça répond instantanément à une tonne des problèmes qu'ils ont et ça leur permet d'aller vite. J'ai modulo modulo aller chez

toi en plus. Bah c'est simple mais je suis d'accord, en fait c'est un peu à un moment si tu veux, mais ta solution elle peut pas, Je peux pas tout mettre dans ta poche. Moi je suis pas sur le cloud, je fais comment? Mais par exemple on a une solution. Mais au delà, au delà de parler de ce que nous on fait, c'est. Vous vous rendez compte qu'en passant notre temps à parler de ça, on assassine tous les autres projets.

C'est à dire que tous les autres projets aujourd'hui intéressants, ils ont du mal à vivre parce que comme on répète en boucle des trucs et tu vois, il y a des technologies, tu parles enfin comme quoi par exemple en fait c'est comme quelle technologie la sur attention et la sur, c'est ça qui tu regrettes au final?

Et bien sûr parce que la plupart des gens qui en parlent ne l'ont jamais lancé parce que tu vois, on leur dit en permanence la le go to go, ce serait ça. Et tu vois, on a une discussion là, je t'ai donné tous mes points sur le pass et tu me dis effectivement, pour faire un pass, peut être pas ce qu'il faudrait,

mais alors il faudrait recoder. Et alors je parle par exemple par rapport à Cloud Foundry parce que beaucoup de Cloud Foundry, je préfère Cube mais 1000 fois cube oui Non mais enfin Oui mais c'est ça en fait c'est si si si, Mais en fait, à l'heure actuelle, il n'y a pas de technologie qui à l'heure actuelle est un tant soit peu concurrente. Moi je pense qu'il faut regarder d'où partent les gens, d'où partent les IT, d'où partent les infrastructures et elles partent de mais d'un niveau,

mais au ras des pâquerettes. C'est pour ça qu'on nourrit. C'est ça qu'on vend Un petit backup MySQL avec des sink. Et encore une fois, la solution du cloud n'est pas systématiquement pertinente, loin de là. Donc des fois, ce qu'on fait, on pense que le TCO global, il est meilleur ailleurs. Et par ailleurs, si tu veux, quand tu regardes, j'essaye d'expliquer pourquoi il y a cet engouement, pourquoi il y a cette auto auto

marketing et l'engouement. Mais en fait, l'engouement, il est quand même essentiellement lié au budget marketing qui ont été dépensés dedans et le fait que du coup, dans l'infrastructure, c'est un peu cynique, un peu le oui complet, mais non, non, non, non. Le budget technique, il a été mis à partir du moment où ça a commencé à marcher et vraiment pour l'avoir vécu il y a cinq ans, mais alors vraiment pour l'avoir vécu, on était dedans aussi, vraiment.

Le budget marketing était à zéro et nous on galérait mais genre pour tout. Mais en même temps, toi tu l'as vécu dans ta boite ici en France? Non? Non mais toi il y a cinq ans tu l'as vécu dans ta boite ici en France, C'est pas ici que s'est joué le match. Le match. Il s'est joué dans quatre pâtés maison à San Francisco et je te jure que là, le budget marketing, il a été mis. Il n'y a pas de discussion sur le sujet et le budget marketing qui a été mis sur Cube. Il est délirant.

Et aujourd'hui, soyons très clairs sur Cube Cube, c'est la seule chose qui permet à Google de continuer à dire qu'ils ont un pied dans le cloud. Parce que la réalité du cloud aujourd'hui, c'est 47 points Amazon. On pourra finir sur le nom parce qu'il y a encore c'est 47 %, Amazon, 25 %, Azure 3 % à Google et aujourd'hui ça s'appellerait pas Google, on en parlerait pas. Mais je suis entièrement d'accord avec toi. C'est même d'ailleurs l'annonce qui était plus ou moins là.

On ferait quoi auprès du soir, auprès du nomade? Enfin, il y aurait d'autres choses, ou alors aucun de ces trucs là, et on aurait eu des gens qui auraient créé des solutions intéressantes. Mais non, justement, la solution intéressante, c'est quand même l'idée d'avoir un truc qui est commun à tout un corps de métier. C'est intéressant, ça a de la valeur, ça a de la valeur pour un standard, c'est un paquet de scripts, non? Standard, ça l'est de facto.

Je dis pas que c'est énorme, c'est pour l'instant le seul standard que je ressens dans le cube, c'est Elm, alors je suis pas sûr que ce soit une bonne nouvelle. C'est celui qui est le plus basher vraiment la communauté dans la communauté? Non? Celui que je vois utilisé par des gens à l'extérieur. Le plus c'est des gens qui me disent c'est génial, on va lancer du script. Non mais elle aime ce qu'elle fait à la fin, c'est qui génère des manifestes. Moi ce que je peux faire c'est

que à la fin, à la fin. Mais même il peut faire la merde qu'il veut, il ne peut pas écrire sur sur un node un cluster. Ce qu'il fait c'est qu'il génère du Yémen que je vois là. Je fais quelque chose avec ce YAML là. C'est un générateur, c'est un générateur de YAML avec tous les problèmes qu'il a derrière. Mais alors vraiment?

Mais, mais, mais enfin il a changé! Non, non non, J'ai toujours des gamelles mais il était toujours avec un template et ça a commencé par des zips, dans des YAML, dans des if. Non, ça c'est encore les générations, les générations, la fin du fin du fin, ça fait des YAML. Et c'est parce que tout le monde est un peu obligé, forcément. Quand on fait. Le relais, il y a plein d'opérateurs. Enfin si, après si, après tu l'installes, c'est tout.

Mais je ne manipule pas les tar.gz, je. Fais des gestions de dépendances. Du coup tu maintiens, tu fais des gestions de dépendances. Moi en fait, si tu veux, encore une fois, je ne vous dis pas le contraire, Je vous dis je pense que cette techno est floue à la base. Donc voilà, vous me dites non, il y a des trucs intéressants, c'est moins moisi que ce qu'on faisait avant. Ok, j'admets, c'est moins moisi que vous faisiez avant, je n'étais pas avec vous peut être.

Je pense que c'est pas le futur, mais ça l'est pas. Oui mais le problème c'est qu'à force de nous casser les couilles avec ce truc là, on est obligé de l'intégrer. Tu crois quoi? Comment Moi je l'intègre dans mon. Enfin tu vois, genre on est 17 h. Voilà, au moment où je mets deux gus à intégrer ce machin là, très concrètement, le projet est passé à la trappe. C'est le projet de description sémantique de service. Ça, c'est la réalité. Les gens intelligents, tu crois quoi?

Que les gens qui ont fait des opérateurs élastiques, ce n'était pas des gens brillants? Ces élastiques ont des partenaires élastiques. On va bientôt lancer l'offre. Gardez ça pour vous. Entre gens qui écoutent le podcast, on on est partenaires, on discute avec ces gens là. Les gens qui font ça sont des gens brillantissimes qui auraient pu

faire à la place des choses utiles. Et en fait, aujourd'hui, on a tous tous les éditeurs, on a une taxe Kubernetes qui est réussir à faire tourner plus ou moins notre merdier dans ce bordel. Alors c'est oui, ça aurait pu, oui, on aurait pu trouver un truc mieux, on aurait pu aussi trouver un truc pire.

Et vu comment effectuer un test. Et surtout quand tu as cité l'exemple D'openstack, c'est qu'en vrai des bonnes technologies qui sont bien sorties etc. Des gens qui pensaient que leur technologie était bonne et qu'en fait elle était toute moisie et qu'elle ne marchait pas, Il y en avait plus que ce que l'on peut imaginer. Et j'en suis passé par plein des gens qui ont essayé de réinventer la roue

comme ça. Tu vois, c'est le cas. J'adore cette technologie là, mais tout le monde en a fait de la merde et c'est pas un problème de chef, c'est un problème de plein d'autres choses, même de chef. C'est du scripting. Le scripting c'est du binaire, le binaire c'est la mort. En fait toujours la même chose, on prend le truc au sexe fournisseur, je reviens au métal,

on va chez OVH, on va chez OVH. N'importe quel mec qui fournit du métal, il y a une interface web, OK, on va la planifier chacun, il va se dire OK, moi je vais fournir une espèce de Schindler de machine physique et on va avoir X provider X API. On fait la même chose avec les VM, on va avoir plein de mecs qui fournissent des VM avec chacun, qui fournissent son skylink machin. Il y a un intérêt à avoir quelque chose de commun, que ça soit OpenStack, que ça soit, mais ça fait pas des films.

Non, non, non, On arrive avec le concept là tu Kubernetes, je suis sur Kubernetes en disant il a créé aussi, il a créé des choses, mais absolument génialissime. Si jamais demain on rase Kubernetes, on gardera les autres. C'est à dire que quand Kubernetes on s'en débarrassera, enfin, on aura le legacy de ce machin. Non, c'est pas du legacy. Je termine juste. C'est.

Tu es en train de regretter le fait qu'on te force à mettre Kubernetes, mais s'il n'y était pas, tu devrais valider un truc fait maison. Imaginons un fait maison ou autre qui serait complètement différent des autres. Alors un truc open source qui fonctionnerait pour tout le monde parce qu'on aurait pu faire un format, mais on aurait, on aurait réussi en fait. Mais en fait on ne l'a pas réussi parce qu'on était embêté. C'est là où on n'est peut être pas fort,

mais on n'est peut être pas d'accord. C'est que c'est arrivé déjà très très tard par rapport à ce qu'il aurait du.

Il est arrivé déjà quinze ans après. Quelque part, c'est une mise en commun. Alors certes, c'est pas une mise en commun, c'est une mise en commun, mais en quoi c'est une mise en commun? Aujourd'hui, j'ai pas le droit d'aller contribuer dans Cube a fait autre chose. Enfin tu vois. Non mais non. Mais il a le droit d'aller contribuer dans Cube aujourd'hui. Mais qui a le droit de contribuer dans Nomad? Qui est OpenStack? Qui a le droit?

Je suis pas en train de défendre Nomad, j'ai jamais dit que Nomad c'était bien et j'ai jamais dit que c'était bien. Je te rappelle que je suis rentré dans mon bureau un jour et j'ai dit à mon équipe bon, ce machin là, dans un mois et demi, on l'a dégagé. Enfin ok, c'est pénible. Ok c'est pas cool, mais. Mais en fait tu as pas l'impression que ça sent la même chose?

Je veux dire, ça sent tellement la même chose que je me souviendrai toujours la première Dotscale, la première Dotscale la conv d'ouverture c'était moi et j'ai fait toute la journée. Après l'avant dernière conf, c'était Solomon X qui pendant 30 minutes nous a parlé de l'industrie de la logistique alors qu'il y connait que dalle en racontant des conneries et pendant dix minutes nous a dit j'ai fait la même chose et vous allez voir c'est des mini VM.

Et là il a enchaîné une série de demi mensonges technologique.

Je lui en veux pas, il vendait sa boutique, il fallait qu'il sauve sa boite qui était docteur à l'époque et qui n'avait pas fonctionné comme pass et du coup il faisait ça et à sa sortie je lui ai dit je vais implémenter ton truc sur mon machin, on s'entendra et c'est pour ça qu'on était le premier cloud à sortir et le talk suivant, c'était le mec de la D'openstack qui nous a décrit que le projet OpenStack ça allait être génial parce que c'était cool.

Driven Community, non, Il faut quand même le dire sans trembler des genoux. J'aime bien le foutage de gueule absolu de ce machin là. Et t'avais toute la pièce qui applaudissait en disant que c'était génial et moi qui était consterné en me disant mais les gars, ce truc est une énorme daube. Et tu tu parlais à n'importe qui qui était dans la pièce, tu disais ce truc est une catastrophe, Ils disaient mais non, c'est le futur, tu t'en es déjà servi, non? Et aujourd'hui, Cube,

c'est la même chose. Qui pense que Cube est le futur qui s'en est déjà servi. Attends encore quelques mois debout Et là, tu fais un sur mini cube. Mais on prend pas de risque à dire

qu'un truc va se casser la gueule. Et là et là c'est vraiment un problème, c'est qu'à l'heure actuelle, personne ne dit qu'ils sont sur Cube parce que tout le monde se dit putain ça fait cinq ans que ça existe, je vais pas dire j'y suis, sinon je vais passer pour un boloss avec ça. Ah oui, 500 en 2007 et 2014 c'était juillet 2014 et leur première release. J'ai checké c'est novembre 2014 et qui sont tagué bêta mais c'est pas grave, ça vient par dessus les applis bêta, mais il y en aura toujours.

En fait, à chaque fois il y en aura et c'est pas pour rien. C'est que mes parents, que le pod, le pod, il a jamais été bêta. Le pod. l'Unité de base n'a jamais été le Réplika. C'est que tu prends un binaire lance le il est replicaset n'a jamais été beta. Ouais enfin on s'en sert, mais si le déployer il utilise le réplika set. Mais oui, parce qu'en fait c'est

basé sur des bases saines. C'est la même chose que quand on avait le GCP qui nous expliquait Mais non mais vous ne faites plus d'essais pour moi, je fais des JSP et t'es là genre mais les Kara et résultat des courses on en parle de l'état de géo au sein de l'état de Java Enterprise Edition? Vous voulez vraiment qu'on ait

cette discussion? Parce que ça n'avait pas cette vocation, mais ça avait complétement cette vocation, ça avait pas cette vocation là de gérer l'infrastructure, ça avait une application, ça gère son contexte, mais bien sûr, ça gérait les Enterprise Pattern de la vision SOA, mais franchement, ça allait beaucoup plus loin que être capable de faire un run sur un binaire.

C'était Java Enterprise Edition. Et donc si vous voulez, à un moment, quand je vous dis on n'apprend pas des erreurs du passé, pour moi on est dans les mêmes contextes et quand on me dit mais si c'est un standard, tu peux le ré implémenter et là bas il y a déjà des implémentations. Non, Il y a quand même, il y en a d'à peu près tous les composants à l'heure actuelle, sauf l'API Server. Je connais des implémentations d'à peu près tout, d'à peu près tout, des vrais NPM.

Genre c'est une emblème ou c'est plus ou moins parce que virtuelle complète, c'est une applet? Non, non, mais il manque la moitié de l'API. Enfin, c'est comme si tu dis non, ça dépend, ça dépend du backend derrière, genre en fonction du backend derrière, il peut manquer des choses parce que les casts à l'heure actuelle sont merdiques et moi j'adore. Moi par exemple je suis pour que non mais moi mon truc c'est que

j'en ai ras le cul. Je me suis battu pendant cinq ans pour dire aux gens arrêtez de dire master sur cube, c'est un control plane avec moi, même en technologiquement je suis dans la même chose que toi, c'est que moi ça fait trois ans que je dis Kubernetes, c'est un control plane, il faut le bouter comme un control et arrêter de penser tout un cluster avec des master et des slaves, enfin avec des master et des workers.

Et je dis c'est pour ça que je disais mettez Kubernetes dans des dans des Kubernetes parce que il va savoir gérer ou dans des nomades ou dans je sais pas quoi d'ailleurs j'avais commencé à coder mais tu sais que c'est ce qu'a fait. Oui c'est trop bon, mais deux ans après que je leur ai dit absolument pas. Ah bah c'est non. Pour le coup, j'allais voir les équipes et j'allais voir les équipes à la Kubecon. Je suis allé voir les équipes à l'école, je leur ai dit Mais regardez,

j'ai ce projet là qui a été fait. Ils ont dit pourquoi t'es pas venu nous voir? Et parce que j'étais allé le voir. Tous les gens que je connaissais d'OVH, qui étaient des gens marketeux et qui sont jamais allés le dire aux gens techniques, Mais les gens techniques qui ont fait Cube, je les connais bien, Ils ont pris le projet assez tardivement, avant son delivery. C'est des gens qui ont fait un très bon boulot après, mais globalement c'est du cube. Enfin c'est du cube en cube avec

tous les problèmes que ça a généré. Et franchement, je pense que t'as pas idée des problèmes que ça a généré, mais vraiment un nombre de conséquences encore une fois à exécuter des process de gens. Enfin des process qui ne devraient pas être sur les mêmes OS que dans le cube, un truc ultra important. Si jamais ils ont mis les runner dans Kubernetes, je te promets que c'est des photos de famille, les runner et le control play. Le control playing pour le coup

il est complètement isolé. Tu peux le mettre dans un cube ou dans n'importe quoi et c'est un peu plus délicat que ça. Je vais pas raconter à leur place et en plus je sais pas si j'ai le droit de le dire, mais c'est plus délicat de ça parce que il y a SAP qui le fait aussi depuis bien plus longtemps avec Gartner et je pense que les mecs ont rencontré d'autres problèmes qui sont résolus autrement. Je te dis je te dis c'est pas plus. Non mais peut être, mais je te dis

que c'est plus que ça en a l'air. Mais non mais on peut pas, c'est tout ça, c'est des choses qui se règlent et vraiment. Et oui oui il y a des problèmes, mais comme on ne va pas le faire comme ça, bah c'est dommage, mais c'est un orchestrateur qui marche très bien. Alors Oui, mais alors alors alors? Mais non mais c'est dit avec Nomad ou quoi que ce soit, mais le control playing, encore une fois, ni l'un, ni l'autre, ni l'un, ni l'autre. Pourquoi?

Parce qu'aujourd'hui, et c'est probablement là où vous ne comprenez pas pour moi le problème du scaling et de l'orchestration aujourd'hui. Est ce que je reproche le plus à cette techno là? C'est qu'elle pense que tu peux faire de l'orchestration sans connaître le contexte. Or, ce qui fait que nous ça marche, c'est qu'on fait de l'orchestration qui comprend le contexte. Oui, mais ils le disent, c'est vraiment tous les gens qui vendent des orchestrateur closed source sur cube, c'est skinny.

Parce que le scheduler c'est le projet le plus bâtard de tout Kubernetes, c'est le truc où il y a le moins d'investissements parce que tout le monde sait que c'est compliqué et qu'on laisse la communauté curatrice et le projet le plus. Comment dire? Donc en fait, il faut réécrire ce truc là aussi. Mais tu te rends compte? Mais c'est pas se plaindre, c'est pas réécrire. C'est qu'en fait, en gros, ce que dit Kubernetes, c'est on ne veut pas devenir OpenStack, on ne veut

pas faire des choix à votre place. Nous on a une implémentation qui marche pour l'instant, qui est hyper simple parce qu'on ne veut pas, mais un peu à la GOT, un peu à des choses comme ça. Pareil pour le pour les paquets Django et tout, c'est genre Google disait nous on sait pas faire du packaging, on sait pas faire du versionning parce qu'on a notre mono repo donc on fera pas sortir. Faites le vous même et une fois que ça marchera, on essaiera peut

être de l'intégrer dans le groupe. Et c'est ce qui s'est passé. Kubernetes, c'est exactement la façon dont on succès. Bah ouais c'est super engueulé, ça a été le fumier. Aujourd'hui c'est la pénibilité absolue de faire du go à cause de systemd. Si je puis me permettre, il n'a pas du tout dit ça. Moi non, parce que j'étais quand ils ont lancé Go, j'étais là, les mecs ont dit non. Le système de gestion des dépenses, on a résolu le problème, non? Alors là, j'étais là. Genre vous avez fait quoi?

On n'en a pas? Non. Ah oui, si, si, je t'assure que c'était ça que les gars et que les gars. Mais toutes les toutes les issues que j'ai pu voir là dessus. Parce que pour le coup, ça a été un débat, alors. Ah non mais attends, ils ont changé leur fusil d'épaule il y a un an Et des bananes? Non, non. Tout comme sur les. Non, non, c'est du glide. C'était quoi? C'était en 2015. Au début, ils nous expliquaient que ça servait à rien. C'était bien. Non, Ils disaient. Ils disaient on ne sait pas faire.

Genre, vraiment, quand tout le monde leur proposait des trucs, ils disaient nous on sait pas faire. Et vraiment, mais. Mais Kubernetes, c'est pareil, c'est le projet le plus, comment dire? Rétrograde, rétrograde, rétrograde. Mais genre camper sur ses acquis, c'est qu'à l'heure actuelle, incluant une fonctionnalité incubatrice, ils ne veulent pas, ils disent maintenant on a fait un système extensif, faites le ailleurs. Si un jour la communauté arrive à converger dans une solution, on l'intégrera.

Mais pour l'instant c'est pour ça que c'est dur de coder dans Kubernetes, c'est qu'ils ont les codes, c'est un fait, mais c'est politiquement non. C'est que. Mais oui, mais c'est extensible à l'infini. Imagine, imagine ce qui se passe, C'est Linux. Mais non, mais Linux ne se passe pas du tout comme ça. Je suis désolé, Linux, ça marche très bien comme projet, mais c'est le débarquer et

contribuer à rien de parler. Il faut que tu connaisses, il faut que tu arrives à envoyer l'e mail au bon mainteneur du bon sous système, etc. Dans la bonne mégaliste ça va, il y a une doc, il suffit de la lire. Enfin il y a un moment faut se prendre par la main, c'est pas accessible au tout venant non plus. Mais si tu veux, il y a un cas où la méthodologie demande apprentissage. Dans l'autre cas, on ne va pas prendre ton commit

à cause de ta tronche. Je suis désolé, dans un cas c'est de la politique, dans un autre cas ça démontre ton approche. Tu vois effectivement les patchs par mail, c'est un sujet dont on pourra vaguement discuter si on veut. Bah écoute, franchement, je suis pas un grand fan du patch par mail, mais si ça marche, c'est comme ça

que ça marche. Non mais si tu veux. En fait c'est juste qu'à l'heure actuelle, tu ne veux pas devenir OpenStack et c'est d'ailleurs pour le coup c'est vraiment un truc OpenStack, c'est qu'on intègre rien, on retire du code ou on en fait pas plus. C'est vraiment ça. Alors est une Kubernetes qui n'intègre plus de nouvelles fonctionnalités. Ce qu'ils font, c'est qu'ils rentrent. Ils rendent non bêta les tags qui étaient bêta sans rien changer. Mais il n'y a pas d'évolution

politique. Mais non, regarde, regarde comme moi je vois le bordel. Tu as un truc qui est tenu par une boîte? C'est son seul lien sur un marché dans lequel ils ont dit qu'en 2023, s'ils faisaient pas réellement de l'argent, ils disparaissaient. Donc c'est quand même un vrai

souci ce machin. Tout le monde en parle, c'est hype, Il y a la moitié moins de la moitié des contributeurs, moins de la moitié des toutes les places dans le cycle, c'est pas la question, c'est eux qui sont dans la dans dans la tête de tout le monde déteste tout le monde pensait Google. Tu as toute la SNCF autour et dans la SNCF, c'est essentiellement des startups qui ont été créées, qui sont financées par des VCS. Dont l'objectif est qu'un jour

ça rapporte du cash. Et ces gens là se battent pour prendre chaque segment de management de ton infra sur des projets open source avec des versions entreprises ou whatever. Et tous ces gens là s'engueulent dans l'objectif qu'un jour le tas de pognon que ça générera, ils arrivent à se le partager. Et donc tu passes essentiellement du temps à faire de la politique, bien sûr, mais comme dans toute entreprise, comme dans tout projet humain, moi je suis désolé, c'est pas mon kiff.

En tant que développeur, en tant que développeur open source. Non mais la politique avec Linus Linus, elle est énorme aussi et c'est très bien que le personnage est un personnage hautement politique. Rien, rien. Rien que le ZFS, juste là à l'heure actuelle. Tout le truc sur ZFS comme quoi Linus

n'intégrera jamais les projets DFS. Tant que t'as pas le manager de VMware d'Oracle qui crie sa couille sa couille dans dans un timbre quoi c'est des fesses est un problème largement plus élevé que juste Linus s'il ZFS n'a pas été intégré au démarrage. C'est quand même que ZFS Linux c'était de la daube à la base ça

ne marchait pas. ZFS est génial dans Solaris, ça a mis du temps à être propre dans Linux. Aujourd'hui, ça ne sera pas ajouté facilement parce que sinon ça va finir comme d'habitude par une grande annonce et un truc pas propre. Que ce soit intégré, propre, il faut du temps. Moi j'ai entendu beaucoup parler de politique dans Linux. On a quand même beaucoup moins

que dans d'autres projets. Node est un projet où la politique. Enfin, entre les fork et réunion, fork et réunion, ça a été l'enfer. On l'a vécu en tant que main OpenStack, la misère absolue en politique. J'étais obligé d'envoyer mes commits aux gens de chez Canonical pour qu'ils les resignent et que ça passe. Et pendant ce temps là, on avait les gens qui disaient

c'est ce qui tourne en prod. C'est bizarre parce que moi, le code source qui me permet de savoir si il y a assez de RAM ou pas sur la machine pour booter une machine virtuelle. Je l'ai écrit il y a trois jours donc tu pourras me faire croire tout ce que tu veux. Soit tu me dis que Rackspace ne check pas s'il y a assez de RAM ou pas pour booter une machine. Soit c'est peut être pas ce qui tourne en prod en fait, ce serait peut être un peu du foutage de gueule, tu vois,

c'est quand même la réalité. D'openstack tu vois au moment où on en parle. Et pour moi Cube c'est la même, on me dit c'est cube, c'est cube, mais ça c'est Gecko. Ah oui mais geek c'est que c'est cube. Sauf que les diff. Si tu veux, quand tu envoies des machins et que tu les reçois, les les. Enfin si tu fais les mêmes choses entre du vanilla et du machin, t'as pas les mêmes payload. Moi je veux bien que ce soit la même chose, mais à priori c'est pas le

même code. Non mais c'est mignon. Je parlais des API mais c'est pas le même code et on sait pas. Du coup comme c'est pas la même période. En fait les apps sont slightly différente était exactement dans la même histoire et l'histoire du du comité Java avec des gens qui disent on respecte la pièce X et donc du coup on va mettre en place un TCK, on a le TCK, Kubernetes Certified, Tagada et maintenant pour chaque module on va prendre un TCK. Alors.

Godless, la SNCF, le TCK et gratuit. Le logo ne l'est pas mais le TCK est gratuit. Le logo tu dois payer, tu dois être membre de la SNCF, c'est pire. Il faut être membre Platinium Tagada bidule. Enfin ça te coûte pour te dire, pour te dire je suis. Bernadette a dit, elle a dit tout, tout se répète, un grand cycle et tout aussi Kubernetes, c'est un concept. Pas encore une fois, je bosse sur des projets qui ne répètent pas ces patterns là.

Pour moi, on est sur des projets politiques dont l'objectif est de vendre des choses aux gens et pas de leur régler leur problème. Ok, mais alors mis à part je sais pas qu'est ce qu'on a? On a Linux, on a je sais pas quel projet de la fondation Apache. Non, tout ce qui tourne dans freedesktop org c'est très bien, mais les gens de systemd, ils sont pas là pour te vendre un truc, ça marche très bien. Oui ok, mais là j'ai pas le temps, c'est un troll, j'attendais plus en plus.

Désolé, je te connais pas mais je suis d'accord, je suis d'accord. Mais bon, ça va mourir je le sens. Mais plus audio c'est génial En vrai c'est génial! Mais alors cette intégration? Non attends, attends, L'intégration audio a été un peu le même argumentaire. Je l'ai donné aujourd'hui à quelqu'un. Il avait tenté le coup sur Beryl, ça c'était passé nickel. Il y a eu une fuite de mémoire monumentale, c'est activé les poissons, mais ça c'était passé

nickel qu'on puisse guérir. Pour ceux qui se rappellent de FF sur lequel j'ai envie de vomir, qui m'était absolument, ils ont tenté la même sur PulseAudio, ça a merdé tu vois. Genre parce que on avait pas grand chose d'autre à ce moment là à faire. Enfin tu pouvais faire du streaming audio. Enfin ça a marché, t'avais la ZX, ça fonctionnait, alors sur ces deux applications, t'avais plus de sources.

Enfin tu avais, je suis d'accord, mais il restait l'intégration de PulseAudio. Ils l'ont fait huit mois trop tôt, tout le monde leur est tombé dessus. Catastrophe. Admettons. Mais en fait si tu veux, il ne faut pas. Enfin si tu veux. Aujourd'hui, la plupart des projets freedesktop, ils sont plutôt dans l'open. Dans la fondation, tu as quand même un paquet de trucs qui marchent très très bien. Enfin je suis pas au niveau. Enfin au niveau neutralité de ce

genre d'outils. Node c'est Il n'y a pas que des produits commerciaux. Mais peut être posez vous la question, peut être posez vous la question à ce moment là de vous en tant que communauté des OPS. Le problème qui est de continuer à penser qu'on devrait vous fournir des outils sur étagère qui fonctionnent et pas que vous avez à ouvrir le code et poster. Et fondamentalement, je suis entièrement d'accord. Salut Cube, tu as lu le code de cube avant de le coller en prod?

Non, j'en ai lu des parties, on a lu et on sait, on sait comment aller chercher. Et moi le premier jour, premier jour où je suis allé à la BNP, à la BNP, bosser, j'avais en moi et en face de moi une armée d'IBM. Il y avait un bug, on va mettre des gros guillemets à désespérer, des bugs, etc. Et ben le jour même, je suis allé leur sortir le code source, je leur ai pondu dans les temps Là dessus, la première réponse est ah mais toi tu sais lire le code source de cube. Voilà.

Mais genre ça arrive et avec Cube justement, c'est du go, c'est du go ultra mauvais, mais ça reste du go à peu près lisible. Ça dépend, ça dépend des coins, ça me pénible, c'est quand même non mais alors il y a un truc du FOSDEM de l'année dernière alors voilà tout. Et tous les trucs merdiques que je trouve dans un talk de l'année dernière du FOSDEM qui disait pour récupérer le CLR parce que ça a été écrit par des bugs et en gros c'est du c'est du.

Alors moi je défends rarement Java en tant que langage, mais en fait je défends beaucoup la JVM. Je trouve que la GDM est une très très belle. Le problème en fait, c'est juste des développeurs qui ont codé d'une certaine façon alors que le langage s'y prêtait pas et donc ils ont fait un truc. Je fais plein de choses. Scala ça ressemble un peu au C du kernel Linux en fait. Partie mais il est compliqué quand on le regarde dans les yeux. Il y avait même le C de systemd

aussi. Et vraiment c'est bizarre. Enfin genre 1C1C poilu quoi. Enfin c'est un C qui fait des choses quoi et qui fait des choses peut être un peu trop. Enfin moi encore une fois, moi je suis pas à la base, je suis un vrai dev donc j'étais le seul homme de la boîte. C'est pour ça que j'ai créé avec Oliver à la base. Mais. Mais moi si tu veux, ma vision sur ce genre de produit est plus le produit est intégré dans du code, moins il

y a de bash, mieux je me porte. Et avec systemd j'ai réussi dans des fichiers de couches de cinq lignes à remplacer 800 lignes de bash. Et bah j'ai fait ça. Je suis d'accord. Moi j'ai remplacé toute la prod, toute la prod. Vous avez des docker lancés à la main? Non mais tu t'imagines que t'imagines que toute la prod de ta bouteille, toute la prod de ta bouteille, elle tourne sur un script shell qui est inclus dans une ressource Chef? Non, c'est le chef.

Ah non, non, non, non, non, non, non, non, non! Les chaînes qui appellent des fouets du rugby pour faire des opérations, etc. Tout ce code là, en gros. Oh combien il y avait 200 lignes de codes qui n'utilisaient que la stdlib avec une couverture de couverture de test à 60 % d'open SSL je crois. Non, non, non du tout. J'utilisais que la stdlib et elle était testée, etc. C'était toute la partie qui décrit le déchiffrer et chiffrer et

déchiffrer les secrets que j'avais. J'avais un gars, il est arrivé, il a mis un truc ici dans la liste des technologies, il n'y a pas marqué Go et pas marqué Shell non plus. Encore une fois, si je vais pas, je vais pas. Toutes les erreurs managériales et politiques que tu as dans ta vie pour le bien et bon pour la santé mentale des gens qui nous écoutent. On pourrait, on pourrait se dire d'abord là, en ce moment, ils nous voient, ils nous entendent plus normalement. On va essayer de coller.

Les morceaux sont sortis, c'est devenu terrifiant pour eux. Et je vous propose qu'on essaye de Roundup le truc, quitte à ce à se revoir une autre fois. Je pense qu'on s'est compris sur un truc. Moi j'ai des griefs techno à apporter au truc. Vous pour vous, ça vous a libéré parce que vous étiez dans des écosystèmes déplorables. On arrive, on arrive à faire. Je pense que les écosystèmes déplorables sont manifestement majoritaires, malheureusement. Soit.

Néanmoins, moi, les les problèmes techniques que je vois sont non excusables dans un cadre de prod selon moi. Après, vous faites bien ce que vous voulez. Je rappelle que des gens mettent encore du Drupal quatre en prod.

J'ai eu l'impression, la totalité de l'expression de me souvenir de mes premières années en web agency où je disais on va quand même pas utiliser du SPIP, c'est de la daube et on disait ouais mais ça ira plus vite et ou en fait, très concrètement, on avait des projets où la complétude allait très vite et on mettait des mois à aller vers le bien et on atteignait jamais. Parce que la dette de concepts et de trucs qu'on avait fait au début était non remboursable.

On avait fait des flots majeurs au démarrage. On est entièrement d'accord là dessus. Mais après je pense que c'est la même chose. Mais au moins peut être que je me trompe et que des bons samaritains

débarqueront et corrigeront les bugs. Je pense que le projet tel qu'il est politiquement interdit, ça alors, on peut attendre 6.2 %. Soit on s'adresse à des gens comme vous qui sont dans l'incapacité de le faire, soit on investit sur ces projets précis là dans une infrastructure dédiée qui ont qui ont à mon avis une flow.

Aujourd'hui, il y a des trucs qui vont être très difficiles à corriger la spécialisation, l'hétérogénéité, dire on va pas corriger un nouveau projet après, mais, mais moi je le souhaite de tout genre, mais vraiment de tout mon cœur. C'est genre Kubernetes, j'ai plein de griefs contre lui etc. Il y a des choses qui sont des choix.

Par exemple comment le mono repo de Kubernetes à l'heure actuelle avec plus de 25 binaires, 25 main Go dans un même repo, etc. Que même le client GO, c'est en fait un vendeur qui est enlevé, qui est mixte mais c'est de la merde, c'est de la merde. Tout ce truc là a été bloqué par les gars de Kubernetes, de Google au début et moi j'ai vraiment beaucoup de problèmes avec comment ça a été fait. Donc je souhaite absolument que tout ça, ça saute. Je suis entièrement d'accord, mais

vraiment. Et je n'attends que ça. Et le jour où ça arrive, j'irai dessus. Je serai un early adopter le premier jour et je continuerai le premier jour où ça se fait. J'espère juste que les gens qui feront ça ce jour là auront

trouvé un modèle économique. Parce que, en sous jacent, le problème c'est le modèle économique de l'open source et surtout en France. Et là c'est ça le problème que j'ai envie de dire en France, Je ne sais pas, je ne sais pas comment vous avez réussi, vraiment, mais je trouve ça fabuleux. Et même d'ailleurs, c'est un plus l'exploit. L'exploit premier de Clevercloud, c'est d'avoir réussi à tenir en étant en France avec l'écosystème de la tech française, je te le cache pas.

Alors moi c'est ça. Et pour le vivre, même tous les jours avec des gens qui sont avec des étrangers, qui font des trucs plutôt bien dans des boîtes assez grandes, et les Français qui sont en train de bloquer des cinq fers pour essayer de faire en sorte que ça ne se passe pas bien en France. Et ça, c'est quelque chose que je vis à peu près tout le temps et donc clairement c'est le cas à l'heure actuelle et je le vivre.

Vivre de bonnes technologies à l'heure actuelle, c'est un problème et c'est et je pense que pour le faire, il faut continuer à défendre cette vision que LaTeX c'est un truc d'ingénieur. Et moi j'en ai marre qu'on me vende un truc de pas ingénieur, j'en ai marre qu'on vienne me parler de technologie en me parlant des problèmes de management, moi, que les gens ne sachent pas faire du management, alors leur proposer hormis de lire des bouquins, mais

surtout faisons des jolies choses. Et moi c'est ma position, les gens font bien ce qu'ils veulent, Je maintiens que c'est ça le truc. Et après, après après tu sais bien que le goûts et les couleurs, moi par exemple, je trouve ça extrêmement élégant dans la manière où c'est fait, mais parce qu'on a des goûts et des couleurs différents. Et lancer des binaires au pif les uns à côté des autres, ça finit à la fin. Je trouve ça cool. Mais. Mais en fait, surtout dans l'ingénierie, c'est

l'optimisation en domaine contre. Et ben j'ai des contraintes qui sont un peu du management, j'ai des contraintes qui sont de plein de choses, etc. C'est je fais de l'optimisation où je peux et ça c'est de l'ingénierie, c'est pas de la technicité, c'est c'est de l'optimisation de domaine et c'est ça l'ingénierie, l'ingénierie dans la définition de Jancovici, parce que c'est la pure, c'est du Jancovici, c'est des Jancovici, etc. Je suis pas nécessairement d'accord pour accepter

l'environnement humain là dedans, parce que pour moi c'est pas un domaine contre un environnement, c'est toujours ce que tu présuppose de ce que vont penser les managers. Et si tu veux, moi il m'est arrivé de rentrer dans des pièces où on me disait c'est mort et d'en sortir vainqueur et sans avoir tué personne. De façon très simple, très carrée, en expliquant concrètement aux gens comment ça allait se passer.

Et à chaque fois qu'il y avait quelqu'un qui avait une objection, je lui ai débunké son extrait, son objection. Je vous ai expliqué ce qui était selon moi, des griefs technologiques sur ces technos qui, à mon avis, sont des dangers qui sont des dangers forts. Parce que si on a beau avoir dit la vertu, c'est cool, le machin etc. Aujourd'hui,

c'est pas là dessus que c'est basé. Aujourd'hui, on a des problèmes de mise à jour, on a un problème de dockerhub, on a un problème d'isolation, on a un problème de contrôle, de conformité, du control, du control manager, il y a plein de problèmes. Alors on me promet que demain ce sera génial et je te promets qu'on te promet. Pas du tout. Je pense qu'il y a personne d'entre nous, c'est juste que je pense que ça va rester pareil donc ça va rester aussi bloqué avec, on sait pas là dedans,

mais il y aura, il y aura demain. Moi je rêve, je rêve de conteneurs qui sont plus des leaders etc mais d'autres choses avec une envie. Tu rêves Mais est ce que je veux dire par là?

C'est que toi aujourd'hui, tu vois le potentiel du projet, tu te dis la la communauté va le faire. Soit. Ouais, le potentiel du projet, je le dis Non mais moi j'ai vu, moi j'ai vu ce qui était avant et surtout les technologies, moi j'ai fait du méso, je suis désolé, c'est une merde, c'est une merde. Et moi j'ai du apprendre à faire des containers, j'ai mis de la prod sur tous les containers, sur tous les orchestrateurs. Très sincèrement, celui qui va le

moins appeler Seveso, j'ai pas aimé ça. On parle pas de moi là. Non, je parle de mes OS. Vraiment. C'est que je sais que je mets quoi dans mes os si tu fais juste tourner mes os? Non, non, non mais non! Mais oui, mais dans ce cas là, tu vas pas comparer avec Kubernetes si tu fais. Pas du tout le même degré de flexibilité. Mes os, mes os. Tu mets un framework par dessus, c'est mes os. Quelque chose qui ressemble à Kubernetes, mais mes OS tout court. Mon marathon,

c'est pas si pénible que ça, tu vois. Ah bah ça va, on a wipe la prod juste avec un push merdique parce que les pieds à y aller, la vie est une merde en disant que c'était pas très exigeant, voir même pas, tu ne peux même pas savoir le check que tu as mis, genre tu pousses un check, tu peux même pas le récupérer. Et moi c'est comme ça que devrait fonctionner les check. Mais ça c'est encore une fois. Toutes les autres technologies que je connais, que j'ai vu technologiquement sont en dessous

de cube. Tu n'es pas parfait. Est ce que je sais pourquoi notre monitoring fonctionne? Ça, c'est un sujet qui est très amusant. Pourquoi notre monitoring à nous fonctionne? C'est par rapport à toutes ces technologies que tu as des problèmes de box, de machin, de truc. Mais Prometheus, j'ai eu peu de problème. On pourrait en avoir. Enfin, tu as vu que ça demandait quand même vachement d'avoir un Prometheus exporté dans la technologie que tu monitore aujourd'hui. Bah ok, c'est pas c'est pas très

très grave, ils auraient du même cash avec. On t'en reparle. C'est Oui c'est facile, il faut que tu modifie webcasts, il faut que memcache tu décides qui peut répondre à tes questions. Ils ont dépassé le stade que si tu as besoin de plus des stats, tu vas aller dans les. Couilles. Il a fallu que je me cache moi même. Donc ouais, ç'aurait été un échec. Non mais d'accord. Une fois que ce que je veux t'expliquer c'est que moi j'ai pas envie qu'un process externe puisse parler à mes machines.

Donc mon monitoring fonctionne. C'est entre autre parce qu'on est en vertu, C'est à dire que aujourd'hui, c'est parce qu'on peut se permettre d'avoir un vrai gestionnaire de processus qui va avec chaque apps que tous ces problèmes là, on peut les résoudre. Après tu peux me dire oui, mais on peut bricoler machin. Oui, c'est vrai, mais justement moi, si jamais j'ai envie de ça dans ton code, tu peux très bien lui mettre un exporteur. Et ils sont vraiment ensemble, Ils sont connectés?

Non, ils sont totalement ensemble, isolés, tout ça tout ça. Ils sont pas isolés, ils sont dans le même os que tout le reste. Ce qui veut dire qu'à chaque fois que tu vas chercher de la data sur l'OS en lui même, soit tu as bien configuré des conteneurs et il n'a pas accès à slash proc, soit les données qui sont remontées par proc ne sont pas du tout ce qui parle de ton propre mais de l'intégralité de l'OS. Et donc tu as des problèmes de monitoring ne serait ce que ça tu vois?

Enfin en fait, si tu veux, à chaque fois que je pourrais avoir des problèmes, tu en as beaucoup, tu en as, tu en as. Mais en fait, avant, dans toutes les prod où je suis allé, les gens ils se lançaient tout en mode yolo avec seize bits. Et en fait, arrête de me répondre à chaque fois. Ouais mais avant je bossais dans un endroit où les mecs faisaient de la civilisation qui ne bénéficie à personne. C'est pas une optimisation, ça bénéficie à tous mes utilisateurs.

Mais non. Oui mais si concrètement ça ne pas l'avoir fait, ça n'aurait rien changé. Tu as perdu du temps en fait. Et ça a tout changé chez le monde entier. Le monde entier ne peut pas juste te dire que j'ai fourni un exporteur pendant X années sur un memcache. Il faisait le travail, il fournissait de la valeur à mes clients et j'ai ressenti aucun problème. Il ne s'est passé rien pour nos clients alors qu'au bout de 20 ans,

il s'est passé quelque chose. Peut être qu'au bout de 40 ans, il s'est passé quelque chose, mais en attendant, je ne suis même pas sûr. Donc est ce que le risque en vaut la chandelle? Et en plus, le principal étant d'avoir une telle exigence, est ce qu'il y a vraiment une valeur? En fait, la différence entre avoir une telle exigence et pas avoir une telle exigence est que ton sommeil la nuit est extrêmement qualitatif parce que je sais exactement ce

qui va se passer puisque ça a été calculé. Non mais faire. Mais je pense qu'il y a quand même une certaine part de fait. En fait non, Dans un domaine que je gagne et à un autre endroit dans un domaine. Mais tu vois, c'est toujours le même, mais dans un monde limité, tu peux te le permettre. Et je suis entièrement d'accord avec ça.

C'est juste que Kubernetes, il a un principe de base qui est de pouvoir faire tourner des applications legacy, des applications que je ne fais pas tourner, des applis legacy dans Kubernetes. Arrêtez de déconner. Il a. Il a comme but de pouvoir le faire. Oui d'accord, mais c'est à dire que c'est pas en passant, ça veut dire qu'en gros oui mais nous on passe, on fait tourner des applications.

Pour le coup très legacy, c'est vraiment des choses qui ont été en fait en gros le but normalement non, mais c'est en fait en gros on a pas de prob. De ce type là, nous on a que des trucs, peut être pas, mais je le garde pour nous les vieux trucs. Mais non, ils sont sous contrat avec IBM puisque sous contrat avec Solaris

ou encore la machine à écrire. Mais en tout cas, voilà, je pense que là vous avez déjà ce podcast, c'est le plus long qu'on ait jamais fait et on avait d'ailleurs un des plus intéressant et j'espère que vous m'entendez puisqu'on parle. Donc là on a eu un problème de son Si jamais on a on a tout baisé, voilà, il n'y a plus rien. Donc le zoom nous enregistre depuis tout à l'heure, mais ça se trouve pas. Terminer la conversation au resto, c'est ça? Mais en tout cas,

merci beaucoup d'avoir écouté. Je pense qu'il y aura des suites, il y aura tout ça etc. En d'épisode on va le sortir en trois parties donc la dernière partie. Mais.

Mais en tout cas merci à vous d'avoir écouté, merci à toi Quentin d'être venu nous parler etc. On a. On a vu que genre hotline Twitter on peut discuter normalement avec des gens, mais c'est très bien de le dire avec les gens qui regardent ça de l'extérieur, on a l'impression peut être que on est des grands méchants qui, qui, qui, qui ne savons pas parler, etc. Non, on peut avoir des divergences et pourtant s'entendre et et voilà, c'est juste des il souffle

Franchement les mecs on s'entend. Mais non mais c'est d'accord, en fait on est pas d'accord sur de multiples trucs, mais en fait c'est un problème. Enfin comme souvent c'est un problème de contexte. Moi je il y a des choses c'est en fait. Après ça dépend ce qu'on fait dans la vie, mais c'est peut être le fait d'avoir été connu jeune pour mon code, mais en fait moi j'ai un truc, c'est les gars,

je mettrai pas de la merde en prod. Et en fait le truc c'est que si ça se passe comme ça, je vais passer la porte et pas revenir. Et du coup moi je mets pas de la merde en prod, il n'y a pas de discussion sur le sujet tu vois. Et ça c'est ça me rend beaucoup plus serein et du coup ça nous permet de construire des choses. Je dis pas qu'on a eu raison sur tout, on a fait plein de merdes, il n'y a pas de, il n'y a pas de discussion. C'est juste que je pense que là on a pris des mauvaises,

des mauvaises décisions. Après, j'entends le discours qui dit ouais mais avant on avait vraiment de la daube et j'ai pas les moyens de tout recoder. Ma réponse c'est de dire regardez ce qu'il y a d'autre, voilà. Mais c'est ça, c'est ça. La question qu'on m'a posée, c'est qu'à l'heure actuelle, il n'y a pas grand chose d'autre viable, mais au moins vous en avez fait par des équipes qui parlent français, qui font le boulot qu'avant et.

Et la question elle est jusqu'à quel point on va continuer à aller embrasser Google sur la bouche? Et je pense que la base plus IBM qu'autre chose. Enfin quand tu vois ce que. Non mais un jour auprès des oiseaux ces jours ci. Enfin je sais pas, il y avait. Il y avait moyen aussi à un moment de t'embrasser ça au tout début et d'y être. Ça a été le cas avec certains de mes amis. On s'est fait défoncer en plein de boîtes françaises etc qui n'ont pas

pu y aller, moi et des scaleway. OVH a passé à Cuba dès le début pour être des vrais acteurs français de cubes, pour pouvoir peser dans le game etc. C'est pas pour dire, mais ils n'ont jamais pesé dans le game. Je sais pas à quoi tu rêves, mais sans déconner, tu tu. Tu vas souvent dans la vallée parce que pas souvent. Mais. Mais t'as pas senti. Enfin moi j'échange des mails des fois. Surréaliste. Il m'est arrivé de faire des trending hackernews avec des techno.

Tu vois, les mecs de plusieurs boîtes connues m'ont envoyé des mails en disant c'est génial ce que vous avez fait, On boit un café pour en parler, leur dire on va faire un call parce que moi je suis à Nantes, on va pas boire de café demain parce que ce que je suis à Nantes France. Mais par contre je passe probablement le mois prochain dans laquelle on se voit à ce moment là. Ah non parce que vous savez coder en dehors de la vallée? Non mais tu sais,

t'es là genre Mais va mourir. Alors qu'en vrai, quand tu bosses dans les boîtes de la vallée deux minutes, vu qu'il y a un marché de l'emploi qui est tellement tendu qu'en vrai tu prends un cuisinier de burritos et c'est pas négatif envers les cuisines burritos et tu lui mets un t shirt cube. Le mec est embauché développeur star à 300 zéro zéro zéro balles à Noël, ce qui fait que tu as un tocard au mètre carré en code mais qui défonce l'entendement quoi.

Et franchement, t'as cru deux minutes que si OVH avait migré mais six mois plus tôt sur Kubernetes, il devient leader dans le marché. Regarde Zalando, Zalando s'en sort super bien mais regarde sur Docker Docker, il y a eu trois. Alors je sais pas, c'est reparti. Il y a eu plein de fois au mois de janvier de signer du dock du docker datacenter dans le monde, dont une énorme française. On a donné le moindre poids, mais c'était genre ça a jamais marché.

Ouais, c'est bien ce qu'on dit, mais en plus c'était une version closed source. Mes souvenirs. Mais bien sûr! Comment tu veux peser? Moi je suis à l'open source avec des gens qui baisent de manière open source. C'est genre on parle, on parle open source quoi, qui peuvent protéger des gens, des gens qui achètent, de l'IBM, de l'IBM closed source sur le mainframe. Ils vont pas peser non plus dans la construction. Et moi mon ticket de support, c'est bien ce que je t'ai dit.

Je ne vois pas en quoi ça nous pèse. Il y a Bloomberg qui pèse aussi. Il y a quand même pas mal d'acteurs européens. Le truc c'est que en France, c'est un néant. Il n'y a aucune kubecon qui est jamais là en France et je pense qu'il y en aura aucune qui viendra en France comme en Europe. Elle viendra jamais, il y en aura pas en France parce qu'en France il n'y a pas d'autres villes que Paris pour organiser une kubecon que Paris c'est extrêmement cher et que les infrastructures

sont pénibles à gérer. On peut parler du marché de la conférence, c'est pas un souci. C'est beaucoup plus simple d'organiser une conférence à Amsterdam ou à Barcelone. Enfin, franchement, je connais très bien le game des conférences et pour avoir organisé plein de conf à Paris, c'est pénible à souhait. T'as pas les hôtels que tu veux, t'as pas les infras avec l'aéroport, t'as pas les Ne serait ce que louer le palais des congrès de Paris un

an à l'avance, c'est impossible. Et ensuite louer le Palais des congrès de Paris, Faire un dossier en soi, ça c'est un problème d'infrastructure, d'organisation événementielle. Et sincèrement, c'est ça le problème. C'est pas le plus gros aéroport d'Europe, c'est pas les aéroports les plus simples. Tu dois prendre des aéroports où c'est très simple de venir des États-Unis. Barcelone, c'est un excellent hub Amsterdam, c'est un excellent hub Londres,

c'est un excellent hub. C'est juste que tout est cher. Donc non, non, franchement, c'est pas pour ça. On n'a pas pesé dans le game Kubernetes parce qu'on n'avait pas les gens pour jouer dans le game Kubernetes et parce que la vallée n'est pas du tout ouvert à nous laisser. Et ça c'est un énorme point. Mais on doit être le point de notre prochaine discussion.

La question est est ce qu'il faut continuer en tant qu'Européens, à être une dépendance du réseau américain maltraité ou est ce que on devrait construire notre propre vision d'internet ou aller sur les chinois? On va le faire. Moi j'ai une équipe à 80 % de chinois et les technos chinoises, mais c'est en gros là à l'heure actuelle. Le truc c'est qu'on n'y arrivera pas si jamais toute notre tech reste tout le temps dix ans en retard. Tu vois, c'est pas le cas chez moi.

Mais enfin, c'est à moi qu'on a dit que j'étais, j'étais daté et que j'étais un cacochyme qui savait pas de quoi il parlait, tu vois? Non, non non non. Mais dans les conteneurs, au final, tu utilises quand même in fine une notion de conteneur. À mon sens, les conteneurs c'est une notion, c'est pas une implémentation. Let's go! Non mais attends, après la bouffe, je vais t'expliquer comment marche le truc.

Et en fait, l'histoire que tu dois comprendre, c'est que justement non, c'est parce que nous, notre truc est sémantique, c'est pour ça que ça marche. Encore une fois, ce que je reproche aux conteneurs, fondamentalement, c'est leur absence totale de sémantique, c'est de faire un zip de binaire. Je trouve que c'est dommage. Ouais, mais dans ce cas là, t'as plus du tout la génération, la génération mais oui, non, non, non mais attends, une entreprise, non, non, non, non, non non!

Mais que exécuter des binaires c'est pas. Expliquer comment ça marche, on va le faire au resto, on va pas repartir en arrière au x ième fois. Merci à tous. Et puis et puis à une prochaine. On espère beaucoup plus vite que les dernières fois. Faites nous du feedback. Je pense que vous allez nous dire que c'est un chouilla long, mais écoutez, écoutez, les ont plusieurs, c'est pas jouable, c'est pas juste du blabla. Non, c'est bon, allez, à plus. Merci aussi.