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.