Dev'Obs #14 / Kubernetes, révolution ou buzz marketing ?
Télécharger MP3C'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.
Créateurs et invités
![Dev'Obs #14 / Kubernetes, révolution ou buzz marketing ?](https://img.transistor.fm/y4Grzbv32_UtJ-ZYk26RNYlsA_btB0y65jEUuA_p4qU/rs:fill:800:800:1/q:60/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS9lcGlz/b2RlLzIxNzYxMy8x/NTg0MTA3MzYxLWFy/dHdvcmsuanBn.webp)