DevObs

C'est d'abord une culture.
Quand on est en DevOps, tout le monde

DevOps et Agile font effectivement
partie de la même famille.

Sa virtualisation applicative
s'est très bien.

Aujourd'hui,
ça nous prend dix minutes et un café.

Ce n'est ni être, ni être,
c'est avant tout la communication.

Ce mouvement DevOps, c'est tout
simplement drivée par la communauté

et endossé par les entreprises.
J'ai adopté une démarche DevOps,

le développement agile.
On a accéléré déploiement.

Ça amène une clarté sur le
travail de l'être dans une

démarche d'amélioration qu'on se
retrouve face à des familles

naturellement ensemble, ça donne
des résultats concrets, des box.

L'objectif individuel,
ça s'atteint, alors que l'ambition,

ça se partage. Bonjour les DevOps.
Alors aujourd'hui, petit aparté

inhabituel avant le début du podcast,
juste pour vous dire que celui ci,

comme vous l'avez sans doute vu,
est assez long plus de 3 h,

mais il est aussi extrêmement
dense et riche en informations,

donc n'hésitez pas à l'écouter
sans doute en plusieurs fois,

revenez dessus, mais je suis sûr
que vous apprendrez quelque chose.

Au moins,
ça vous donnera plus d'informations

sur ce que les gens peuvent penser,
aussi bien des conteneurs que de

Kubernetes d'ailleurs,
et même globalement de l'état de

la tech à l'heure actuelle en
France et dans la Silicon Valley.

Donc n'hésitez pas à venir nous voir,
à commenter et également à venir

participer.
Soyez le prochain interlocuteur,

que ce soit de manière
ponctuelle ou régulière.

Je suis sûr que vous avez des
choses à dire sur le DevOps,

une opinion différente ou pas
d'ailleurs de la nôtre.

Donc n'hésitez pas, venez nous voir.
Et sur ce,

je vous laisse avec le podcast.
Bonjour à tous et à toutes et

bienvenue dans le 14ᵉ numéro de
DevOps.

Alors on est super en retard, ça
fait presque un an qu'on n'avait pas

fait de numéro donc désolé à tous.
En plus, j'ai même reçu plein de

messages pour me demander un nouveau,
un nouveau numéro. Nous voilà!

Et donc si jamais vous aussi vous
avez envie de venir parler d'un

sujet autour du DevOps ou même
d'ailleurs autour de Kubernetes

dans le podcast dans ton cube,
n'hésitez pas à venir.

C'est vraiment ce qu'on recherche des
gens autres que nous pour parler.

On n'a pas envie de faire un entre
soi, donc c'est vraiment l'intérêt

de venir et de proposer des sujets
ou quoi que ce soit. D'ailleurs.

On sera début du mois de février
au FOSDEM.

Donc s'il y a des gens qui sont
qui sont au FOSDEM,

n'hésitez pas à venir nous voir.
On pourrait même faire un

épisode spécial à ce moment là.
Il y a du temps au FOSDEM donc

n'hésitez pas à nous pinguer,
on pourra s'organiser un petit moment

là dessus et. Et voilà pour les news.
Et on commence donc cet épisode

sur Alors épisode à troll sur
Kubernetes révolution ou buzz

marketing et autour de la table,
nous sommes quatre.

Je vais laisser chacun se présenter
en commençant par le nouveau Quentin.

La première personne, la seule
personne qui n'est jamais venue avant

dans un désert, dans un DevOps.
Je vais te laisser te présenter.

Bonjour à tous,
je m'appelle Quentin Adam.

J'ai le fameux pseudo imprononçable
sur Twitter, ce qui pour les

spécialistes en fait est un pattern.
Quand tu es sur un clavier

azerty et que tu te faisais bien
chier quand j'étais ado.

Et en fait je dirige une boîte qui
s'appelle Clevercloud qui fait

un outil d'automatisation forte
des infrastructures de façon à

libérer du temps pour les OPS,
permettre au dev d'aller plus vite et

renforcer l'infrastructure. Super!
Et les deux anciens,

les deux anciens.
Barthélémy Osmond,

un vieux de la vieille du DevOps.
Récemment, j'ai rejoint une nouvelle

petite start up qui s'appelle Store
Lift et qui propose des magasins

autonomes, tout simplement.
Avant, tu étais chez Criteo pour

rappel, donc un peu de Kubernetes
et beaucoup de débrouillardise.

Et Jérôme Delahaye?
Je suis chez BNP Paribas et on

s'occupe de toute la partie cube
et maintenant super!

Et donc moi Guillaume Letteron
et je suis toujours indépendant,

je fais toujours du Kubernetes, etc.
Et c'est ça fait la transition

et c'est pour ça qu'on est là.
Alors pourquoi ce sujet aujourd'hui?

Alors il fait suite à un tweet que
j'ai envoyé la semaine dernière

d'ailleurs, une série de tweets sur
Kubernetes, en disant bien que.

Enfin, en disant de mon opinion
que Kubernetes,

c'était donc maintenant assez vieux
puisqu'il a même cinq ans et demi,

que ce n'était plus un sujet hype et
que globalement, maintenant, en 2020,

c'était vraiment, enfin c'était pour
moi un non-sujet que que Kubernetes.

Et donc s'en est suivi une,
une longue, longue thread extrêmement

touffue et poilue pour le coup,
puisque en fait des arguments,

enfin des échanges d'idées plus
ou moins bien faits on va dire,

ont été, ont été échangés.
Et ça me permet d'ailleurs de

rappeler une règle qu'on a ici,
je pense, assez implicite,

qui est qu'en fait je pense qu'aucun
d'entre nous troll en fait, c'est à

dire qu'on a des avis différents.
Mais ce que j'aimerais ici, et je

pense que c'est le cas de Quentin,
et c'est le cas entre tous,

c'est tout ce qu'on dit, on le pense,
on ne le dit pas pour faire,

pour faire enrager les gens en face.
On a le droit de ne pas être

d'accord, mais on ne fait pas
pour enrager les autres.

C'est juste on n'est pas
d'accord et c'est très bien.

Et ça ne va pas nous empêcher
justement de faire une table ronde

comme ça, d'aller prendre un verre,
d'aller manger ensemble.

Et c'est quelque chose dont on a
le droit de pas être d'accord et

pourtant de pouvoir de pouvoir
discuter, c'est quelque chose

d'important là dedans. Et.
Et justement, cette divergence là,

en fait, suite à toutes ces opinions,
suite à toutes ces discussions,

on est arrivé en fait à un.
Point,

notamment avec Quentin où on arrivait
sur des divergences profondes,

en fait sur des divergences.
On a vu que là, à ce point là,

on n'était pas d'accord.
Et je pense qu'au lieu de moi,

parler et de dire ce que c'était,
je vais laisser peut être Quentin

expliquer, lui, la vision qu'il
avait de la suite des événements,

de manière très succincte,
si jamais tu devais te résumer,

moi je vais résumer de mon côté,
mais j'aimerais bien avoir un autre,

un autre point c'est ça.
Non mais là,

pendant une minute ou deux,
juste juste après, on va revenir

dans le sujet plus du débat qu'on
pourrait avoir et même techniquement,

parce que je sais qu'on m'a aussi
demandé d'être un peu plus technique.

Je pense que c'est un sujet qui
est à la fin,

qui est éminemment technique en fait.
Je pense que là, je pense que la

divergence est assez simple.
Pour moi, une infrastructure

aujourd'hui doit s'autogérer, c'est à
dire que tu as des humains, Donc les

humains sont des gens magnifiques
mais profondément imparfaits.

Et aujourd'hui, ce qu'on demande
à une infrastructure,

c'est de délivrer 100 %.
Ce qui veut dire que s'il y a

des humains sur la prod,
ça ne peut pas marcher.

C'est statistiquement impossible
que ça se passe bien.

Donc il faut supprimer les
humains de la prod pour supprimer

les humains de la prod.
Il y a plein de solutions,

mais la meilleure des solutions,
c'est probablement un usage

massif et statistique.
C'est à dire qu'il faut faire un

cœur qui soit basé sur soit de la
récurrence, soit de l'apprentissage

statistique, ce qu'on appelle
aujourd'hui du machine learning ou

de l'intelligence artificielle.
Je sais qu'on s'est fait chambrer

parce que notre nouvelle baseline,
c'est i-power DevOps, mais c'est

littéralement ce qu'on fait en fait.
C'est à dire que nous,

on a foutu un cœur statistique qui
réagit à des règles statistiques

préétablies de par un apprentissage
pour faire fonctionner la prod.

Et c'est littéralement ce qu'on fait.
Et je pense que pour obtenir une

infrastructure qui fonctionne bien et
qui fonctionne de façon autonome,

qui libère les gens à la fois des
conflits internes, des boites,

parce que je pense que le conflit
entre le fameux ce qu'on appelle

dev et ops n'a pas été souleve.
Quand on a dit DevOps,

ça a été réglé dans certaines boites
où ils ont fait le truc qui permet à

DevOps de fonctionner, c'est à dire
fusionner les budgets et les équipes.

Mais tant qu'il y aura deux équipes
séparées, ça ne marche pas.

Et alors il y a un autre truc qui
s'est produit dans certaines boites,

c'est à dire qu'au début tu avais
deux équipes et là maintenant il y en

a une troisième qui s'appelle DevOps,
qui est censée faire le lien,

qui a son propre budget, ses propres
insights, sa propre façon de bouger,

ça ne marche pas du tout.
C'est toujours pas la bonne

stratégie.
Si vous voulez que ça fonctionne,

il faut fusionner les équipes.
Et donc moi je pense que pour

aller vers ça,
il y a eu des choix technologiques

de prix il y a quelques années,
qui sont à mon avis des échecs

qui ont déjà été des échecs dans
l'histoire informatique et qui à

mon avis sont des dead end et qu'on
est en train de payer les pots

cassés de ça et qu'on va encore les
payer pendant quelques années avant

d'avoir la paix là dessus. Voilà.
Alors c'est bien parce que tu

arrives justement dans notre premier
point et qui est donc la suite de

de notre discussion, qui était
justement ce dead end technologique.

Tu as employé le terme là dedans
et donc la question,

la question qu'on peut se poser
c'est justement donc est ce qu'il

y a un sens à l'innovation?
Et je vais donner mon avis là

dedans qui rejoint le tien,
c'est que je ne pense pas,

enfin, qui est en contradiction.
Je ne pense pas qu'il y a des

dead end technologiques.
Je pense qu'en fait toutes les

technologies apprennent les unes
et les autres.

Ces technologies là d'ailleurs
s'entrecroisent et en fait il

y a une dépendance au chemin
qu'on a emprunté.

C'est à dire que les technologies
de demain ne seront qu'en fait

un découle des technologies
qu'on fait maintenant.

Et en fait il n'y aura personne
qui devra faire marche arrière.

En fait, c'est le DTN.
Donc l'impasse, l'impasse dans

laquelle on sort, dans laquelle
on va voudrait dire qu'une fois

qu'on est au bout, il faut mettre
la marche arrière pour revenir.

Et les gens qui sont restés hors
de l'impasse ont gagné.

Ça veut dire ça, la technologie,
c'est dans l'évolution,

c'est une réalité.
Alors là où je te rejoins,

la technologie va toujours en avant.
C'est le fameux retour accéléré

du progrès.
C'est pas Google ou whatever qui

t'explique que toute technologie
apporte à la suivante.

Et c'est la progression technologique
humaine est une courbe exponentielle.

Néanmoins,
quand tu dis chaque technologie

apprend de ses prédécesseurs,
c'est parfaitement vrai et

notamment ça apprend des erreurs.
C'est à dire que la dépendance au

chemin, elle existe, mais pour
autant elle n'est pas valide.

C'est à dire que c'est pas
quelque chose dont tu dois en

permanence hériter l'évolution.
Par exemple, dites des espèces

de Darwin et buissonnante.
Donc tu as des buissons et des

fois ça finit par un dédale
justifié ou non.

C'est ça qu'il faut bien comprendre
Quand on parle d'évolution

buissonnante, tu as des évolutions
qui meurent pour de mauvaises raisons

D'orgas d'évolution des espèces.
Les trois ou quatre individus qui

avaient une mutation pour des raisons
complètement exogènes n'ont pas été

capables de se reproduire et donc
donc non pour des raisons exogènes.

Je t'ai dit imagine, tu as,
tu as, tu as trois individus qui

développent une capacité incroyable
à vivre 150 zéro zéro zéro ans.

Au même moment, il passe sur une
route, c'est la même famille,

il passe sur une route sous un
éboulis de rochers.

Ils sont tous tués en même temps
parce que par contre, autant ils

ont une longévité extraordinaire,
par contre, personne ne résiste

au rocher à ce moment là.
Pour des raisons exogènes à leur

capacité de mutation, ils sont
morts pour de mauvaises raisons.

Donc en gros, c'est que ce gène là ne
s'est pas transmis et n'a pas et

n'a pas et n'a pas, n'a pas réussi
à profondément polliniser encore.

Utiliser ce terme là,
polliniser toute la population.

Et c'est pour ça qu'en fait
l'évolution des espèces est

buissonnante pour de bonnes ou
de mauvaises raisons.

Encore une fois, tu peux très
bien avoir une espèce avancée qui

meurt pour de mauvaises raisons.
Ok, alors donc pour revenir dans

un contexte technologique, là,
dans notre cas, si jamais on le

prend dans le cas de Kubernetes par
exemple, prenons de l'eau sur des

cas technologiques plus anciens.
Si on veut parler de l'évolution de

la technologie, prenons le zeppelin à
l'arrêt si tu veux des dirigeables

est clairement lié à un contexte
d'évolution qui a été un problème.

Prenons quelque chose de bien,
bien plus trivial.

Tu es en Europe pour se torcher
le cul, on utilise toujours du PQ

alors qu'on sait tous que ça étale
la merde et que ça ne supprime pas

les choses et que c'est très bien.
Alors là, pour mettre dans le

contexte, je vois la référence et
donc une vidéo de Dirtybiology qu'il

faut voir là dessus justement.
Mais c'est une excellente dépendance.

Si tu veux, c'est une très bonne.
Voyez la vidéo sur le PQ et pourquoi

on utilise du PQ alors que ça sert.
Enfin, il y a mieux, il y a mieux, Il

y a les fameuses toilettes japonaises
avec des douchette et il y a pire.

Faut être très clair sur le fait
qu'il y a pire.

Mais toujours est il que
l'évolution n'est jamais linéaire

et je ne connais aucun système qui
a une évolution linéaire parce

que là tout système d'évolution
génère une certaine entropie.

Et en fait tu fais juste un pari
statistique que les meilleurs

vont gagner.
Mais c'est un pari statistique,

c'est pas une certitude statistique,
c'est un pari statistique et c'est

pour ça que c'est buissonnant.
Donc on ne peut pas définir que

chaque invention est nécessairement
meilleure que la précédente.

Par contre,
on peut apprendre de ses erreurs.

Alors là je suis entièrement
d'accord avec toi,

C'est pour ça qu'en fait je vais peut
être repréciser ma notion de sens.

Et c'est là où on est d'ailleurs
d'accord, c'est que statistiquement,

dans la moyenne, à la fin on
arrive vers un meilleur en fait.

En gros, les évolutions tendent
vers un meilleur.

Et je pense que là dessus,
et c'est même d'ailleurs le principe

de l'évolution des espèces,
même si c'est en fait,

c'est la notion de frissonnant que
tu dis un peu ce que je disais.

Le maelstrom en fait, cette espèce
de de choses avec plein de choses

qui arrivent dans un, dans un tout,
dans le contexte des technologies.

En fait, je ne pense pas que,
en fait, tu as pris par exemple

l'exemple de ces trois personnes
qui sont écrasées.

La question est c'est de se dire s'il
y a dix zéro zéro zéro personnes qui

ont ce gène là, donc ça veut dire
une chose ou un événement critique

précis ne peut pas les supprimer.
Est ce que ces 10 000 personnes

là sont quand même dans quelque
chose dans un dead end en fait?

Est ce que est ce que d'un seul
coup les 10 000 on regarde

l'histoire du Blu ray et du HD-DVD?
Pas là pour le coup.

On était dans un dans un très
petit nombre.

Personne n'avait HD-DVD en fait,
le HD-DVD est mort avant même

d'être utilisé, mais il était
technologiquement supérieur.

L'histoire de Betamax et VHS,
c'est la même.

C'est pour t'expliquer qu'en
fait il était beaucoup plus cher

en fait technologiquement.
C'est à dire que oui,

pour un technicien, ça veut dire
en terme de qualité vidéo.

Le Betamax était bien meilleur, mais
le fait que le VHS était trop cher,

c'est pas lié en fait à la qualité
d'une technique. Alors exactement.

C'est à dire ça,
je suis bien d'accord avec toi,

c'est que l'évolution ne serait
pas tous taper Windows pendant

des années et Internet Explorer
six tu vois? Alors voilà.

Alors là alors là c'est super bien,
C'est qu'en fait c'est

l'évaluation des technologies
auxquelles on arrive.

C'est que l'évaluation d'une
technologie, est ce qu'elle se fait

juste par la qualité intrinsèque de
sa technique, de sa qualité du code,

de son, de sa, de sa.
Je sais pas, on pourrait voir plein

de plein d'évaluations là dedans.
Où est ce qu'elle est plus

globale que ça?
Typiquement, le VHS est quelque

chose qui marche parce que elle est
moins chère à produire et c'est une

qualité d'une technologie qui a
besoin d'être dans tous les foyers.

Alors que si jamais le lecteur
VHS était cinq fois plus cher,

et bien en fait, il se serait
jamais diffusé, même si la qualité

de la vidéo était meilleure.
Oui mais peut être qu'en

introduisant un plus grand nombre,
on aurait fait baisser le coût.

Mais en fait si tu veux,
c'est toujours.

C'est toujours le problème quand
on essaie de faire entrer des

arguments sociaux dans un dans
un choix technologique,

un choix technologique qui doit être
rationnel en tant qu'ingénieur,

à un moment on se pose des questions
et puis après on peut faire un

arbitrage financier si tu veux.
Il y a des il y a des technologies

qui sont des sales idées qui
reviennent de façon très régulière.

Si la marche du monde est faite
autour du pétrole aujourd'hui,

c'est pour de bonnes raisons
techniques et de très mauvaises

raisons commerciales.
Parce que c'est tellement plus

simple aujourd'hui.
Mais on a tous conscience aujourd'hui

que c'est une mauvaise idée.
Pour autant,

on peut pas résoudre notre dépendance
au pétrole en trois jours.

Bah en fait on y serait même pas.
Moi ce que je pense vraiment,

c'est qu'on y serait même pas là
sans pétrole.

Pour le coup c'est le pétrole est la
base de toute notre civilisation

actuelle et c'est pour ça qu'on
a une dépendance dessus, c'est que

justement on a une dépendance.
C'est à dire que cette technologie

là, on a amené plein d'autres,
le plastique, juste le plastique,

c'est, Ouais,
je parle de brûler des hydrocarbures.

Le plastique, pour moi, c'est
vraiment un autre essor. Mais brûler.

Des hydrocarbures est très pratique,
mais du coup, ça nous a entraîné

dans quelque chose où on sait
tous aujourd'hui qu'il faut

qu'on trouve une autre solution
pour faire rouler des voitures.

Enfin, c'est pas que rouler les
voitures, c'est annexe.

Les voitures c'est le pétrole,
c'est le transport,

c'est le transport et le transport
c'est la mondialisation.

C'est là le gros problème en fait.
En gros, la mondiale est un autre

débat, mais c'est ça aussi.
Non mais c'est un super excavateur,

c'est Il n'y a plus de pétrole,
il n'y a plus de transport,

il n'y a plus de mondialisation,
on est dans la merde.

Le monde actuel c'est basé dessus.
Donc c'est ça toute la

complexité qui est derrière.
D'ailleurs que tu dis, c'est que

si jamais on si on se base sur des
technologies, en fait le monde

avance dans une certaine direction.
On s'est basé sur les technologies

et c'est très dur de faire ce
retour en arrière justement.

Tout à fait,
c'est C'est pour ça qu'aujourd'hui

je pense qu'on a fait des choix
technologiques graves dans notre vie.

Alors voilà, maintenant,
retomber sur nos pieds parce que

on parle de belles choses.
Quels sont ces choix graves que tu

technologiquement, que tu regrettes
ou que tu ou que tu ne supportes pas?

Enfin, quelque chose qui te.
Et c'est un avis a priori.

Là comme ça on pourra donner ton
avis et on va essayer de

rebondir là dessus.
Je pense que depuis les années 70,

à peu près tous les dix ans,
il y a quelqu'un qui débarque

avec une idée qui est direction.
Prenez tous les process des gens

qui vont les exécuter alors qu'ils
ne connaissent pas les uns à

côté des autres sur le même os.
Et cette idée là qui déclenche

plein de problèmes dont on
pourra discuter et on pourra se

demander si on peut les résoudre.
Depuis les années 70,

régulièrement meurt parce que c'est
un concept technologique de mauvais

aloi et on en a vécu son sa dernière
occurrence avec l'apparition de

Docker et l'apparition de docker
lead directement à Kubernetes.

Alors je tout de suite rebondis
sur le moi.

Je prends l'autre côté du miroir
qui est si on ne le met pas sur

le même os.
Dans les années 70 et jusqu'à dans

les années 90, c'était on le met
sur des machines différentes,

voire on a peut être.
On avait peut être la

technologie du mainframe qui
était un peu dans le même temps,

on avait le même logiciel,
mais on a on a une ségrégation par

le hardware et qui n'est qui ne
pouvait exister que par le hardware.

Et cette ségrégation là,
à mesure de la montée en force,

en puissance du hardware, n'était
plus valide parce qu'on n'allait

pas ségrégué par le hardware.
Quant au hardware,

il y avait cinq GHz et 128 Go de RAM,
c'était pas possible.

Donc soit on faisait des micro
machines qui faisaient cinq cm,

soit on ségréguer de manière autre.
Autrement en 2003 t'avais pas

128 giga de RAM et laisser
l'apparition des VT instructions

poussé par Intel dans le CPU qui
te font une ségrégation hardware

tout ce que tu avais demandé.
Alors donc là justement c'est assez,

c'est assez marrant,
c'est que on s'est posé la

question tout à l'heure là dessus.
On connaît les entreprises qui

détestent les instructions VT et la
virtualisation, c'est à dire qu'en

fait elles sont dans le même posture,
c'est à dire qu'elles disent non,

nous on interdit la virtualisation,
mais complètement.

C'est un dogme absolu pour plein
de raisons qui peuvent avancer

typiquement la latence,
la latence, rajouter la pseudo

latence rajouter par par.
Alors tu vas m'expliquer d'où

vient la latence de la VT?
Je sens que ça va être très

intéressant. Alors alors.
Alors détrompe toi, je me suis battu

dans cette entreprise là dont tu
viens de boire, dont tu viens de

boire l'eau à l'heure actuelle.
Regardez le live,

c'est un dogme absolu dans cette
entreprise qui fait qu'on a déjà

installé des haproxy monocoeur
sur des 24 cœurs, 128 Go de RAM.

Je suis pas là pour écouter les
dogmes imbéciles de dos.

Mais justement moi en fait si tu
veux, la virtualisation a été

critiquée à une époque en disant elle
rajoute de la latence fine où est

ce qu'elle rajoute de la latence?
Ah mais c'est toujours les zayo zayo,

les Zayo network, les aïeux.
D'accord, donc on rajoute de l'IoT,

de la dépendance sur les IO.
Pourquoi est ce que ça rajoute

de la dépendance sur les IO?
Moi je pense que ça en rajoute même

pas si jamais on essaye l'apparat.
Non, non, non.

Mais posons une vraie question
pourquoi est ce que des choses

comme VirtualBox ou les premiers
VMware ajoutent de la dépendance

de temps sur les IO et le network?
Que c'était un hyperviseur pour tout

le monde qui passait et qui reprenait
tous les IO qui les centralise?

Et il rajoute ça,
il rajoutait une abstraction surtout.

C'est pas un problème d'abstraction,
l'abstraction n'a jamais posé de

problème, le CPU a toujours géré
très très bien la séparation des

OS qui ne se connaissent pas.
La racine si vous voulez sauver

votre vie dans le CPU pour ça,
c'est ce qu'on appelle les VM.

Exit la VM, exit.
Donc vous voyez les niveaux de

sécurité dans un CPU.
C'est le moment où globalement

tu sors de ton enclave sécurisé.
Quand on dit tu sors de ton enclave

sécurisé, c'est pas un problème,
c'est le moment où tu dois

parler au CPU pour avoir la main
sur autre chose.

Sauf que c'est très bien de pouvoir
booter un OS dans le CPU peinard et

de pas avoir d'overhead ou minimale.
D'abord parce que je sais pas

comment ça se passe dans vos infra,
mais moi le CPU est rarement bande,

on est tous bound par les algos
et rarement par le CPU.

J'ai pas dit que ça arrivait jamais,
j'ai dit que c'était beaucoup

moins souvent, surtout dans des
infra web où fondamentalement on

a des bases de données qui lisent
sur des disques durs et qui

répondent de HTTP sur le réseau.
Enfin, fondamentalement,

j'ai eu des CPU dans les trucs à
base de Cassandra Elasticsearch,

ils consomment du CPU, alors regarde
pourquoi il consomme du CPU.

En général, c'est lié à des
problèmes, mais ça peut arriver,

ça peut arriver.
Des fois tu as du calcul à faire dans

la vie, mais en général tes problèmes
de perf dans la vie c'est des algo.

Ce qui a rajouté des problèmes de
lenteur, c'est que pour être capable

de faire de la virtualisation, autant
le CPU, gérer la virtualisation,

autant le reste du hardware non.
C'est à dire que ton network,

je dirais pas la virtualisation.
C'est pour ça qu'Intel au début

avait imaginé que tu mettes un
CPU 30 cartes réseau dans TA dans

ta babasse et roulez jeunesse.
Tes disques durs ne gèrent pas

la virtualisation,
ton écran gère pas la virtualisation.

Personne d'autre ne gère la
virtualisation, ce qui fait qu'on a

créé ce qu'on appelle des couches
d'émulation où on faisait croire

qu'il y avait du matos et au début,
on faisait même croire qu'il y

avait du matos réel,
donc des Broadcom. Notamment.

Je sais pas si vous vous
souvenez de la grande époque où

on configuré les Nvidia pour que
ça émule un chipset Broadcom.

Et là évidemment, oui,
tu émule du d'électronique qui

n'existe pas, c'est lent sa race.
Sauf qu'entre temps, on a introduit

des drivers qui permettent d'utiliser
des instructions supplémentaires,

des instructions qui te permettent
d'avoir une communication directe

entre l'host et la virtualisation.
Maintenant, juste,

je voudrais qu'on soit très clair
sur cette histoire virtualisation

contre container à cet endroit là,
Tout, tout, tout les benchmarks

que j'ai vu à la grande époque
de l'apparition des containers.

Vous savez, les machines virtuelles
light sont des benchmarks qui ont

été faits en mode host, c'est à
dire sans aucune sécurité des IO.

Alors évidemment, tu es rapide.
Sauf qu'aujourd'hui,

si jamais tu fais un test de ta
sécurité des IO dans un mode où t'es

tout le monde dans le même OS et
on parlera des autres problèmes de

tout le monde dans le même OS, Tu es
obligé de le faire user Landside

donc avec une lenteur de check
délirante et en plus là absolument

pas soluble dans le hardware.
Donc tu la dépendance à l'IoT?

Oui, si tu la supprimes et que
tu dis en fait fuck la CPU.

Oui effectivement, je te confirme, tu
n'as plus de dépendance de problème,

mais si tu la réinstalle, t'es bien
baisé dessus quand même. Donc là.

Donc là, si on résume ton ton,
tu penses vraiment et c'est

d'ailleurs un argument qui se tient,
c'est à dire dépendre de la

sécurité du kernel,
de plein de fonctionnalités du

kernel pour segmenter les usages,
c'est quelque chose.

Là je viens juste de te dire que
c'est un problème de sécu, de perf,

que ton problème de perf était là.
On va parler ensuite des

problèmes d'isolation, de sécu,
mais c'est en fait elles sont liées.

En fait, c'est ce partage même du
conteneur parce que tu pourrais très

bien avoir des conteneurs qui n'ont
pas ce problème là potentiellement,

mais le fait même qu'elles
partagent un socle de base,

sinon c'est pas un conteneur.
Si jamais elles ne partagent pas

ce socle commun, cet OS en commun,
c'est plus du conteneur.

Donc là, si jamais je viens,
c'est donc ce grief là.

Et personnellement je l'entends
très bien, voir même plus que ça.

Je pense qu'en fait tout le monde est
d'accord avec toi pour une raison,

c'est que par exemple,
tous les cloud providers, il y en a

quasiment aucun on va dire aucun qui
propose du vrai conteneur de service,

c'est à dire qu'en fait elle te
donne une VM, c'est la tienne,

c'est pas celle d'à côté.
Cette VM est isolée via les

institutions.
C'est ce que font les autres

plateformes de services dans tout le
marché des plateformes de services.

Je suis le seul qui fait que de
la vertu dans tout le marché.

Ouais mais.
Mais en fait tous les autres le font.

En fait, si jamais demain même
j'installe un Kubernetes sur GCP,

tu me donnes des VM,
des VM que j'espère être isolé

via des instructions processeurs.
Donc en fait personne à l'heure

actuelle me donne accès à un
Kubernetes partagé.

Alors là c'est un problème de dogme,
de sécurité parce que du coup on

n'a pas parlé des vrais problèmes
de sécurité entre en engendre.

Mais admettons.
Partons sur cette histoire

d'isolation, je pense qu'on va dans
la sécurité alors que au final,

je voudrais juste qu'on parle de
cohabitation ou de partage de

ressources.
Parce qu'au final, aujourd'hui,

je suis développeur.
Les problématiques de sécurité.

Déjà de.
Les problématiques de dope en

général sont assez éloignées,
même si ce n'est pas volontaire,

les problématiques de sécurité
sont encore plus éloignées.

Je parle de pas dans la pratique,
c'est comme ça.

Moi ce que je veux comprendre
c'est qu'est ce que ça m'apporte

de faire du multi process versus
de la virtualisation versus du

container versus de la
virtualisation et du conteneur?

Enfin, aujourd'hui, ça a une valeur.
Tu disais tout à l'heure l'idée c'est

que les développeurs aillent vite et
je pense que la conteneurisation

et la VM isation ont en plus.
D'amener des problématiques de

sécurité, amener des problématiques
de l'instruction VT, etc.

d'Isolation.
Elles ont amené énormément de

flexibilité pour ces développeurs
là et je pense que c'est là la

force de ces choses là.
Et il faut parler de sécurité dans le

cadre de plateformes de services.
Mais quand on est dans une

entreprise, qu'on a ses serveurs,
qu'on n'est pas hébergé sur un cloud,

je suis désolé, mais quelle est
la différence entre faire du

multiprocess et faire du conteneur
ou faire de la virtualisation?

Et aujourd'hui il y en a, C'est
beaucoup plus compliqué de faire.

Du comment dire de la. Comment dire?
Je vais y arriver de faire de la

virtualisation versus c'est pour moi,
c'est en terme de complexité, c'est

number one en terme de complexité,
c'est de faire du conteneur

parce qu'aujourd'hui c'est peut
être trendy, mais aujourd'hui,

en deux clics, on y arrive.
Et en le plus simple c'est quand même

de faire du multi process et d'y
aller comme un dégueulasse sur son

serveur qu'on a installé à la main.
Voilà pour moi la valeur ajoutée,

elle est là.
Et les problématiques de plateforme

de hub pour qui parle Adobe,
c'est c'est pas un détail,

mais c'est pas ça qui fait driver.
C'est pas un détail, mais c'est

pour ça qu'il faut parler de cul.
Pourquoi il faut parler de cul?

On peut parler de plein de choses sur
la mutualisation des ressources,

mais parlons en de façon simple tu
fais, tu lances plein de process,

tu as un react dans un coin et
tu as ton serveur Php-fpm,

ton React prend plein d'écriture,
il va exploser son nombre de ulimit.

Ton serveur Php-fpm ne sera plus
capable de répondre une fois de

temps en temps à des requêtes parce
qu'il a pété le nombre de ulimit.

Parce que ça c'est ça.
C'est une limite qui ne devrait

pas être partagée entre ces deux
applications là.

Elles devraient même pas savoir
qu'elles existent l'une l'autre.

Prenons un autre problème de
ressources partagées.

Non mais on illustre,
c'est très bien.

Tu as une application qui qui fait
dans le qui fait du chiffrement.

Donc en fait elle va t'épuiser
l'acide d'entropie de ta machine.

Et comme l'acide d'entropie,
elle est partagée avec tout le monde,

ça veut dire que toute l'entropie
de tous les autres trucs qui va

être utilisée en chiffrement sur
la totalité de la machine est

épuisée et donc t'as plus de sécu.
Cela dit, à l'époque,

il y a longtemps parce qu'il y a
longtemps, on n'avait pas les

capacités CPU d'aujourd'hui,
on avait des circuits hardware

dédiés à la génération d'entropie.
Ça existe encore, il faut le

configurer, ça existe encore,
je suis désolé et on devrait être

capable, même dans le cadre de VM et
même dans le cadre de conteneurs,

de pouvoir configurer des
machines spécifiquement dédiées

à la génération l'entropie de
l'entropie dans les VM.

C'est un énorme,
c'est un énorme sujet.

Par exemple, c'est un sujet beaucoup
moins lourd que dans le même OS.

Alors pour le coup,
je me souviens plus à quel moment,

mais il y avait des VM pendant
un temps qui n'était incapable

de booter parce que juste elles
attendaient le ssh de lancement

et il avait une faille Debian.
On peut faire notre vie entière à

parler d'une faille Debian moi,
moi, moi je parle plus,

je tire sur une ambulance.
C'était pas la faille Debian.

Je vois très bien le truc où en
fait les nombres étaient même pas.

Je te parle même sur l'exemple
que tu me donnes n'est pas n'est

pas lié à des gens qui faisaient
des choses bien.

Il se trouve que Debian a manipulé
l'entropie plein de fois et ça a

donné plein de plein de trucs chelous
parce que pendant longtemps ils

ont cru qu'il fallait augmenter
la rapidité de génération

d'entropie et donc effectivement
il y a des problèmes sur du SSH.

Néanmoins, là ce n'était pas un
problème de VM, c'était un problème

de driver. En fait si tu veux.
Le problème c'est que les gens

confondent les problèmes de VM,
donc du VM exec dans le CPU avec

les problèmes de drivers,
de l'encapsulage de la machine,

le VM, ce qu'on appelle le VM,
c'est un problème fondamental

que vous devez décorréler.
Est ce qu'il peut y avoir un

problème dans vos drivers? Oui.
Est ce que c'est pour ça qu'il

faut compiler vous même les
hyperviseurs de façon à réduire vos

surfaces d'exposition? Oui aussi.
C'est pas parce qu'il y a plein de

gens qui font n'importe quoi qu'une
technologie est mauvaise sinon.

Enfin, le web entier serait pourri.
On faisait tous du frontpage à

l'époque, tu vois,
c'est c'est un problème.

Si tu veux, à un moment faut regarder
les choses de façon rationnelle.

Quand je te dis il y a un problème
avec les containers, je ne te dis pas

qu'il y a un problème dans l'absolu.
Il y a des cas d'usage où c'est

très cool.
Les containers, tout Macias,

ils tournent sur Container.
Le premier cloud public ever à avoir

proposé du docker, c'est Clevercloud.
On est une des seules boites

dans le monde à packager Docker.
Il y a nous, RedHat et Docker

donc c'est pas compliqué,
on passe notre temps à faire ça.

On s'est engueulé un nombre de
fois incroyable avec les

mainteneurs parce qu'on sentait
bien qu'on était dans les rares à

compiler le bordel. Hormis eux.
La liste des options du kernel

qu'il faut pour compiler pour faire
fonctionner Docker sur un truc,

ça sort de chez nous, donc on connaît
particulièrement bien ce bordel.

On te dit il y a plusieurs problèmes,
il y a un problème d'entropie,

on peut parler de tous les
autres problèmes d'entropie qui

ont été liés.
Il y a un truc qui est sûr,

c'est que si tu fais du conteneur,
tu auras des problèmes d'entropie.

Tu as un problème de ressources
limitées non mutualisables qui

se retrouve mutualisé.
Donc là je te citais les limites,

mais en vrai il y en a plein
d'autres des ressources limitées

non mutualisables que tu peux avoir
parce que c'est un autre problème.

Après tu as un problème d'isolation.
Ton problème d'isolation,

il est statistique.
Il y a 430 failles du kernel

annuellement,
il y en a à peu près 30 annuels qui

sont des élévations de privilèges.
C'est à dire que tu étais pas root,

tu deviens root, ce qui veut
dire que tu as conteneur EPC.

Bon, il y a 52 semaines dans l'année,
il y en a 30 pendant lesquelles

tu es condamné. Fais ton choix.
KVM Deux failles en dix ans,

il y a une des deux failles.
La première, j'étais même pas

concernée tellement c'est vieux.
La première dont je me souviens,

c'est une faille dans le driver
d'émulation de disquettes trois

pouces et demi.
Alors je sais que le web entier

s'est enflammé parce que tout le
monde utilise des des distrib

dans lequel tout est compilé.
Mais enfin moi ça m'a pas touché.

C'était pas compiler le driver de
compiler, d'émulation de disquettes

trois pouces et demi parce que ça
n'a rien à foutre en prod chez moi.

Donc si tu veux un pur point de
vue statistique, tu admettras

qu'il y a un problème d'isolation.
Alors je suis entièrement d'accord

avec toi et mieux que ça encore,
c'est que j'adore la virtualisation.

Enfin pour avoir été chez
Cloudwatt et avoir fait de

l'open stack sur du KVM etc.
Et même avant avoir des infras

très très lourdes sur du KVM,
le cumul leadworth, le machin etc.

J'en ai bouffé et j'adore ça.
C'est peut être un truc que les gens

crachent beaucoup sur OpenStack même
il a énormément de problèmes, mais il

a répondu à énormément de soucis et
je pense même maintenant peut être

parce qu'on va revenir là dedans.
C'est bien que tu aies parlé de

conteneurs, mais c'est que moi,
par exemple, je pense que donc la

dépendance au choix dont on parlait,
c'est que je ne vois pas

Kubernetes sans la virtualisation.
Qu'est ce que ça veut dire pour moi?

Et ça va être la définition que je
vais dire, c'est que Kubernetes

n'est pas un casse, ce n'est pas un
conteneur de service, il ne fait.

Il a même une notion de conteneur,
à mon sens que très lointaine.

C'est avant tout un manager
d'infrastructures.

Il doit se reposer sur des
ressources.

D'ailleurs,
il gère des ressources humaines.

Aujourd'hui,
il lance des conteneurs alors

même pas utilise les conteneurs,
je vais dire pour son exécution.

Alors depuis, c'est un outil.
Même pas, même pas depuis hier,

j'ai vu qu'il y avait un kubelet
codé en Rust qui fait du.

C'est un Toy project.
Il y a d'autres trucs Microsoft qui

a pondu le virtual Kubelet qui te
permet de prendre l'API de Kubelet

et de lancer plein d'autres trucs.
Et c'est comme à chaque fois il

se branche à des casses pour des
pures casses.

Non, je pensais même par exemple à
Kata container kata container pour

le coup, qui lance, qui utilise
des instructions VT en fait.

Donc pour ça il lance des micro VM
basée sur le projet Clear Linux et à

l'intérieur de ce micro kernel donc
qui pour le coup là est émulé avec et

utilise des instructions VT via KVM à
l'intérieur de ce micro kernel Linux,

il va spawner un conteneur.
Donc en fait on a toujours la

primitive de conteneur mais isolée
hardwarement pour le coup, si jamais

ce mot existe matériellement est
peut être meilleur d'ailleurs.

En effet, matériellement par par
les instructions BT.

Et c'est très bien que tu en parles
parce que ça va me permettre de

parler des autres problèmes avec
les conteneurs, parce qu'à chaque

fois on parle de l'isolation.
Moi je pense que c'est une

connerie de faire de l'isolation.
Juste un point sur l'isolation et sur

le fait que tu es dans la même boîte.
Du coup on se fait confiance.

Ça c'est un truc simple.
On a écrit un article il y a

très longtemps chez Clevercloud
qui s'appelle Mettre fin à la

métaphore de la forteresse.
Si tu considères que faire de la

sécu, c'est que si on est tous
copains, alors on se connaît et

on peut se toucher les couilles.
C'est ton problème.

Tu vois, moi je touche pas les
couilles de mes collègues de travail.

C'est la même chose dans tout le
coin en fait, à un moment donné, la

sécurité, ça se fait en profondeur.
Si tu as quelqu'un qui a un

logiciel au hasard,
tu es dans une grosse boite.

Il y a un progiciel moisi dans
un coin qui se fait attaquer,

démonté et pris en pris en attaque.
A partir du moment où il est

corrompu, s'il est sur la même
bécane que les autres,

il tue les autres, il est corrompu.
Ça, pour moi, c'est un drame.

Donc en défense, en profondeur,
l'argument du oui mais on est

entre nous et pas entre tierce.
Dès que le nous commence à être plus

de quatre, il y a un vrai problème
de sécu et il y a un problème

d'exigence vis à vis de la sécurité.
Je suis entièrement d'accord

avec toi et c'est d'ailleurs un
combat que j'ai eu dans beaucoup

de missions que j'ai.
C'est que moi par exemple,

je déteste avoir un cubain
partagé même entre des équipes,

un cubain, une équipe.
On viendra ensuite à Kubernetes

si ça te va.
On peut parler d'un autre

problème des conteneurs qui est
un problème fondamental.

Aujourd'hui un conteneur Linux,
c'est quoi?

C'est un gros paquet de binaires.
Un zip layer, mais c'est un zip que

tu partages dans lequel il y a tout
ton OS sauf Tooth in the kernel. Ok.

Fin moi j'aimerais comprendre
pourquoi on m'explique que c'est

plus safe d'avoir des versions.
De Spring Boot,

par exemple Spring Boot.
Je rappelle le framework qui a

été testé sur toutes les
versions de Java dans un sens.

Dans un autre en haut de la VM de
Chirac à la GM de chez Oracle.

La totale.
Et d'avoir des dépendances non

testées de la j'ellipse.
Et du kernel ensemble.

Ou pire, une dépendance jamais testé,
des combinaisons non testées ou

ce n'est même plus une ellipse
de mec qu'on remplace.

La GSC part en se disant ça va
être cool.

Et qui ensuite me disent c'est
plus fiable ce que vous croyez.

Quoi que les développeurs de la GTM,
ils font leur taf avec Musl ou

avec Eclipse?
Alors encore une fois,

j'invoque le miroir magique qui dit
je prends le revers du miroir et

le revers du miroir, c'est quoi?
Parce que j'ai l'impression que tu tu

prends tous les problèmes et que
tu les analyses avec le spectre,

avec ton analyseur sécurité.
Moi je prends l'analyseur

développement,
je prends l'analyseur feature et

je suis désolé mais justement,
gérer les dépendances en local,

c'était une hérésie.
Ça a été pendant 20 ans une hérésie

pendant 40 ans, une hérésie.
J'ai jamais géré Gérer les

dépendances en local.
Attends, attends, il y a une

différence entre si on prend tous les
binaires, on en fait un gros nœud

autour et qu'on les frappe sur le
serveur et qu'on les bisous pas.

Gérer les différentes versions
de l'IP, c'est les différentes

versions de Python, les différentes
versions de tout ce que tu veux.

Je te dis que c'est une catastrophe.
Une erreur, ça s'appelle Debian,

ça s'appelle.
Voilà, c'est tout ce que tu veux,

mais c'est ta défonce aujourd'hui,
nous, on n'a pas ce souci là.

Chez nous, on met à jour des
milliers de machines sans que

personne s'en rende compte.
C'était une réponse et je pense

que c'était une bonne réponse.
Que ce soit la virtualisation ou

la conteneurisation, ça dépend,
ça dépend en fait, tu mets en place

des versions non testées de trucs
qui sont beaucoup plus majeurs.

Donc là j'ai flippé, tout le monde
voit à quoi ça sert la glibc ou pas.

Vas y, explique,
parce qu'on a des gens qui.

Donc la glibc, ce qu'on appelle la
librairie standard, c'est c'est le

truc qui globalement va plus ou
moins, quel que soit le langage

dans lequel vous allez parler.
Sauvegarde, ça dépend qui compile

en fonction de comment il compile.
Voilà, pour rappel, vous avez une

dépendance à J'ellipse très souvent
et tout ceux qui ont fait un from

scratch avec un binaire GO le savent,
ils ont pas bien compilé.

C'est l'évocation du fait que go
clame ne pas en avoir.

On pourra avoir plein de discussions
sur Go après, mais si vous voulez la

dépendance à IPC, donc la glibc,
cette librairie standard,

c'est celle dont vous allez vous
servir pour faire essentiellement ce

qu'on appelle les appels systèmes,
donc les appels systèmes, c'est Je

voudrais écrire sur un fichier.
En fait,

quand vous écrivez sur un fichier,
ça n'est pas votre programme qui

sait comment écrire sur un fichier.
Vous ne savez pas comment c'est fait.

Vous êtes peut être sur Windows,
peut être sous Linux.

Donc voilà, si vous êtes sur un
Linux, vous êtes peut être sur

du btrfs, peut être sur de Xt4,
peut être sur de l'overlay FS.

Enfin,
je vous laisse aller constater la

quantité de FS disponible en Linux.
Vous ne savez pas écrire sur sur

le fichier,
donc votre programme ne sait pas.

En général,
il rappe quelque part dans les

profondeurs de ses dépendances,
il frappe la glibc et la glibc.

Elle même ne sait pas en fait
écrire sur le sur le sur le disque

dur ce que sait faire la glibc,
c'est un appel système qui lui va

écrire sur le disque dur parce que le
kernel, lui, sait comment il a été

configuré et comment il fonctionne.
La Gillipsie va gérer vos

dépenses au réseau, gérer vos
dépenses à tout le hardware.

Elle va gérer vos dépenses au temps.
Bref, tous les petits sujets en

informatique tels que écrire de
la donnée, parler sur le réseau,

savoir quelle heure il est.
Les trucs pas important de

l'informatique, ce qui veut dire
très simple, toujours très simple.

Depuis le début, on sait faire.
Et on rappellera que pour l'anecdote,

le premier version de Linux qui est
sortie le plus grosse partie du code,

c'était juste afficher la date.
Je crois juste la calculer.

C'est c'est chiant, c'est le
truc le plus infâme du monde.

Et imaginez quand on ira sur Mars.
Et du coup, si vous voulez, le boulot

de la gillipsie dans l'opération,
c'est de faire ces appels là.

Ce qui veut dire qu'en fait
votre gillipsie et votre kernel,

ils sont excessivement proches.
Evidemment, la gillipsie est

codé avec un nombre de garde
fous incroyable pour essayer de

ne pas spammer dans le kernel.
Et le kernel a lui même des

gardes fous.
Par contre ces gardes fous, en fait

ils vous font perdre du temps, ils
vous font perdre énormément de temps,

donc ne pas les employer bien.
Et par ailleurs, il y a des bugs dans

la gillipsie, il y a eu des soucis.
Alors il y a une grande spécialité

de Debian qui est de rester six
versions en retard de la gillipsie

en se disant que celle là était
bien battletech comme ça.

Il y a des erreurs qu'avait
quatre ans qui ont été corrigées

il y a quatre ans,
qui sont découverts à un moment,

souvent en se disant mais pourquoi
vous n'avez pas mis à jour?

Parce que nous, on aime bien les
vieilles versions bien stables.

Donc voilà.
Et par ailleurs, il y a des gens

qui ont décidé que la gx7 est mal
écrite et qui l'ont intégralement

réécrit. Ça s'appelle Muzzle.
Enfin, il y a plusieurs.

Il y a Micro Ellipsis qui a été
plutôt pensé pour de l'embarqué,

donc l'idée était de dire on fait
une toute petite JPC pour des cas

d'usage spécifiques Damzel qui est
même pas binairement compatible.

Mais il faut de toute façon tout
recompiler qui n'est pas du tout

foutu pareil et surtout qui est
codé par deux mecs.

Qu'on soit très clair sur la
situation.

La Gillipsie,
c'est un code patrimonial de

l'informatique mondiale qui date
des années 70 avec des tests,

des gens qui ont bossé dessus.
Muzzle c'est une blague?

D'accord, D'un point de vue
gestion de projet, tu as deux

gus dans un garage qui codent ce
truc et donc on te dit on va tous

utiliser Alpine, Linux, Alpine,
Linux Racing, c'est quoi Muzzle?

Donc on va se retrouver avec un
truc où on dit on va lancer MySQL,

MySQL, il fait quoi?
Il parle sur le réseau, il parle

au disque dur, il passe son temps
à faire des appels à JPC qui elle

même fait des appels sur le kernel.
Et donc on va utiliser quoi?

Un truc avec lequel les gens qui
font MySQL n'ont jamais rien

testé et on va te prétendre que
c'est beaucoup plus sec parce

que tu comprends du MacBook Pro,
du développeur à la prod,

c'est le même binaire.
Et maintenant, posons nous la

question est ce une bonne idée?
Je n'ai jamais vu qu'on prônait,

c'était safe,
on disait que c'était pas unsafe.

Ce qui est différent de dire c'est
safe, mais surtout les avantages.

Enfin,
c'est comme n'importe quel choix,

il y a un coût, je sais plus comment
on appelle ça bénéfice risque.

Aujourd'hui, on prend sa voiture.
On a décidé de manière sociale

que prendre sa voiture,
c'était bien. Pourquoi?

Parce que le bénéfice de prendre la
voiture était largement supérieur,

au risque de se planter en
bagnole et que rouler à 130,

c'était à peu près là, alors qu'on
sait tous que tout le monde va mourir

à 130 si jamais il y a un accident,
tout le monde va mourir à 130.

C'est pas grave, mais c'est un
médicament, c'est un bénéfice risque.

C'est mais c'est bien,
mais c'est bien, c'est bien.

Par contre,
le bénéfice risque sociologique.

Enfin moi je vous parle de
comparer des technologies,

c'est un bénéfice des technologies.
On doit, on doit,

on doit voir leur capacité.
Au delà de ça,

je te dis ça c'est un major Flow.
Le deuxième meilleur flow du truc,

il est simple, ça veut dire que
tous les binaires que tu compiles,

comme tu n'as aucune idée de
comment ils vont être exploités,

bah en fait tu compiles les binaires
les plus open possibles, c'est à dire

que ça doit marcher d'une GameCube.
À l'émulation un peu cradingue que tu

as sur Mac. Je te suis? Mais non.
Non mais c'est un vrai souci,

c'est tout.
Ce que tu compiles,

c'est toutes les options puisque
tu ne sais pas ce que tu pourrais

avoir besoin d'avoir accès.
Donc du coup, tu compiles le

fameux driver du disquette trois
pouces et demi. Tu vois.

Alors que fondamentalement,
aujourd'hui emprunte sur un cloud,

ça devrait pas être là.
Tu compiles sans utiliser aucune

spécification de ton processeur.
La plupart des images docker

aujourd'hui,
je les fais tourner sans aucune

discussion sur le Athlon XP moisi
que j'avais quand j'étais au lycée.

Et ça, ça veut dire que bonjour,
que tous les mecs d'Intel qui

bossent en R&D, ils ont rien branlé.
Ces quinze dernières années, il n'y a

jamais eu de nouvelles instructions,
il n'y a jamais eu rien.

Je paye mes processeurs 1 600 $
pièce pour le plaisir de me servir

de trucs qui en fait pourrait
être fait il y a quinze ans.

Parce que je ne lis pas les
changelog Intel, je ne lis pas

les changelog du kernel,
je ne lis pas tous ces trucs là.

Donc si tu veux,
j'ai eu une bonne idée là dessus.

Effectivement,
tu dis il y a un bénéfice.

Moi ce que je te dis,
dans un monde où on parle d'écologie,

moi je te parle de 30 35 % de
perf à gagner juste en changeant

ton fichier de configuration.
Et là je ne t'ai pas parlé des

problèmes sécuritaires parce qu'un
kernel banane Ubuntu full ouvert,

ça fait 360 mégas avec l'activation
en plus des modules qui est à

peu près 50 % des failles de
sécurité graves du kernel si on

en suit l'accidentologie de ces
dix dernières années.

Un kernel chez Clevercloud,
ça fait un mega deux.

Donc ça veut dire qu'il y a du
code qui n'est pas là.

Ça veut dire qu'on a nettoyé les
choses.

Ça veut dire qu'on n'est pas en
train de faire n'importe quoi.

Donc si tu veux, il y a un moment,
quand tu parles de bénéfice risque,

je te dis mais il n'y a pas de
problème.

Parlons des bénéfices cachés.
C'est pas parce qu'on a mis

l'accent unique sur certains
points en marketing qu'on ne

peut pas parler des autres.
Alors alors tu es d'accord avec

moi que tu pourrais très bien même
checker Cloud et d'ailleurs vous

le faites et ce serait tant mieux,
parce que c'est en fait le sujet

dont tu viens de parler de cette
optimisation des processeurs pour

être un gros lecteur de Phoronix.
On va essayer de le prononcer comme

ça. J'ai jamais su la prononciation.
C'est un sujet que j'ai beaucoup et

c'est d'ailleurs ma plus grande,
mon plus grand grief envers Debian,

Ubuntu et tous ces paquets là où en
fait tout est compilé complètement

avec des options arriérées comme tu,
comme tu le disais, arriéré dans

le sens elles sont pas merdiques,
c'est juste elles sont très vieilles

et avec des options très très parce
qu'il faut une volonté universaliste

et vous pouvez reprendre votre PC de
98 et installer Ubuntu, ça marchera.

Donc en gros, en fait le truc c'est
que les conteneurs n'ont ni changé.

En fait non pas changé l'ordre
établi, c'est à dire que les gens qui

sont passés avant d'une distribution
d'un PC et une babasse installée

avec une Debian et je te mets un jar
dans les dents et ça doit marcher.

Ils sont passés à des conteneurs.
En fait, ça n'a rien changé pour eux.

Est ce que ça a changé?
Par contre pour eux, c'est le

format de déploiement d'artefacts.
Par contre là où je suis d'accord par

contre, du coup, ça n'a rien changé.
En fait, si tu veux, à un moment,

quand tu regardes une technologie,
il faut regarder ce qu'elle apporte

et ce qu'elle aurait pu apporter.
Le format de packaging applicatif, le

fait de dire on va faire ça parce que
du coup on fait un format binaire.

Donc si tu veux un format binaire,
enfin, c'est quand même pas à

vous que je vais apprendre que
de faire des formats binaires,

c'est une sale idée.
Enfin, on a toute l'expérience

de Microsoft Word, de BMP,
ça fait un moment qu'on est sur les

formats binaires et le fait que bon,
pour finir, c'est quand même pas

si pratique que ça,
et ben là c'est la même.

Et je suis désolé,
je reçois des calls pendant le live,

c'est très chiant, les gens ne
regardent pas ou alors ils ont

voulu dire de parler très bien.
Donc en fait le format, le format

binaire ici pose un problème.
Il pose plusieurs problèmes en fait.

Ton premier problème c'est
effectivement la non

optimisation des binaires et du
coup ça la grave dans le marbre.

Le second problème, ça pose un
problème de portabilité maximale,

c'est à dire qu'on dit à partir de
maintenant, toutes les applications

ne fonctionneront que sur du 386 ish,
peut être 86 sur 64 sous Linux,

mais on n'a pas réglé le
problème de portabilité.

Aujourd'hui, nous on a réglé nos
problèmes de portabilité avec un

format sémantique qu'en plus on
plante au jouant en loto,

en loto afférents parce qu'on sait
que les gens ne veulent pas écouter.

Notre format redéfinit portabilité
parce que c'est à dire que tu

prends ton application et tu peux
la faire tourner sur autre chose,

sur un Raspberry, sur un PC,
sur un autre OS, sur sur une autre

architecture logicielle quoi.
Donc ouais, c'est un objectif,

moi c'est pas mon objectif.
Quand on dit on va vous fournir un

truc qui package définitivement
les applications parce que ce

sera portable, C'est parti.
Je n'ai jamais entendu une partie de

la page d'accueil dans l'argumentaire
Docker, mais alors justement,

c'est lui, il l'a dit par ailleurs.
Non, non mais non mais non,

mais c'est vrai!
Et pourtant dans les faits,

c'est pas un objectif en soi.
Non mais pour prendre ton

exemple des Raspberry Pi,
et ben moi je suis désolé mais les

conteneurs c'est génial parce que
justement ça m'a permis d'avoir plein

de logiciels compilés en arm64.
Alors ok, il y a eu le problème

des armes achevées.
Est ce que HF est ce que est ce

que j'ai des intrusions par 64?
Oui, voilà.

Et ça c'est un problème de des
connards de chez ARM qui ne

savent pas faire.
Enfin personne, plutôt les

constructeurs de processeurs qui
font de la merde avec.

Est ce que je t'ai les
instructions de néon ou pas, etc.

Bref, connard de chez Nvidia qui
ont fait qui ont fait ça et.

Et en gros, le truc c'est que
quand même le format docker a plus

popularisé des architectures type
Arm64 et je suis sûr d'ailleurs

que Sfiv pourra aussi devenir
populaire parce que justement je

pense qu'il faut encore une fois,
il faut regarder ce que ça a apporté.

Je termine mon conteneur,
Il n'est pas porté, s'il vous plaît.

Alors bon, l'avantage c'est que
justement, par cette multiplication,

cette facilitation d'utilisation de
plateforme un petit peu orthodoxe,

pas orthodoxe justement, le Tooling a
pu évoluer et fournir typiquement

des docker multi-plateforme,
enfin des images multi-plateformes,

multi-plateformes.
Alors voilà, c'est le tu peux pousser

un truc qui a le même nom et qui dit
que tu fais du multi-plateforme.

Tu n'as plusieurs images qui sont
multi-plateformes mais qui n'ont

aucun lien entre elles. Exactement.
Mais c'est pas grave, mais ça veut

dire que le packaging que tu fournis,
ça veut dire que le format que tu

fournis, le tout n'est pas capable
de le gérer intrinsèquement.

Mais c'est mal, c'est mal.
L'universalité, enfin l'universalité

absolue dans le discours,
dans le discours, dit au début,

mais en fait, en fait,
en gros c'est tu peux me dire ok,

c'est pas grave, c'est une figure.
Bon, il y en a qui l'ont vendue,

moi pas,
mais du coup on s'en bat les steaks.

Très bien, c'est des sacs de
pommes de table, on est d'accord

que c'est pas portable le Hello
World Python, il va tourner

partout pareil le Hello World.
C'est le cas aussi des

conteneurs des conteneurs.
Essayez de faire un conteneur

qui tourne sous Windows et vous
verrez un peu la galère que c'est.

C'est c'est c'est pas un
objectif en soi.

Je veux dire, c'est peut être un
objectif, c'est peut être pas un

objectif dans le monde, Non non,
c'est pas un objectif de trois

pecnos je vais dire Qui ça?
La portabilité des formats

applicatifs, la portabilité des
formats applicatifs, ça intéresse

tous les éditeurs aujourd'hui.
Tu t'appelles pas Elasticsearch?

Un format compatible avec tout
ça t'intéresserait?

Aujourd'hui, tu te retrouves à
faire X conteneurs, alors quand

tu as des moyens, why not?
Mais en fait, ça n'a pas réglé

ce problème là, c'est tout.
En fait, c'est encore une fois,

je ne sais pas.
En fait, si tu veux,

tu me demandes c'est quoi que tu
reproches à cette techno? Je te dis.

J'ai l'impression que tu
reproches beaucoup de choses qui

sont que tu dis.
Ils disent ça, ils veulent faire ça,

mais ils ne le font pas.
Du coup ça pose un problème.

Tu vas me dire, moi l'intérêt que je
vois au conteneur beaucoup et qui

en fait est en lien, peut être ça
pourrait ressembler à la portabilité,

mais en fait ça l'est pas pour moi.
Moi c'est la reproductibilité,

c'est reproductible en fait,
via l'immutabilité justement,

ça veut dire quoi immutable?
En fait, le fait que toutes mes

dépendances, à un moment donné,
soient contenues dans un package,

quelle que soit la façon dont je
l'ai fait.

D'ailleurs, je ne suis pas très
fan du Dockerfile, je parle

vraiment d'un concept très vaste.
On parlera du layer après qui

pose un autre problème en fait.
Mais mais c'est pas reproductible

puisque tu exécute un script, le
script va chercher des trucs qui sont

posés sur les repo et t'as aucune
putain d'idée de ce que moi je parle.

Justement, ça dépend du script.
Moi je parle vraiment du format

d'image.
Okf Oui normalement c'est ça,

je dis voilà, je te donne.
J'ai fait il y a dix ans un format

d'image normalement. Et alors?
C'est vrai que par contre tu poses

le problème de la l'eapc avec le
kernel et c'est un vrai problème

mais qui arrive très peu souvent.
J'ai plus de problème de temps

entre mon paquet python et le
python que j'ai maintenant avec

un autre paquet etc.
En termes de statistiques,

pour le coup, bah ça m'arrive
plus souvent un problème avec

Python qu'avec les statistiques.
On a besoin de grands nombres et

du coup ton expérience personnelle
n'est pas une nécessité.

C'est pour ça que j'ai dit moi
et je le dis je.

Bien sûr, quand on parle et on
est tous d'accord avec soi,

on est ultra biaisé parce qu'on se
connaît que nous et les gens qui

nous entourent et les gens qui nous
entourent nous ressemblent trop.

C'est clairement un problème.
Mais en gros, moi ce que je vois à

l'heure actuelle dans ce format là,
ce format a plein de problèmes,

mais il en a beaucoup moins que
les autres formats.

Simscript Ah non non non.
La différence entre un Dockerfile

et un chef, c'est que avant chaque
commande tu as mis run en majuscule.

Mais fondamentalement,
on est entièrement d'accord,

on a besoin de rien.
Non non non non mais moi je parle pas

de doc, je parle du format de sortie,
c'est à dire ce truc que tu

pourrais faire avec le binaire,
tu pourrais faire avec.

Donc cet artéfact qui est la
représentation de ton application,

c'est pas une représentation,
c'est un binaire,

mais il a besoin du kernel,
donc en fait il est, il a en fait

en gros on a juste descendu avant
je te donnais juste un binaire et

après c'est à toi de faire tout.
Après je t'ai donné un accord.

Sauf que.
Sauf que si tu veux aujourd'hui

ta reproductibilité ou tout ce
que tu veux d'autre.

Si aujourd'hui je te supprime le
Dockerfile qui en lisant en plus

comme aujourd'hui, le format a été
pensé de telle façon qu'on est obligé

de mettre du double ordre un peu
partout et c'est un peu pénible.

Mais en le lisant, tu es capable
de comprendre globalement ce que

le mec essaye de faire.
Si aujourd'hui tu prends juste

le truc et que tu te dis bah ça
fait quoi cette appli?

Ta seule solution c'est de monter
le filesystem et de introspecter,

c'est à dire que tu es dans un
binaire, tu n'as aucune idée et ce

n'est pas un format sémantique.
La différence entre le

sémantique et le binaire en
informatique est très simple.

Tu peux descendre du binaire quand
tu viens du sémantique et par

contre quand tu es dans le binaire,
tu es bloqué et ta seule solution

c'est de passer du machine
learning dessus pour essayer de

comprendre ce qui se passe.
Je sais, la seule chose à laquelle

j'en suis réduit aujourd'hui pour
essayer de gérer ce problème là.

À l'époque où Docker est apparu,
il y avait des réflexions pour

créer des formats sémantiques.
Et en fait, si tu veux,

l'apparition de ces choses là a
tué toutes ces réflexions là à

cause de l'overhaul marketing.
Alors après tu peux me dire

c'est pas grave, je te dis,
c'est un problème, il voulait le

régler, ils l'ont pas réglé.
Tu peux me dire on s'en fout

très bien, on s'en fout,
c'est un problème.

Le deuxième problème,
c'est le format de layers qui sur

le coup paraissait très malin.
La réalité,

c'est qu'aujourd'hui tu prends les
100 images les plus downloader du

docker hub et Sneak te dit il y a
au moins 30 failles dedans et pas

des petites genre Ghost Puddle,
enfin des trucs genre toutes tes

data à poil sur internet quoi.
Vraiment un truc violent.

Et ça à mettre à jour, c'est hyper
pénible parce que le système de

cascading n'a jamais été pensé pour
penser à des mises à jour qui soient

faites par des hommes. Pourquoi?
Parce que Docker n'a pas fonctionné,

Parce qu'il permettait de faire
mieux.

La prod Docker a fonctionné parce
que ce qu'il promettait aux devs,

c'est d'aller faire chier les ops.
Tu veux pas me mettre à jour mes

technos?
Et bien très bien, je vais donner

un run et tu vas l'exécuter.
Et c'était le cas et comme moi

j'en ai rien à foutre et bah moi
je sais pas faire de la mise à

jour on s'en tape et donc on
aura des binaires pas à jour,

pas compilé pour tagadatsointsoin.
Parce que de l'autre côté je gère

une infra aujourd'hui où on n'a
que des binaires à jour, que des

binaires optimisés pour chaque
profil d'architecture qu'on fait.

Et à ma connaissance,
on est dans les rares à faire ça.

Après je te confirme, on est dans
notre coin et comme d'hab on est dans

notre coin et tout le monde nous
regarde avec des grands yeux Quand on

dit qu'on fait une seule grosse base.
Tu l'as dit, tu l'as dit toi même,

vous êtes les seuls.
Et en fait, à l'heure actuelle, oui,

cette technologie de conteneurs,
elle a plein de problèmes et je

pense qu'on était dans les dans
les tout débuts de Docker.

Et oui, à chaque fois on se regardait
en se disant mais pourquoi?

Mais en fait en vrai, elle a quand
même répondu à des problèmes,

elle y a peut être mal répondu
ou elle aurait pu faire mieux.

Comme elle a répondu à une
question managériale qui était

une question de mal management
des équipes qui permettait à une

équipe qui aujourd'hui a la main,
parce que c'est très simple,

les boîtes, elles ont besoin
d'évoluer très vite leur soft.

C'est pour ça que moi,
la composante CentOS, je me la suis

tapée dans plein de boîtes et je me
la tape encore dans plein de boîtes.

Et donc oui,
mais c'est ça un problème,

c'est un problème de management,
C'est pas un problème technique, mais

ça me semble entièrement d'accord.
Et en fait, en gros,

je pense que en fait,
ce que tu ce que tu es en train de

dire et ce que je pense concrètement,
c'est que vous êtes sans doute

demain il va y avoir un merge et
c'est là la notion de je pense,

de linéarité dans ce combat,
dans ce combat, c'est qu'à l'heure

actuelle on a pu avoir une espèce
de patch qui nous a permis, là,

de tenir dix ans de plus et que
demain, en effet, basé sur cette

technologie là, on a perdu des
années à faire des technologies qui,

du coup posent des soucis,
ça a réglé des problèmes,

mais ça en générant plein d'autres.
Et moi, si tu veux.

Ce qui m'énerve dans cette situation
là, c'est que tous les problèmes que

ça génère au moment où c'est apparu,
les ingénieurs systèmes ont tous

dit ça pose un souci quand même et
personne ne les a écoutés, ça oui,

mais ça en a résolu beaucoup plus.
Nous, on était, on était dans ce

cadre là, à ce moment là,
ça n'a pas résolu, etc.

En chef, c'est on on a fait,
on est vraiment là dedans.

Il faut vraiment se remettre
dans le contexte,

c'est ça répond à un vrai besoin,
c'est et en plus, et en plus cette

technologie n'est pas orthogonale.
C'est vrai qu'elle a permis de

ne pas se poser certaines
questions comme tu le dis,

mais elle est pas orthogonale.
C'est à dire que même maintenant

avec des conteneurs, on peut
faire des conteneurs sécurisés.

C'est possible, C'est peut être plus
compliqué, mais c'est possible.

Mais ce n'est même pas plus
compliqué qu'avant.

Oui, en recompilant soi même par
exemple, c'est c'est, c'est ces

conteneurs ou en n'utilisant pas
docker par un système de layer en

supprimant. Mais moi je déteste.
Enfin je sais pas ce que tu es

en train de me dire.
On est en train, on est capable de

générer des binaires, de les mettre
dans un zip et de se les envoyer.

Oui ça je suis d'accord avec toi.
Mais si la seule chose qui fait qu'il

faut reconnaître des conteneurs
c'est on peut faire ça, ça me va.

Moi il y a un deuxième problème
qui me pose souci dans l'histoire,

c'est que si tu veux,
je sais pas comment vous ça se passe,

mais nous on gère des décès et faire
un système de distribution basé sur

un point de centralisation alors
que quand tu perds un décès entier,

il faut tout repoper en un coup ou
donc tu as besoin de peer to peer

littéralement Parce que sinon ton
bottleneck c'est la carte réseau de

la babasse qui distribue en HTTP.
J'avoue que là, encore une fois,

j'étais malade.
Alors là pour le coup,

là pour le coup, voilà le problème.
En attendant, alors là,

on arrive dans un point très
important de l'écosystème Kubernetes.

Vous avez mis en prod le bordel des
Chinois. Lequel? Lequel? Lequel?

Parce que là, pour le coup,
parce qu'il y en a plusieurs.

Moi j'ai dit on s'est dit par
exemple ils l'ont, je te parle pas,

tu parles, tu parles du multi,
c'est pire parce que moi j'ai

mis en prod tous ces machins là,
tous ces respects, il y en a pas

un qui marche. D'accord?
Donc moi je veux bien si tu veux,

à chaque fois que je dis ça,
c'est un truc qui est pareil,

on dit si ça ça marche,
tu l'as mis en prod non?

Alors moi j'ai mis en prod qu'on
soit clair,

ces machins là ne marchent pas.
Moi ça fait dix ans que je fais du

peer to peer sur mes infra et ça
ne marche pas avec ces systèmes

là pour de bonnes raisons,
parce que leur système,

il est fait encore une fois de
façon à penser à une forteresse.

C'est à dire que la totalité de
ces systèmes là sont pensés des

dans mon réseau.
Donc t'es un copain et donc la

faille de sécu.
Mais non mais je suis à 100 %

d'accord avec toi et c'est même et
c'est même quelque chose qui est en

même temps et justement je pense.
Alors voilà, voilà mon avis là

dessus ultra personnel, c'est que
je pense que votre expérience

chez Clevercloud que vous avez,
elle est extrêmement bonne,

et justement, il y aurait tout
intérêt à ce que cette expérience là,

elle puisse profiter en fait au
reste de l'écosystème,

c'est à dire en fait moi,
depuis le début, depuis le début,

je me donne des TOC en permanence
en expliquant aux gens comment ça

marche, mais en fait pas comment
ça marche, comment ils font mal,

mais comment en fait, avec ce
qu'ils ont, ils vont mieux faire.

Ah non non non, attends, il y a un
truc qui est important quand tu as

une baraque qui a été construit
sur de la boue, sans fondations,

si tu mets un immeuble haussmannien
dessus, ça ne marche pas.

Il y a un moment parce que tu
utilises à peu près les mêmes

références que moi et c'est la base.
De la base, c'est un problème.

Alors si tu veux, oui,
on donne des tôles et on ne donne

pas du tout des tôles de défonce.
Encore une fois, on a été les

premiers à accepter cette techno
en disant il y a toutes les

techno qu'on supporte en Europe.
Sur Clever,

il y a tout le reste que vous pouvez
faire en docker et il y en aura.

Vous n'arriverez pas à rentrer
dans du docker. Et c'est vrai.

Et on finira certainement un jour
par faire du VPS pour les gens

qui ont absolument besoin d'aller
faire du SSH et des choses dessus.

Par contre, la question elle est
quand tu regardes un format,

est ce qu'il a répondu au problème?
On vient de dire qu'il y a un

problème d'isolation et de sécurité.
On vient de dire qu'il y avait

un problème de mise à jour par
la virtualisation avant.

Donc en fait, on peut se reposer
sur la virtualisation pour la

sécurité et la contextualisation,
pour le pour le ce qu'on fait.

Je lance du docker la lance dans
une machine.

Est ce que j'essaie que j'ai que à
peu près tout le monde, y a personne?

Ah non, nous on lance chaque
containers dans sa vertu,

On fait un peu du kata si tu
préfères, mais à notre sauce,

on finira probablement par
rejoindre le projet Kata.

On bosse déjà beaucoup avec Intel
sur des sujets, mais ce qu'on veut

expliquer par là c'est si tu veux,
quand tu me dis ça a résolu le

problème, ça n'a pas résolu les
problèmes d'isolation, ça en a créé,

ça n'a pas résolu les problèmes de
portabilité puisque à mon sens,

ça en a plus créé qu'autre chose.
Ça a vraiment pas résolu les

problèmes de faire des binaires
trop compiler largement alors

qu'on avait tout pour les
résoudre ce problème là.

Je rappelle on a l'open source,
l'Open source a triomphé.

On a quand même un marché dans lequel
aujourd'hui, la plupart des softs,

c'est normal d'en donner des sources.
Ça va même jusqu'à Elasticsearch

qui libère les sources des parties
payantes en disant si tu as un truc

à corriger ou si tu veux faire ta
propre compile, fais le. Tu vois?

Donc l'open source a triomphé.
Et du coup, on fait quoi?

On distribue des binaires dont
on regarde pas le contenu Et ça

c'est un autre problème avec le
système de packaging.

Je te signale qu'aujourd'hui le
lien entre ce qui a été compilé

et le binaire que tu télécharges
n'est pas fait.

T'as aucune putain d'idée de ce
qui est lié.

Ce qui veut dire que quelqu'un qui
décide de pousser sur le docker

hub dégage des portes dérobées,
Il peut le faire.

Il n'y a rien dans le format,
dans la conception du protocole

à ce moment là.
Quand je télécharge la lib,

une lib dans Debian et une lib
dev dans Debian,

j'ai pas la garantie que la lib a
bien été builder avec la lib dev.

J'ai dit qu'on ne tirait pas sur
Debian,

c'est tirer sur une ambulance.
Non mais encore une fois je sais même

pas si on sait que c'est le meilleur.
Debian est complètement merdique

en Perl, mais si je télécharge
depuis un miroir, je suis pas

sûr que le miroir n'y est pas.
Je suis d'accord avec ça,

il y a des checksum après moi
encore une fois, je fais pas de

Debian pour de bonnes raisons.
Chez Clever, il y a une règle,

elle est simple si jamais on
s'aperçoit, ça fait quasiment 1 h,

1 h et quelques qu'on parle.
On a toujours pas parlé de

Kubernetes,
on rappelle que c'était ça le titre.

Mais c'est bien parce que ça
rappelle, ça rappelle la chose.

Donc le grief sur les conteneurs.
Et donc moi je rappellerai juste

l'aspect enfin, en fait,
le mon tweet était vraiment que

sur Kubernetes en particulier,
et je dissocie en fait.

Personnellement,
je vais donner mon opinion en fait.

Et comment je vois Kubernetes?
Je le dis un peu, c'est pour moi

un gestionnaire de plateforme,
un gestionnaire de plateforme,

c'est à dire qu'il va vous permettre
de décrire avec de la sémantique.

Et alors pour le coup,
de la pure sémantique,

de la pure sémantique déclarative,
ce que je veux dans ma plateforme,

il se trouve que la primitive en
dessous quoi, c'est sémantique,

déclarative, c'est déclaratif,
c'est déclaratif.

Ah bah tous les tous les manifest
que je vais faire de ce que je

veux le manifest kubernetes d'un
pod il dit binaire l'actu

download là ouvre tel port,
file reprend tel afterlife de pod.

C'est quelque chose qu'on aime pas.
Les manifest de pod,

on ne les manipule plus, on manipule
à la rigueur des déploiements,

on manipule des choses qui exploitent
les manifeste. Ça veut dire quoi?

On va dire que à l'heure
actuelle et à l'heure actuelle,

on utilise des pod et ses potes
sont en effet des conteneurs etc.

Et en tout cas ils sont
déclarative dans le binaire.

La primitive de base de cube CRS.
Alors je pense qu'on est tous

d'accord au bout d'une heure.
Du coup on est d'accord sur le fait

que un conteneur n'est qu'un binaire
à partir du moment c'est un contexte.

Non mais non, c'est non,
c'est pas un binaire,

c'est un contexte d'exécution.
Et avec le binaire, oui.

Si tu veux un binaire oui non mais
d'accord, ça veut pas le faire,

mais du coup tu sais pas ce qui
tourne dedans.

Mais c'est pas le but justement,
tu n'en as aucune au niveau de

conscience.
S'intéresse que à Kubernetes on

s'en fout.
Non mais en terme oui non mais

je suis bien d'accord.
Mais en terme d'architecture tu

sais pas quel protocole on parle,
Tu sais pas comment c'est codé,

tu sais pas comment le mettre à jour,
tu sais pas s'il y a de la donnée

dessus, tu ne sais pas si la
donnée est répliquée, tu ne sais

pas si quand tu arrêtes le pod,
tu peux le faire violemment ou pas.

Parce que si tu le fais violemment ou
pas, c'est la déclaration, c'est la

déclaration, c'est la déclaration.
C'est à dire que la personne a si

heureusement tu dis que tu déclares
le protocole dans la déclaration,

Non, non, pas le protocole.
Est ce que tu déclares le modèle de

runtime, la déclaration, le modèle,
le protocole, donc le protocole que

tu parles dans une déclaration, que
ce soit réseau ou quoi que ce soit?

Donc le truc qui te permettrait de
savoir si tu es en train, si tu fais

un protocole que tu peux interrompre,
pas interrompre un protocole,

tu peux le load balancer pas load,
balancer, load balancer du http

va load balancer de l'UDP.
C'est possible dans certains cas,

pas possible dans certains cas.
Alors là pour le coup, le port,

le port c'est défini par défaut,
c'est du TCP port, c'est pas,

c'est pas sémantique. Le port.
Enfin moi je te fais écouter de

la http sur les ports de 1 à 8.
Oui mais justement moi ce que je

veux c'est que et c'est déclaratif,
c'est à dire que quelqu'un me

dit tel conteneur,
je l'ai buildé de manière magique.

Voilà, j'avais une potion magique,
j'ai sorti un conteneur,

ce conteneur là.
L'avantage c'est que je le ferai pas

pour touiller la potion 20 fois.
C'est à dire que ce truc là,

cette potion là, je peux la
dupliquer, je peux la cloner,

ça sera exactement la même, sans
aucun bit de différence ce truc là.

Maintenant, je te dis que pour
le boire, pour le faire tourner,

et ben à la fin, ça va être comme ça
et ça va être sur ce port là précis.

Moi je te donne toutes ces
déclarations là,

je te la donne et tu peux le faire.
Je sais pas si c'est un mode

d'emploi.
En termes d'architecture,

tu n'as toujours pas aujourd'hui
Kubernetes Ice Cube.

Dis moi comment je l'explique.
C'est justement cette boucle

entre dev et ops, tout le monde
voit le huit, dev hub, etc.

Et bien moi quand je vois une boucle,
il y a un point au milieu.

Ce huit là, il y a un point au
milieu. C'est un point remarquable.

Qu'est ce que c'est?
C'est donc une frontière entre

deux mondes le monde du dev,
le monde de l'App.

Moi, quand j'entends frontière,
maintenant j'entends api, j'entends

api, j'entends la déclaration.
J'emploie contra, j'emploie API

au sens très très large.
Et bien maintenant,

Kubernetes c'est ce truc là,
c'est ce truc qui dit qu'il y a

des devs qui font un truc et il
y a des ops qui savent l'opérer.

Alors oui, ok, ils ne savent pas
ce qu'il y a dedans.

Et justement, Kubernetes permet de ne
pas avoir le fait qu'il ne sache

pas de base en fait qu'ils sont
incapables de réellement comprendre

comment ça pète ou pas en fait.
En fait, en fait, l'histoire elle

est très simple, soit soit, soit.
Tu considères que ce que tu dois

faire pour opérer un truc,
tu as juste à fournir du CPU.

Et dans ces cas là, expliquez moi
à quoi vous servez aujourd'hui,

hormis filer trois coups de
molette dans ce machin qui est

un moyen stable, tu vois?
Et on pourra parler après des

designs de Kubernetes notamment
l'API Server et sa façon d'être

bizarrement master et de ne pas être
capable de clôturer ces problèmes.

Mais ça c'est encore une fois,
ce sont des problèmes dont on peut

parler un tout petit peu plus tard.
Je suis complètement fan,

mais les serveurs. Donc d'accord.
Aujourd'hui tu prends un API serveur,

tu butes, qu'est ce qui se passe?
Je prends une équipe de daube,

tu la bute.
Qu'est ce qui se passe

aujourd'hui dans un système?
Tu es dans un système, Tu as déployé

sur 50 bécanes, dans un serveur,
un API server, ton API server,

tu tues pour x raisons la machine
sur lequel il tourne, tu disparais.

Aujourd'hui, l'API Server il était
master, ce qui veut dire qu'un

serveur n'est absolument pas Master
si elle est Master. Non du tout.

Alors là, pour avoir déployé des API
serveur sur une centaine de machines

et des master slides, je te jure que
tes déploiements en cours partent

en cacahuète parce qu'ils partent.
Non mais si ils sont, ils sont dans

le vent! Non non non, non non!
Les serveurs? Pas du tout.

Le contrôleur manager oui, ils ont
une élection de leader, de leader.

Le scapulaire pareil, il y en a.
Élection de leader qui est d'ailleurs

à se taper le cul par terre.
Mais ce que je peux vous définir

comment ils font une élection de
leader, c'est très bien.

Toi tu peux donner un chiffre
aléatoire, c'est toi,

c'est Debian huit trois.
Ah merde, moi je pensais à quatorze.

Bon bah faut qu'on recommence
jusqu'à ce qu'on soit d'accord.

T'es sérieux mec?
Genre vous avez rien trouvé de mieux?

Non mais c'est oui mais ça marche,
ça me fait les pieds,

les pieds serveurs il y a.
Alors pour le coup, c'est peut

être le seul composant dans le
cube où il n'y a aucune aucune.

Effectivement, le manager,
en fait le manager et le serveur

ont une relation complexe.
Mais ce que je veux dire par là,

c'est que c'est un système où tu n'as
pas de vraie distribution du rôle.

Je Si tu veux,
le système de déploiement et

d'orchestration de cube.
Je l'ai regardé il y a un peu

plus d'un an.
J'ai décidé de réécrire le

système de déploiement chez nous
depuis le début.

Nous on fait un système
d'orchestrateur qui est full

distribué.
C'est à dire que chez nous, tu peux

tuer des bouts de orchestrateur et de
l'orchestrateur, il se passera rien.

Les déploiements vont continuer
à faire leur vie,

il y aura aucun problème, il n'y aura
aucune interruption de prod même.

Tu sais que si tu tue le contrat
manager, il n'y aura pas

d'interruption de prod, c'est
juste qu'il se passera plus rien.

Le cluster de la prod de
déploiement en cours, tout ça.

Alors on a on a un temps de pause
dans les déploiements, mais tout ne

tombe pas, c'est pas parce qu'il
n'y a personne pour les surveiller.

Et encore une fois,
ça dépend du nombre de déploiements

que tu fais à la seconde.
Mais si tu veux, moi j'ai un moment,

j'ai des problèmes à régler,
ça entre autres.

C'est un problème, je ne peux
pas me permettre de m'arrêter.

Alors on a été lire le truc et
on était horrifiés.

Par ailleurs,
il y a un autre problème qui est

que Cube repose sur un truc qui
s'appelle Etcd pour faire sa

conférence et assume que TCD marche.
Et Sauf que si pour le coup on

va plus dans le monde des
systèmes distribués Etcd,

ça fait marrer tout le monde parce
que TCD il n'est pas capable

d'assurer une résilience en cas de
forte charge en cas de l'expert.

Il n'a pas été jusqu'à MongoDB.
MongoDB a fait marrer encore plus

les gens parce que quand on l'a
soumis à des stress tests MongoDB,

il n'a pas seulement perdu de la
donnée, il n'a pas seulement dit

de la donnée qui était vieille,
il n'a pas seulement imposé de

la non réécriture de données.
MongoDB a généré de la donnée,

c'était, c'était.
C'était un nouveau type d'erreur

dans un système distribué.
Personne n'avait vu ça.

TCD Aujourd'hui, il tient pas.
Il y a très peu de systèmes de

logs distribués qui fonctionnent.
Il y en a un qui a été basé

d'ailleurs d'après les réflexions
de Google et qui s'appelle Zca et

qui marche admirablement bien.
C'est ce qui fait tenir Hadoop,

c'est ce qui fait tenir des tonnes
de choses depuis des années.

C'est des tonnes de problèmes.
Il avait des problèmes à un

certain moment, il a été designé
pour certaines choses et pas pour

d'autres. La différence? Zookeeper.
Mais pour le coup, c'est dit dans

la façon dont on peut l'utiliser.
En fait, le problème qu'ont eu les

gens, c'est qu'ils ont voulu tout.
En fait, ils ont cru que Kubernetes

c'était mes OS et donc ils se sont
dit Chouette, j'ai un Schindler,

et ben je vais pouvoir mettre mes
100 zéro zéro zéro machines dessus.

Il y a des TOC dans des gens de la
tech qui parlent de ça et j'ai mis

mes 6000 machines d'un seul coup,
avec plein de choses différentes dans

Kubernetes et ça a pas marché. Voilà.
Comment ne pas faire parce que juste

ils ont même pas regardé pourquoi tu
dis ça? C'est ça la promesse du truc.

La promesse c'est de te dire on
va gérer ton infra. Non, jamais.

Et vraiment. Et là, d'un coup, il.
Lire tous les tweets de Kaiser

Tower depuis au moins quatre ans
et tout ce qui ne va pas

attendre le Kaiser Tower.
Je pense qu'il est atteint pour

tout le monde que Chelsea Tower et
a atteint le à peu près 20 mètres

au dessus du sol quand il marche.
Et ça fait très longtemps que Kaiser

ne comprend plus ce qu'il écrit.
Mais justement, c'est très bien.

C'est que je pense que les gens
qui ont fait du bruit n'ont jamais

imaginé le point où il en est devenu.
Maintenant, c'est toi même qui

m'a dit que tous les Major Pass
fonctionnaient sur Kubernetes,

Mais non, c'était un problème.
Ouais alors il y a un problème,

c'est que c'est faux.
Alors en gros non mais la notion,

la notion moi je connais aucun
pass qui tourne sur cube mais la

bah si il y en a pas forcément
des bien il y a Openshift voilà.

Et sur Shift fonctionne sur un
fork de cube donc admettons je

te l'accorde, mais un moi j'ai
jamais vu de déploiement très

massif de openshift et ensuite
c'est pas un des major pass qui

tourne et ne vient pas sur cube.
Nous sommes pas sur Cube mais

heureusement Appengine fonctionne
pas sur Cube et heureusement.

Non mais c'est heureusement dans un,
dans un dans un certain moment.

Il y a aussi juste une question
de l'histoire, c'est que,

à l'heure actuelle, Kubernetes peut
commencer à devenir un pass, mais

parce qu'en plus il est vraiment,
profondément, littéralement.

Ce que tu viens de me dire,
c'est qu'il ne faut pas partager

son cube et en faire un indoor.
Le problème que tu as quand tu

fais de l'informatique,
c'est qu'il faut que tu partages

des ressources et que tu les
partages entre plein de projets.

Et alors toi tu dis non, Il faut
restreindre le périmètre des projets

et faire du cube un cube ou faire
du cube qui est doublé. Admettons.

Ça veut dire que très cube,
la demande globale,

c'est quelle que soit la façon
dont tu le fais, admettons.

Enfin, littéralement, c'est ce qu'on
va fournir, parce que effectivement,

tu fais jamais du cube, tu fais
toujours du cube avec les six ou

sept ou quinze ou 30 projets rigolos
du moment de la SNCF, c'est tous

les projets, c'est marqué Alpha,
mais tous les noms des call en prod.

Ça me rappelle la grande époque
du JCP où vous collez les alpha

sur les ORM en prod,
c'était bien Ruby qui n'a jamais

dépassé le 0.0, Aucun projet n'a
dépassé le 0.0 quelque chose.

Je connais plein de projets Ruby
qui sont en prod et qui marchent

très bien et qui sont toujours
dans zéro zéro.

Ouais non mais enfin c'est
encore une fois c'est un projet

SNCF pour le coup.
Ouais non mais enfin moi j'ai

une façon très simple de savoir
quand nous on fait des choix

technologiques.
J'ai une façon très très simple

de savoir Le projet fait partie
de la SNCF à -100 points.

Il y a quand même de fortes chances
pour que ce soit une béta écrit

par trois personnes qui se voient
dans un bar à San Francisco.

Parce qu'il y a un autre sujet,
c'est que la SNCF n'était pas à San

Francisco, tu rentres pas dedans.
Donc il y a un vrai vrai

marketing géographique.
Typekit c'est des chinois alors ils

ont émigré, ils sont à San Francisco.
Je les ai vu d'ailleurs dans leur

premier meetup à San Francisco.
C'est hyper bien,

c'est l'écosystème Rust et Clever.
On utilise du Rust depuis toujours.

Chez Clever,
on a pondu un truc qui s'appelle

Norme qui part sur Combinator.
Et très sincèrement, quand tu fais du

Rust, si en dépendance transitive
il y a pas un moment où tu tires,

nomme ses cheveux parce qu'on
est quasiment toujours dans les

dépendances transitives.
Donc on connaît très bien

l'écosystème Rust et on a beaucoup de
projets qui sont écrits en Rust,

donc on connaît très bien les
gens de Typekit.

Effectivement, eux sont rentrés
dans la SNCF, ils sont quand

même dans la vallée et et fine,
tu vois ce que je te dis juste,

c'est que la SNCF,
en tant qu'organisme de gouvernance,

est un organisme de gouvernance
valley centric.

Et pour être tout à fait honnête,
San Francisco centric.

Déjà la vallée c'est louche, tu vois,
genre San Francisco, admettons.

Tu vois, c'est vraiment la façon
dont est gérée cette fondation.

Moi je trouve ça un peu grave, mais
toujours est il que effectivement,

on va te fournir de moyens de
qualité parce qu'il y a des gens

qui sont rentrés dans un pattern
où Cube est devenu un framework.

Fine Cube est devenu leur framework.
Je ne comprends pas pourquoi se

servir de cube comme framework?
Parce que si ton problème dans la vie

c'est de faire du système distribué,
je peux te proposer une demi

douzaine d'autres solutions qui
à mon avis sont plus fortes.

Tu prends du Erlang,
tu feras du système distribué,

ce sera très bien, tu auras un son,
ok, tu fais ça, pique le Erlang.

Mais non, c'est pas ça qui va te
permettre de faire du distribué

avec des langages différents.
Erlang est vraiment très bien, il n'y

a pas de fait des trucs avec Erlang
que tu feras jamais dans un cube.

Parce que OTP qui est un système
d'acteurs, est très intéressant.

Si on prend un système d'acteurs
d'un projet en lien chez DotNet,

en Java, tu en as plusieurs.
Le plus gros est probablement AKA.

Ils ont fait énormément d'Aka et
c'est un truc incroyable.

Je te dis,
un caca ça fait tourner tout

Fortnite Fortnite c'est un énorme
cluster aka avec du aka persistance

alors que moi aka persistance,
j'aurais même pas osé, tu vois.

Mais mais tu vois,
ça c'est du système distribué.

Quand on me dit on va coder du
système distribué, tu les lancera.

Le protocole dans lequel ils
vont se parler, c'est HTTP.

Idéal pour faire du système de
distribution. On a fait mieux.

Exactement.
On a fait mieux et les gens

feront mieux. Et c'est ça.
Tout le propos que je fais,

c'est que, à l'heure actuelle,
dans plein de prods, on allait En

fait, à mon avis, ce qui se passe,
c'est que tu as trop vu de gens bons,

de gens doués, des gens qui savent
faire de test, des développeurs

qui comprennent ou il y a un bon
lien entre les deux, etc.

Pour avoir été dans plein de
boîtes et même celles encore de

la bouteille où tu que tu que
les gars sont des tanches.

Mais que ce soit des gens de l'Obs,
il y a deux trois choses qui

sont pas si mauvais que ça.
Je te promets que c'est parce

que t'as pas vu leurs prods et
c'est bien.

J'ai vu des bouts de la prod pas si
mauvais que ça alors qu'elle est très

très très très très bien leur prod.
Mais bon, en gros c'est des gens,

nous on a des gens qui sont venus
nous voir pour nous dire j'ai un blob

à partager sur 15 000 machines, on
m'a dit que c'est un blob de je sais

plus quinze méga de quinze kilos.
Je vais le mettre sur le même cache

parce qu'on m'a dit que c'était
rapide et tout le monde a validé.

Tout le monde a validé ce choix là,
tout le monde, tout le management,

tout le staff de tout.
Un mec derrière toi et les loups

et loups.
On nous a demandé à la fin en mode

je comprends pas, ça marche pas.
Bah oui, parce que même cash c'est

pas et pas une base de partagé,
c'est juste à la limite on peut

le garder et c'est le maximum
qu'on puisse faire.

Mais en gros,
c'est juste pour revenir au fait

que tu as sans doute trop vu de
gens où en fait c'est très bien,

tu as fait des choix technologiques,
humains, managériales,

etc qui sont censés censés, c'est à
dire qu'ils vont dans un, dans un,

ils vont dans un tout et ils sont.
Ça permet d'aller dans le bon sens,

dans la bonne direction.
Ce qu'on voit dans la plupart des

boîtes où on passe à l'heure actuelle
dans l'univers de la tech, c'est que

malheureusement ce n'est pas le cas.
On pourrait discuter du pourquoi

c'est pas le cas et tu as donné
notamment l'exemple comptable.

Et c'est vrai, c'est pour être à
leur échelle dans un.

J'ai donné une interview dans un
podcast au début du mois où

j'explique pourquoi on
fonctionne comme on fonctionne

et c'est sans doute,
c'est sans doute extrêmement bien.

C'est juste qu'à l'heure actuelle
c'est pas le cas dans la plupart

des boîtes et malheureusement,
clairement malheureusement.

C'est juste qu'à l'heure actuelle,
ces solutions là permettent

d'être une solution transitoire,
d'amener les choses.

Et la principale chose qu'on dit
d'ailleurs dans Uber, c'est que

c'est un stresseurs de organisation.
Mais le problème que tu que tu

prends là, c'est que à force de
faire du battage autour.

Et bien en fait, on est tous
obligés de supporter ce machin.

Et en fait, si tu veux,
le modèle sémantique de description

des services n'est pas sémantique,
il est, il est, il est focussé

autour des binaires des ports,
il est en fait il passe son

temps à faire de la tuyauterie.
Tu mélanges le modèle sémantique

avec ton problème de plomberie
et si tu veux c'est possible.

C'est juste que aujourd'hui je ne
vois pas comment dans un contexte

non cube, tu reprends les
fichiers qui sont disponibles.

C'est à dire que les fichiers qui
sont disponibles et qui sont censés

décrire des choses, pour moi ils ont
la même valeur que tes fichiers chef,

on saura pas quoi en faire le jour où
on décidera de changer de runtime.

Parce que la description
sémantique qu'ils ont décrit des

ports et du binaire.
Mais par exemple, le jour où tu

décides de procréer le tout par du
Quick, t'es incapable de le gérer

parce que tu sais pas ce que tu peux
mettre dans du Quick et pas du Quick.

C'est un peu réducteur parce que dans
une description d'un déploiement,

tu ne mets pas que un port et tu ne
mets pas que tu vas voir, tu donnes

de sémantique, tu t'oublies tout.
Alors on va déjà passer sur les

volumes, les volumes physiques,
les accès, enfin les espaces définis.

Même pas ton volume.
Si t'as besoin d'aide, t'as pas

besoin d'un iOS, tu as besoin de
garanties. T'as jamais fait ça.

Ça c'est le principe de la story. Tu.
Oh non, non, non, non, non, non,

non, bien sûr que non, non non, Là,
ce que je te dis, la story, c'est

tu peux faire des tags. Mais tu.
Non,

tu ne fais pas de besoin de garantie.
Tu choisis la sécurité que

l'option à fond.
Mais en fait, en même temps tu

ne peux pas demander.
Donc on est bien d'accord,

c'est pas quelque chose de
sémantique dans sa description,

c'est quelque chose de sémantique
dans son contexte, non,

mais c'est à dire que du coup ça veut
dire que tout est storage class,

elles ne sont pas transposables
dans un autre modèle,

elles sont transposables
uniquement à ton organisation.

On est en train de parler de
truc qui a été conçu encore une

fois par des gens qui n'ont pas
de monitoring globaux.

Google n'a pas de cluster de
monitoring global, il y en a,

il y a plein de borgmann les uns à
côté des autres et chaque projet a

son truc parce qu'on est en train
de parler de gens où effectivement

ils ont résolu le problème de dire
on va régler le problème global,

pas on règle pas le problème global
et chaque équipe se démerde.

C'est pour ça que moi je trouve que
c'est très bien en fait ce modèle,

chaque équipe se démerde.
Moi c'est quelque chose que je prône,

c'est à dire que les
organisations globales.

Mais moi à l'heure actuelle,
vraiment, et ça c'est un fait vu

et vraiment expérimenté,
c'est que dans une organisation

extrêmement grande ou à la tête,
c'est un connard,

et bien ça se passe mal.
Et en fait je préfère avoir des

organisations atomiques, mais c'est
juste un point de vue statistique,

c'est que j'ai plus de chance
d'avoir comme ça quand je suis

dans une organisation pyramidale,
un connard à la tête qui risque

de tout niquer que si jamais
j'atomise mes petites équipes,

je fais en sorte qu'elles soient
et qu'elles soient un peu moins.

J'ai une nouvelle pour toi.
Ton problème il n'est pas technique

parce qu'en fait tu es d'accord
pour dire que cette techno,

elle marche moyen?
Non, elle marche, elle marche

très bien dans son cas d'usage.
Une fois que tu as fait.

Une fois que tu as ta.
Tu as renoncé à plein de choses

que ça aurait pu régler.
Tu te dis c'est pas grave,

ça les règle pas ton problème,
il est pas là, il était juste posé,

il n'était pas réglé avant,
il y avait.

J'avais pas de solution pour le
régler.

Mais oui, on avait fait mieux.
On a créé plein de nouveaux

problèmes en les faisant.
Encore une fois, vous n'avez pas

testé ce que nous on fait,
mais on règle les problèmes.

Ton problème, il n'est pas là.
Ton problème, il est.

Tu as toujours bossé dans des
environnements managériales toxiques.

Arrête de bosser avec ces gens là.
C'est pour ça que je suis devenu

indépendant. Non, non, non, non, non.
J'ai arrêté de bosser avec ces

gens là.
Tu continues à bosser avec ces gens

là dans un contexte où ils te payent
juste plus cher et où quand ils te

font trop chier, tu claques la porte.
Mais manifestement,

tu n'as pas arrêté de bosser
avec des gens pas toxiques.

Puisque tu passes ton temps à dire je
vais essayer de préserver l'équipe

d'un éventuel manager débile.
Et donc en fait, tu es toujours

dans cette théorie de jeu politique
à l'intérieur de ta boite.

Et c'est exactement ce que je
disais au démarrage sur sur Docker.

Vous n'êtes pas en train de
régler des problèmes techniques,

vous êtes en train de régler des
problèmes managériaux,

de comptable de ce que vous voulez.
Moi je règle des problèmes de

technologie,
c'est à dire que mes clients,

ils m'envoient des applications
et ils me demandent qu'elles

soient avec de la bonne sécu,
avec de la bonne performance et

plus jamais en entendre parler.
Et ça, c'est ce que je délivre.

Et c'est pas ce que délivre Cube
en fait.

En gros, tu as réglé un problème
algérien à leur place.

Par ailleurs, il se trouve que
je règle le problème managérial.

Du coup, j'ai un deuxième problème
managérial qui est Et du coup,

on fait quoi de nos jobs?
Et moi ça c'est un sujet dont j'ai

envie de parler parce que là,
pour moi, les mecs de l'innovation,

de l'innovation, alors toi tu as
réussi à faire l'innovation qu'ils

auraient du faire, mais alors moi
c'est genre toutes ces boites où je

suis passé et certaines très grandes
et qui avaient des équipes de.

Tu parlais de 100 000 personnes chez
Google, mais là c'était des équipes

avec des milliers de personnes
et qui faisaient de la merde.

Ça on l'a tous vu dans les
boîtes où on est passé et je

suis bien d'accord là.
En fait tu es dans un cas d'usage,

dans un cas de contexte où tu as
résolu le problème managérial dans

ton équipe, tu bosses avec le CAC 40.
Je tiens quand même à le préciser.

On bosse avec des ministères,
on bosse avec des organismes

internationaux, tu résous,
tu leurs résous ces problèmes là,

C'est tout à fait.
C'est à dire que c'est possible

à faire si tu les emmènes dans
le bon sens.

Et du coup en fait tout le monde a
envie d'être heureux au travail.

Et donc moi je ne vais pas me
contenter d'une solution

technologiquement inférieure parce
que le problème de cette solution là,

si tu veux, c'est que moi,
ça accapare mon temps et celui

de mes équipes plutôt que de
fournir des choses qualitatives

parce que le marché nous drive à
utiliser ce machin.

Et je rappelle que la grande vision
dans la SNCF et dans Kubernetes,

c'est quand même Elm.
Elm c'est quoi tar.gz avec des

containers dedans?
Encore une fois,

on est en train de faire ça.
Elm est détesté par toute la

communauté Cube, Ce n'est pas un
projet qui est dans le Nord,

c'est pas le système de packaging
aujourd'hui Customers qui est

nouveau que je connais pas.
Ah non, Custom et Customize pour

le coup est quelque chose qui est
intégré dans le Kubectl Kubectl.

Ca c'est Customize et tout le
monde déteste elle et vraiment

met n'importe qui dans la
communauté Un peu inclus dans

l'équipe avec des tests.
Elle n'a jamais été inclue dans

aucun SIG de que j'ai tapé le
packaging ELM de base.

Non non non non non non non non
non Mais alors alors moi, pénible,

N'importe qui qui me connaît mieux,
n'importe qui qui me connaît

sait qu'on a juste réinventé un
yet another Ansible avec un

templating en go, etc.
Donc on est d'accord pour dire que

c'est de la daube, c'est de la daube,
jamais de la vie. Si quelqu'un.

Non, il faut utiliser un truc qui
s'appelle customers je suppose avec

un K, ça fait comment ce truc là?
Alors customise le concept,

C'est un système d'overlay,
mais ça démarre bien.

En fait, c'est un système d'overlay,
c'est à dire que quelqu'un décrit

son application à un moment donné,
il décrit comment il le décrit

via des manifeste que pour le
coup on est vraiment.

En fait il décrit pas une
application,

il dit utilise tel binaire et
ouvre tel port mais fait le test.

Encore une fois, c'est pas une
description applicative.

Alors non, parce qu'une description
applicative en théorie, si.

Et ça marcherait.
A la fin, tu pourrais avoir un truc

qui est capable de te dire ton
système d'information fonctionne

comme ça, te génère un schéma,
te mets les liens importants,

on peut citer l'API break,
ça va merder, etc.

Et aujourd'hui je ne vois pas
comment faire ça avec un cast.

Mais peut être que de la même manière
on a vu Open API ou on a vu L'okf,

l'Open Container Foundation,
on va avoir une description.

Donc là la croyance non mais on
en a déjà un.

Il y a je crois deux projets dans la
SNCF pour essayer de standardiser ça.

Pour le coup, même pas.
À chaque fois que les gens se

rencontrent dans un bar à SF,
ils créent un projet alpha à la SNCF.

Donc oui,
il y a certainement des projets.

Est ce que pour autant ils vont
être successful?

Mais probablement imaginer que pour
écrire des trucs avec les builtin.

Mais je pense, Mais j'ai une petite
requête quand même parce que là je

dois dire un avantage, mais bon.
En tout cas un fait sur Kubernetes,

c'est qu'il est avec Docker,
c'est que ce sont des technologies

qui sont accessibles, elles sont
au delà du fait qu'elles soient

promues et et vantées et marketées.
Elles sont accessibles, elles

sont simples, elles sont simples.
Aujourd'hui,

ton premier déploiement cube,
ce n'est pas un truc qui s'effectue

en quatre minutes, c'est un truc.
Si tu prends la bonne personne

en quatre secondes.
Excusez moi, mais ton premier

déploiement cube, il faut écrire
un putain de manifeste.

Il faut faire une image,
il faut avoir un cluster en

admettant que tu utilises.
A la rigueur, c'est une ligne,

c'est kubectl create create et
c'est terminé en une ligne de clé.

Je suis désolé, tu n'as même pas
besoin de faire de YAML.

Je compare encore une fois avec
un pass comme nous et tu fais un

git add remote git push.
L'outil que tu utilises tous les

jours en tant que développeur.
Alors tu vois Cloud machin,

qu'est ce que tu as lu?
L'article que j'avais fait sur mes

concepts de phrases complexes?
Je termine, je termine ma remarque.

C'est le concept de.
OK, c'est une technologie qui est

installée, qui est accessible,
qui est documentée,

qui est simple et qui est partagée
par tout le monde. Comment?

Si moi je ne veux pas utiliser
cette technologie là et je veux

me rapprocher des concepts plus
sécurisants, plus partagés, plus que

vous proposez, est ce qu'il y a une.
Une manière, une méthode,

une documentation, une fondation
qui me permet de collaborer,

de travailler, de travailler de
la même manière que vous.

Mais bien sûr,
tu t'inscris sur notre système.

Non,
mais sans passer par votre système.

Mais tu peux, tu peux le télécharger,
le mettre chez toi,

mais ça veut dire demain.
Là, je vais trouver des gens

compétents pour pouvoir le
maintenir avec moi, bien sûr.

Bien sûr, aujourd'hui,
c'est le service qu'on voit.

Est ce que tu me demandes?
Est ce que tu peux l'avoir

gratuitement et ne jamais,
jamais, ne jamais?

Moi j'adorerais le faire en open
source.

On fait énormément d'open source
chez Clever et j'adorerais le

faire en open source.
Pourquoi est ce que Clevercloud

en entier n'est pas open source
aujourd'hui? C'est très simple.

Je ne connais pas de boîte open
source qui gagne de l'argent sans

se faire racheter. Non, non.
Qui gagne de l'argent tout court?

Je veux dire,
il y a des boîtes de service qui ont

acheté des boîtes d'open source.
C'est le cas d'IBM qui a racheté

RedHat et RedHat.
C'était déjà essentiellement une

boîte de service.
Et aujourd'hui, je connais des vici

qui foutent la pression à des boîtes.
Je connais des boîtes qui ont

créé des beaux produits et qui
vendent du cloud service et

c'est c'est ce que fait Elastic.
Et ils galèrent parce que face à eux,

il y a Amazon qui pille leur
propriété intellectuelle.

Et prenons des cas comme docker.
Techniquement, la boîte a

manifestement pas de revenus et donc
avait un problème avec le modèle

open source dans le cas présent
pour générer plein de problèmes.

Et c'est pas compliqué.
Moi sur l'histoire de l'open source

de Clever, c'est une question que
je pose régulièrement à des salles

remplies et je dis moi j'ai envie de
mettre Clever open source demain,

qu'ils utilisent la salle entière
qui sera prêt à payer pour ça?

Zéro personne.
Je suis désolé les gars,

il se trouve qu'on mange.
C'est con, mais on mange.

Donc est ce que par contre,
en utilisant Clever, tu permets

à des technologies plus fortes
d'avancer et nous permet d'open

source et plus de trucs et nous
permet d'avancer? Oui, clairement.

Par contre, à un moment tu ne peux
pas me dire votre discours à vous,

il parait cohérent mais je peux
pas l'utiliser gratos.

J'attends et je parle même pas de
gratos, c'est à dire c'est d'utiliser

les mêmes fondamentaux en fait.
En fait, la logique moi que davantage

on fait de la virtualisation notre
distribution Linux, pour le coup,

elle est complètement open source,
c'est que tu peux l'utiliser.

Les fondamentaux qu'on utilise,
ils sont, ils sont là.

Enfin c'est pas très compliqué.
Est ce que tu vois, on a construit

tout le monitoring sur du.
Est ce que c'est clé en main?

C'est pas clé en main.
Aujourd'hui, Kubernetes c'est

clef en main, c'est en main.
Si tu l'achètes à clé aujourd'hui

qui fait du Kubernetes Vanilla?
Tout le monde fait du geek,

donc c'est la même histoire, non?
Enfin, en tout cas, parmi mes

clients, il y en a peu qui font du
GPL en même temps parce qu'on dépasse

un certain nombre de certains,
mais il y en a, il y en a beaucoup,

enfin vraiment à l'heure actuelle,
des gens qui font vraiment du geek.

Malheureusement, en France,
on va faire simple, tu vas dans

la moindre conférence de dev,
tu fais qui utilise Kubernetes,

tout le monde lève la main et tu fais
qui utilise Kubernetes sans gcos,

sans minikube.
Maintenant tu vas dans une

conférence de DevOps,
tu dis qui utilise machin et tu

verras qu'il y aura 50 % de gens qui
font du in-house sur du bermuda,

du cube spray et du cube spray,
et du Archos et du machin, etc.

Tous les jours tu t'adresses pas
aux bonnes personnes et c'est vrai

que ça dépend beaucoup du profil,
mais moi, à l'heure actuelle,

à l'heure actuelle, la plupart des
gens qui me parlent et c'était même

le cas de la BNP etc, c'est que
il faisait du IN ou en tout cas,

et la plupart des boîtes françaises
ne veulent pas payer et elles

veulent faire du Linux gratuitement
et c'est un problème français.

Et avoir le savoir faire interne
plutôt que de mais même pas parce que

les gens ne veulent pas regarder
les sources genre je suis d'accord,

si jamais il y a quand même des
sources quand tu les regardes,

tu arrêtes,
tu arrêtes d'utiliser le soft.

Encore une fois, nous on fait
tout source basse, donc on fait

beaucoup de lectures de sources.
Il se trouve que si tu veux,

parce que c'est vraiment très
bien dans ce que je dans ce que

je reproche à Cube,
il y a trop de son orchestrator.

Je comprends pas comment tu peux
gérer de grosses infra dessus

l'orchestrateur quand on a voulu
changer notre orchestrateur le ce qui

est douleur, ce qui est la partie,
la partie scheduling de cube,

moi j'ai été la lire il y a un
an et des bananes parce que je

voulais réécrire l'orchestrateur
de le scheduler de Clover et je

me suis dit si ça se trouve,
on pourrait utiliser Cube. Non?

Mais alors ce qui est douleur de
clavier, sans déconner,

c'est le cube. Le ski douleur.
Son algo,

c'est celui qu'on avait en 2014.
Le ski Douleur de cube,

Pour le dire clairement,
pendant très longtemps, n'étaient

même pas inclus dans le projet.
C'est à dire qu'en fait c'était

un projet optionnel qui était mis
comme étant ne l'utilisez pas,

il est débrayable à n'importe quel
endroit et il est dit clairement que

si jamais vous voulez faire de la
prod, il faut en utiliser un autre.

Je connais au moins trois boîtes
qui vendent des scheduler cube

propriétaires en disant le scheduler
de cube ne marche pas, tout le monde

le sait et ce n'est pas un problème.
Vous pouvez utiliser l'autre.

Kubernetes est juste une boîte à
outils.

C'est fait aussi avec plein de
projets qui se mettent dans la

boîte à outils.
Vous auriez pu créer le propre

orchestra. On a on a notre propre.
Il aurait pu très bien se

brancher dans Cube.
Alors le problème de le brancher dans

Cube, il est sémantique, c'est à
dire que. Vous passez juste à côté.

Vous frôlez le concept
d'extensibilité de Kubernetes et

de Standard API.
Et c'est pour moi,

c'est là où est la vraie force, c'est
là où tu me dis ton déploiement.

Il gère pas ça, il gère pas ça,
il gère pas.

Le concept de je suis, de savoir ce
que c'est qu'un bord, il gère pas.

Et non, tu peux étendre l'API
exactement comme tu veux.

En fait le truc c'est que
pourquoi moi je le ferais?

J'ai un truc qui marche,
j'ai pas besoin de cette couche là.

Enfin, quand tu me dis tu devrais
l'utiliser, je te dis non parce que

quand tu marches avec quelqu'un,
ne serait ce que le concept de

tu vas embaucher quelqu'un,
il connaît très bien, il connaît

l'API Cube. Très bien. Voilà.
J'ai un opérateur spécifique qui

gère le protocole réseau Tartempion
et qui interprète ce truc là.

Tu as besoin, tu as besoin.
Après, tu peux réutiliser tous

les soucis, tu peux réutiliser
machin des langages communs.

Pour tous les métiers de l'IT.
Bon d'accord, faudrait que je

réécrive le scapulaire, faut que je
réécrive le runtime parce que là,

je peux pas, je peux pas me servir,
je peux pas me servir du container et

pour le coup tu viendras directement.
Je suis toujours pas d'accord

pour utiliser des modèles.
Enfin j'ai ellipser tous les

binaires et le kernel à part moi
je suis toujours pas d'accord donc

vire vers je sais plus quoi là.
Non mais non mais on va arrêter

avec les il est bien dans son
nom mais en fait.

Donc il faut que je réécrive un
runtime parce que si tu veux,

à chaque fois qu'on me dit il
y a un truc déjà dans le cube

mais tu as déjà fait.
Oui mais il marche aujourd'hui

donc je vois pas pourquoi
j'irais me taper une API.

Enfin, encore une fois,
tu as déjà regardé à quelle

vitesse bouge l'API de Cube?
Franchement, les mecs ont aucune

notion de versioning de l'API,
elle bouge à tous les commits,

c'est incapable.
Ça me rappelle la grande époque

de Docker à une époque,
une époque de docker.

On avait un client, le client,
le client est flingué la tête.

Non non, le client go est une merde.
On est entièrement d'accord dessus.

Sa compatibilité avec l'API est
absolument si on compte donc l'OS

qui est douleur est de la merde.
Le client GO est une merde.

On compte tous les trucs où tu
finis par me dire ouais mais non

mais quand même.
Alors alors alors le truc,

le truc, le truc, tout est moisi,
on est d'accord, c'est une techno

de daube. Mais non, mais en fait.
En fait, j'ai l'impression que tu

montes une espèce de cathédrale
et t'as envie qu'elle soit

parfaite mais malheureusement
qu'elle soit parfaite.

Je fais de la prod, l'informatique,
si ça pète, j'ai un problème.

L'informatique c'est pas parfait.
Et bah en fait en gros non mais

la question la question c'est
est ce que c'est du lourd?

Tu l'as ton runtime, tu l'as.
Moi je te pose, je te repose la

même question maintenant.
Moi qui suis chez des clients,

j'ai des clients, ils ont rien, ils
sont à table rase, ils sont à poil.

Et t'es en train de me dire était
en train de me dire il ne faut

pas qu'il le fasse en interne.
Mais mais moi,

la question de la différence,
voilà peut être là les américains,

les américains qui balancent des
bêtas dans la cncf quand ils se

font prennent un café ou une
bière à San Francisco, Eux,

ils s'en foutent que ce soit parfait,
ils s'en foutent que l'application

elle soit hyper secure.
Eux ils veulent, ils ont un problème,

ils ont une potentielle solution,
une feature, ils la font,

ils font la MVP, ils la font paf!
Nous capturent l'espace marketing

au sein de la SNCF pour assurer
que personne d'autre ne puisse

concevoir quelque chose autour de ça.
Peut être on est sur autre chose.

C'est leur stratégie, c'est leur
vision des choses de ce soft.

Nous, ce soft, il a existé parce
que Google avait envie de jouer

Docker et ça très bien.
Toi, non, tu es parfaite.

Donc non, non, Kubernetes,
ça a fâché ça.

C'était Google qui était très
fâché à propos de Docker parce que

Docker avait fait des conteneurs
et que c'était Google qui avait

fourni tous les patchs dans Linux
kernel pour faire des conteneurs.

Enfin une bonne partie.
Non, non, non, c'est avec LXC avant,

mais alors bien avant.
Et qui en a fait une tonne pour

en avoir fait.
Regarde de près d'où venaient

les patchs de spacing du kernel.
Je te jure que Google est Google

repose sur les conteneurs.
Oui, voilà, les conteneurs Google,

encore une fois,
c'est leur monde à eux et c'est

très compliqué d'en parler.
Mais ce que je veux dire par là,

c'est qu'il était furax.
Et il se trouve que quand Docker

a poppé, tu vois, il était.
Mais tellement furax qu'ils se

sont dit on avance.
Ils ont proposé un rachat qui n'a pas

été accepté par Docker et du coup ils
les ont pris en grippe et Kubernetes.

L'objectif était d'empêcher Docker
d'aller anyway à la prod et ça a été

la fameuse guerre des Orchestrateurs
qui a duré huit dix mois,

dans laquelle ils ont fini par
gagner pour une raison simple ils

ont plus d'argent et c'est aussi
simple que ça, parce que c'était

aussi bien meilleur que Swarm.
Si jamais il faut faire ça,

alors là, technologiquement,
tu peux pas me dire que Swarm

était même un tant soit peu,
mais alors même pas de très loin.

Je suis d'accord avec toi
technologiquement Swarm,

j'ai toujours trouvé que c'était
daubé par contre.

D'un point de vue usabilité de
l'utilisateur.

Je suis désolé, c'était beaucoup
plus simple et j'ai même envie de te

dire une chose c'était l'argent.
Mais oui, bien sûr!

Mais en fait le truc il est
toujours là.

Même moi j'ai l'impression de répéter
en boucle les mêmes histoires.

On me dit la composabilité,
la modularité,

la maintenabilité et surtout,
une fois que tu as un standard,

tu pourras prendre des blocs,
en remplacer.

C'est le discours qu'on avait sur
Java cinq ou 1.4 au sein du JCP.

Et en fait c'est Websphere ou
Weblogic.

Franchement,
ça a jamais été la même chose.

Dans dix ans ce sera la même chose,
Dans 20 ans, il n'y aura jamais une

universalité comme il n'y aura jamais
un système informatique qui marche.

C'est une illusion, on est d'accord.
Le Standard, en fait,

c'est un foutage de gueule dans
le cas présent.

Et donc du coup, tu en veux,
tu en veux un descriptif?

Un standard sémantique?
Oui,

mais alors sémantique et sémantique?
J'ai l'impression de voir le

xkcd qui est oh là là,
il y a quinze standards, c'est nul.

Je vais créer un standard pour
tous les unir tous.

Il y a maintenant seize standards.
Non, non, c'est pas vrai parce

qu'on a déjà des standards
sémantiques qui fonctionnent.

Aujourd'hui tu fais ta dépendance
de projet en Maven où tu décris

tes dépendances de projet.
Ça fonctionne et aujourd'hui tu as

plusieurs softs qui s'en servent
et ça marche très bien et c'est un

format qui n'a pas bougé du tout.
C'est pas du tout une

description sémantique.
Tu dis explicitement la librairie

dont tu as besoin, tu ne dis pas
il me faudrait un truc qui fasse

de la DB. Et bien si, justement.
Parce qu'en fait, vu qu'avec les

plugins tu modifies ces trucs là,
tu es capable de le faire.

Et justement avec des plugins
qui sont des opérateurs,

tu peux le faire.
Ben non, bien sûr,

ça n'a rien à voir parce que tes
opérateurs ils gèrent des binaires

mais pas forcément les opérateurs.
Alors moi j'ai créé des opérateurs

dans la vie qui ne font rien,
mais alors vraiment rien du tout,

comme des binaires.
Moi je te paye pour ça.

Les mecs ils disent non,
il fait des opérateurs qui font rien.

Si vous voulez me payer,
vous pouvez payer, je fais quelque

chose et alors? Sans aucun frais.
Mais non, justement,

le concept même d'opérateur est
justement les serveurs pour moi

est une beauté absolue et qui
devrait d'ailleurs sortir du projet

Cube tellement elle est bien.
Mais vraiment, elle devrait devenir

bien. Ils sont en bêta, tu vois?
Non, non non non, Moi je parle

vraiment de l'API Server.
Et puis maintenant il y en a beaucoup

qui sont sortis de bêta pour le coup
et et non l'API serveur en elle même,

sa notion de déclarativité de
gestion, même interne, mais vraiment,

mais à plein de niveaux.
On n'est pas dans ton cube donc je

vais essayer de pas trop en parler
technologiquement maintenant,

on pourrait refaire quelque chose
là dessus que sur l'API server,

mais justement je trouve son modèle
déclaratif de gestion du workflow etc

dedans, mais extrêmement dramatique.
Enfin, il y a dans combien de

déclarations de service cube?
Tu as une espèce de truc avec un slip

et un end et ce genre de choses?
Enfin, t'es quand même au summum

de la question de la catastrophe.
Alors personnellement, si jamais

un jour je l'ai fait dans ma vie,
il faut tout de suite me taper.

Et je ne l'ai jamais fait.
Jamais, jamais, jamais,

jamais de la chance.
Parce que moi, tous les gens que

j'ai vu faire du cube, tu te finis
par des trucs dans un watch.

Parce qu'encore une fois, le Watch
ne sait même pas ce qu'il fait,

ce qu'il essaye de checker.
La seule chose qu'il renvoie,

c'est un code de retour.
Encore une fois, je te renvoie,

il te renvoie, il te renvoie le la
ressource que tu voulais et un numéro

d'incrément à l'endroit où tu es,
comme souvent.

Et après tu viens get cet
endroit là et tu l'as.

Et après quand tu refais un Watch
revient à partir d'un niveau

D'incrément et il va te dire non,
c'est vraiment purement bien fait.

Tu sais exactement quelle est la
ressource qui est updater etc.

C'est c'est pour le coup tu fais
un Watch le Watch vraiment,

le TPIY, le watch de ressources,
le watch d'objet en ce sens que

tu parles des objets cube,
je parle des objets cube.

Ah oui non mais alors là pour moi
non mais en fait non parce que en

fait ça c'est fourni sous forme
d'une API à pull, alors que ça,

ça devrait être un flux ça on
est dans un cas Cqrs est une

notion de flux, pour le coup,
bah c'est une notion de flux qui

ne se comporte pas comme un flux
puisque tu es en train de l'appeler.

Donc en fait il y a quand même
un souci là dessus,

mais c'est lié à ce qu'il t'envoie.
Il t'envoie oui, mais justement il

t'envoie, il t'envoie, il t'envoie.
Une notion de Watch donc en fait oui,

c'est du pull, mais ça ressemble
furieusement à un push quand je peux

watch une resource et surtout quand
elle est quand elle est dedans.

La différence c'est que t'as pas de
reproductibilité de ton cas Cqrs

Tu vois ce que c'est que cqrs?
Ben oui, mais tu vas encore pouvoir.

Je pense qu'on a des gens qui savent
que c'est une façon de définir votre

flux de modification de la data.
C'est à dire que quand on s'est

mis à avoir beaucoup de place sur
les disques durs, on s'est rendu

compte que ce qui était intéressant,
c'était moins le monde tel qu'il

était que l'évolution des logs.
C'est comme ça qu'on a fini par

faire du machine learning.
Parce qu'en fait,

le machine learning, c'est une
évolution numérique en fait.

Autrement dit, il te faut un flux
dans lequel tu as l'ensemble des

événements de modification et cqrs.
Ça veut dire ou je sais plus le

c'est mais c'est selection query
et et je sais plus non plus.

Mais toujours est il que ton flux
cqrs, c'est le flux de l'ensemble

des ordres qui concerne ta donnée,
qui vont, qui vont, ce qui vont se

linéariser et qui sont dans un état.
Non, tu ne peux pas changer l'état.

l'Ordre dans lequel c'est fait,
c'est ordonné, c'est propre et

c'est ce qui te permet de
reproduire le même dans un système

où tu n'as pas ce genre de log.
Ça veut dire que tout étape de

forensics sera extrêmement pénible.
Et c'est pour ça que si tu veux,

j'ai un problème global avec la SNCF,
c'est que tu as énormément de

projets qui sont pensés pour le
ça va bien se passer et notamment

Prometheus qui est l'autre sujet
dont on pourrait parler des années

où il y a un énorme problème.
Le truc n'est pas capable de

prendre de la data,
ce qui veut dire que ton forensics,

tu ne l'auras jamais de ta vie.
Et donc en fait, pour moi,

tu as un agrégat de projets entiers
qui sont pensés dans un axe qui

pour moi ne règlent pas les soucis.
Alors oui, quand tout se passe bien,

vous êtes démodé.
Oui mais en fait le truc c'est

que moi je les ai réglés les
soucis à mon échelle.

Et aujourd'hui le problème que j'ai,
c'est qu'il faut que je prenne

mon modèle qui marche,
qui est sémantique,

qui est propre et que je le casse
en permanence pour faire rentrer

un carré dans un rond et qu'on me
dit en permanence sur Twitter Quoi,

tu n'utilises pas Kubernetes?
Mais pourtant tu devrais l'utiliser

et d'ailleurs tout le monde dans
ta branche le fait alors que

personne dans ma branche.
C'est à dire qu'on a un problème de

bruit autour de cette technologie
là qui peut régler des problèmes,

mais des problèmes pas si grands,
pas si pertinents,

pas si importants que ça.
Alors c'est une technologie qui

certes dans certains cadres peut
aider.

J'ai été foutu de la prendre
sous cube pour rigoler.

C'est très pénible parce que du
coup c'est le machin qui sonne le

plus souvent dans mon monitoring.
Mais vas y je t'assure,

c'est ça dépend mais j'ai vu des
install cube complètement merdiques.

Il y a des gens qui font des
talk meetup pour expliquer

comment faire du cube.
Tu regardes ce qu'ils ont fait,

mais surtout pas le problème de
parler d'une techno qui by design.

Tu as tellement moyen de t'en
servir n'importe comment.

Prendre une technologie respectable
actuellement, tu vois, prenons Rust,

c'est quand même un techno où dès que
tu mets un point sur la ligne jaune,

le compilateur t'engueule.
Ça,

c'est une technologie que je trouve
incroyable qui va changer le monde.

Bon d'accord, mais alors recompile
Kubernetes en Rust et je te promets

que tout le monde te suit peut pas.
C'est un tas de galimatias,

de lignes de go.
Et par ailleurs, il y a un autre

problème dans le fait de recompile
quoi que ce soit dans Kubernetes,

c'est que le projet est tellement
politique que ça me rappelle la

grande époque de l'open stack où
le moindre commit dans OpenStack,

tu as plus de négos politiques que de
technologie et c'est la même chose.

Tu veux faire passer aujourd'hui
des commits donc tu ne peux pas.

Je confirme.
Et donc tu es sur un projet qui

est fauxpen source dont les
implémentations les plus utilisées

sont en fait des implémentations
qui ont été bricolé en interne.

Donc GK en est une et c'est pour
ça qu'il va en Antho parce que CG

Canyon c'est littéralement En fait
c'est pas cube donc tu es sur,

tu es sur un mouvement assez blessant
tu vois je trouve, tu ne peux pas

aller commiter dedans et en plus
le truc est d'une politique.

Enfin genre tout ce qui faisait
OpenStack pour avoir connu la

grande époque de OpenStack.
Clairement, Kubernetes essaye de

ne pas ressembler à OpenStack pour
une raison et une énorme qui est.

Tu pourras dire que le Cncf ressemble
au projet Tante sur sur OpenStack,

mais à ceci près que déjà un il
n'y a pas de verrou technologique.

C'est que avant, on se souvient
OpenStack, tout devait être fait

en Python et uniquement en
Python et qu'on est tout Python.

Beaucoup de projets de la SNCF
qui sont fait en autre chose que

le client.
Le meilleur projet de la SNCF,

clairement.
Je veux dire, si tu as besoin d'aller

écouter des logs à peu près une ligne
de logs à la seconde, ça marche.

Et pour les parties critiques,
bah non mais non,

il y a les parties classiques.
Non c'est vrai, c'est vrai que la

plupart, la plupart des systèmes,
il y a une espèce de pattern sur les

collecteurs de logs parce que c'était
la même chose, c'était du rugby.

C'est juste que Logstash les mecs
avaient dit non mais c'est en Ruby,

mais c'est fait pour tourner sur
git Ruby.

Du coup ça semble aussi donner la
parole, genre il fallait quand

même vraiment il y a des gars,
il y a les gars qui ont c'était fait

pour tourner sur Jruby alors ça
a toujours été fait pour tourner

sur Git Ruby en first Deployment,
ça a toujours été pensé comme ça

et et c'est pour ça que ça
tenait la charge.

Et oui, la machine Ruby,
enfin Ruby en tant que langage et en

tant que écosystème a plein d'intérêt
et Ruby en tant qu'écosystème,

surtout en tant que écosystème,
ça a été génial.

Et merci à Word et merci à plein
de trucs.

Cela dit, la portabilité du Ruby,
certes en Step One,

elle fonctionne en step deux.
Dès que tu commences à utiliser

des trucs un peu touchy,
tu étais sûr que tu es obligé de

recompiler pour pour des plateformes
X ou Y enfin rencontrés de près.

Il y a un autre souci la
librairie Elastic.

Certes en rugby elle est merdique,
elle appelle l'alizé et compagnie,

mais ça c'est un autre souci.
C'est qu'en fait en rugby,

comme tu as des problèmes de perfs
du renard, du coup tu as des gens

qui vont faire des pas chassés.
Le problème c'est que c'est des

développeurs rugby qui vont faire
le patch, donc pas nécessairement

des développeurs C.
Après,

j'ai beaucoup de griefs contre C,
donc après on peut me lancer sur C.

Et donc du coup tu te retrouves
avec un problème qui est que tu

as un mélange des deux et tu as
ce problème là.

Et du coup ce problème là,
il se répand à un moment où tu

compiles en jruby et là du coup
les parties en C, tu es obligé

de les appeler en jihna et.
Et les conteneurs, c'est bien parce

que à ce moment là et non les
conteneurs ne règle pas le soucis.

Ta stack techno est toujours une
énorme merde, c'est juste que tu

as fait un joli paquet rose au
moment où c'est tombé en marche.

Tu as fait des photos?
Ah putain, vas y!

Genre gros modèles justement,
les photos, les photos.

Ben nous on a fait ça, donc pas
de photos encore, mais ça va.

Encore une fois, vous êtes, vous
êtes dans la perfection et dans la.

On n'est pas dans la perfection.
Nos clients à nous, ils sont

répartis dans 50 pays dans le monde,
Ils sont des milliers, différents,

ils codent pas du tout tous pareils.
Et donc ce que je veux dire,

c'est que mon modèle à moi,
il fonctionne à large échelle,

c'est à dire qu'il fonctionne avec
des gens qui ne se sont jamais

rencontrés, qui à large échelle.
Le client est ce qui marcherait à

large échelle d'entreprise, c'est à
dire vraiment vous en tant que tel.

C'est à dire je te mets 100 000
développeurs, 100,

c'est une question,
c'est ce passage à l'échelle entre

guillemets. C'est une blague?
On est entre nous,

c'est si tu veux, si demain on
me donne 100 ou 200 développeurs

de plus que j'ai sélectionné.
Non, non, c'est la question.

C'est pas ça.
Si, si, demain on prend ta

technologie et on la balance chez
Microsoft, je prends ta technologie,

je la mets à la BNP.
Il se trouve que ma technologie

est à la BNP et ça marche.
Je reçois la BNP, bien sûr,

mais tu me demandes à la Belle parce
qu'elle est à la BNP et ça marche

avec des scale scale à la BNP.
C'est à dire ça marcherait si tu

mettais plus de serveurs,
Enfin si tu veux.

L'idée, c'est que l'idée c'est qu'à
partir du moment où tu répands ta

technologie, tu n'en es plus maître.
Donc tu es obligé de.

De la diluer,
de prendre des raccourcis et de

et de faire des choses.
Non mais toi, aujourd'hui tu es

maître parce que tu es.
C'est ton offre commerciale,

c'est ta technologie,
c'est ton c'est ta vision.

Mais et qu'elle convient à mon
entreprise, Elle convient à des

objectifs business,
techniques et compagnie.

Mais aujourd'hui, Kubernetes,
ça ne peut pas convenir à une

vision vu par essence.
Par nature, c'est fait pour tout le

monde et puis pour tout le monde,
sauf sauf les clients qui n'ont

pas le droit de commiter.
Et maintenant je veux bien qu'on

entende le disque,
mais c'est en fait,

c'est mon vrai projet OpenSource.
Premier kernel Linux 1200 développeur

qui collabore sur des cernes de
trois mois et qui réalise des

trucs avec des gens qui ont des
problèmes extrêmement variés.

Tu as des gens qui font de
l'embarqué, tu as des gens qui font

des serveurs haute performance,
tu as des gens qui font du temps

réel, tu as des gens qui font
des HPC et tu as des gens qui

font tourner des Raspberry Pi.
Les besoins sont extrêmement variés.

Résultat des courses,
le machin fonctionne les mecs,

pour le coup, non, c'est exactement
pareil et pour le coup d'expérience,

mais vraiment d'expérience.
Moi je connais des gens qui mettent

du Kubernetes dans des avions et dans
des avions de ligne dans des Airbus.

Oui, alors là moi je les prends plus.
Alors ne prends plus les Boeing

non plus.
Non mais non, mais à l'heure

actuelle, ça fait tourner le
système média. Oui, tu vois.

Enfin donc encore une fois, on est
sur le marketing du du t'as vu,

ça fait tourner des avions, on va
tourner des avions, ça fait tourner.

Le X était dans des avions bien
fait donc ça fait tourner Google,

sauf quand ça fait pas tourner
Google, on est d'accord, ça fait ça.

Alors pour le coup, je me suis dit
qu'il l'utilisait chez Google,

il l'utilise et en plus c'est
même pas moi qui disait ça.

Sous entendu c'est même pas moi,
c'est pas moi qui avait cet

argumentaire là.
Je t'ai dit que l'argumentaire

ça tourne chez Google était pour
moi un argumentaire faux.

Je me souviens du débat pepettes
vs chef vs sensible et tout le

monde était ah ouais mais moi mon
truc il est utilisé chez Google

mais en fait tout le monde
pouvait répondre la même chose.

Donc donc le machin est là, ça fait
pas tourner les avions parce qu'en

fait ça fait tourner les systèmes
médias des avions dans des avions.

Et en fait en gros,
c'est juste le spectre.

Tu m'as dit tout à l'heure les
Raspberry Pi, les Raspberry Pi, il y

en a qui mettent des cubes sur des
Raspberry Pi et ça marche très bien.

Non mais je sais que ça tourne
sur des Raspberry Pi.

Ce que je veux dire?
Tous les endroits que tu m'as

dit tout à l'heure, ça marche.
Oui, mais lancer des binaires,

c'est lancer des binaires.
La différence est que le kernel fait

quand même beaucoup plus de choses vu
qu'il gère le hardware. Heureusement.

Donc on n'est pas du tout sur
les mêmes choses.

Quand je te dis c'est un projet
qui est open aujourd'hui,

tu peux aller contribuer dans le
kernel, c'est facile.

Je vois quand même un avantage,
on t'en a pas parlé avec

l'extensibilité et compagnie,
mais surtout, c'est un outil.

Et comme par essence,
n'importe quel outil, que ça aille du

marteau au tractopelle jusqu'à la
fusée Saturn V, c'est fait pour.

Pour démultiplier la force et
l'effet d'une personne.

Et aujourd'hui, cet effet là,
il est complet.

Pour moi, c'est une réussite totale
bien sûr, et la scie cloche aussi.

C'est juste qu'aujourd'hui on me
présente le truc comme étant le

couteau suisse.
A mon humble avis, c'est une scie

cloche, éventuellement c'est une
scie cloche qu'on pourrait déplier,

ça coupe des trucs.
Non, ça ira pas plus loin.

Il y a cinq ans de ça, il y a cinq
ans de ça, quand il a été créé, oui,

c'était un outil qui répondait qu'à
une seule chose à l'heure actuelle,

vu l'extensibilité de l'API Server,
clairement, c'est un couteau suisse.

Il est devenu ici avec, il est
devenu, il est devenu cette humanité.

Bon ça il y a toujours pas
d'unification du monitoring.

Je vois pas comment les opérateurs.
Le premier opérateur ici, il est

stable, il est opérateur sérieux.
On peut vraiment faire du

monitoring sur Prometheus, c'est
vraiment Monitor, c'est dynamique,

on est vraiment en train de parler
de ce machin là. Oui, vraiment.

Et alors là, pour le coup,
par rapport c'est vrai que je parle

de boite où le monitoring passe
dans des logs et c'est des boites.

Encore une fois,
c'est pas parce qu'il y a des

gens qui font n'importe quoi,
mais justement c'est la majorité,

c'est la majorité.
Et alors du coup on va aller

vers un truc médiocre alors
qu'il y a des trucs très bien,

Aller vers du mieux c'est,
c'est pas médiocre en fait,

c'est ça le mieux, le mieux en fait.
En gros, à l'heure actuelle,

c'est que tu as une vision,
tu vois le haut du panier, on est

tous d'accord avec ceux du haut.
Oui, mais tu comprends,

tu comprends que le problème qu'on
a est que aujourd'hui, à force de

faire le battage de cette techno là,
c'est que nous, pendant ce temps là,

qu'est ce qu'on fait?
On attend que les gens améliore leur

truc, contribuer, contribuer à ça.
Comment on fait pour contribuer

à cette technologie?
Parce qu'aujourd'hui personne ne

fait sa vie dessus.
En fait, si tu veux,

c'est très simple, un hébergeur pour
un hébergeur, c'est plutôt simple,

c'est pour un éditeur de logiciel,
C'est pas simple du tout ton

hébergeur, tu peux très bien
gagner de l'argent en proposant

des Kubernetes, C'est non.
Je vais en gagner un peu et ça va

me coûter une fortune en support.
Aujourd'hui, chez Clever Docker,

c'est à peu près 8 % de run time,
40 % de demande de support.

Ça, c'est la réalité des conteneurs.
Tu vois, moi c'est pour moi,

c'est catastrophique.
Pourquoi c'est le cas?

Alors moi je suis entièrement
d'accord avec toi.

Et enfin avec ça,
c'est le pourquoi. Pourquoi?

Parce que, en fait,
la notion même des conteneurs et

la notion même de Kubernetes,
c'est que, à la différence du passe,

c'est que à mon sens,
c'est phrasèmes complets.

Alors qu'est ce que, qu'est ce que
j'ai inventé en notant ce mot là?

C'est que tout comme dans la dans les
phrases complètes, en fait, c'est

que tu connais le Turing complet.
Ouais, et ben en fait c'est la même

chose pour de l'infrastructure.
C'est que moi,

demain tu me donnes un passe dans
lequel je peux pousser mon code,

c'est que est ce que je peux
pousser n'importe quel code dans

n'importe quel langage sur ton passe?
Elle est là la question Almost

almost?
Et c'est ce almost là qui te

répond avec du docker.
Le problème c'est que Docker en fait,

si tu me dis n'importe quoi dans
n'importe quoi docker, tu ne peux

toujours pas les supporter dans
Docker et donc ça ne marchera pas.

Alors c'est que si par ailleurs
ce que tu appelles le complet,

c'est se balader avec un t shirt
qui dit je suis la personne qui

jette les pull request des gens
de systemd, c'est être complet.

Je suis pas sûr que ce soit les
plus grands instants de gloire.

Non mais c'est pas c'est pas le nom.
Puis en plus comment ça anecdote a

toujours été la personne open et en
plus elle ne l'est pas forcément.

Mais tout comme Turing n'était pas.
Enfin genre Turing n'était pas une

personne à mon avis agréable à
fréquenter tous les jours, je sais

pas voilà. Mais je sens tout ça.
Je comprends pas pourquoi.

Alors c'est juste fallait
trouver un nom et voilà.

Et tu avais de la chance,
j'ai le choix entre être Hightower

et Fraselle. J'ai choisi Fraselle.
Non mais je plaisante, si tu mets

Cube dans un avion parce que là
du coup, je peux croiser Casey.

Sans déconner, tu comprends de
quoi parle de quelques années?

Parce que honnêtement, Keyser,
très sincèrement, tu sens que le

mec qui il passe un temps fou à
discuter avec des gens etc.

Mais je pense que ça fait très
longtemps qu'il n'a pas tapé la

moindre ligne de code pour le coup.
Alors c'est peut être parce que j'ai

pas tapé assez de lignes de code,
mais ça date d'hier donc peut

être c'est pas assez longtemps,
mais si clairement.

Enfin moi je comprends ça parce qu'en
fait le truc c'est que en effet,

c'est une notion d'écosystème et
sans doute que notre écosystème,

et c'est ce qui se passe à
l'heure actuelle dans même la

compréhension qu'on a de Kubernetes.
Même expliquer Kubernetes à

quelqu'un.
Maintenant,

expliquer que ce n'est pas un cas,
je passe mes journées à ça,

donc sans doute que oui, on est
parti trop loin. Kubernetes c'est.

Alors j'en suis ravie.
Pour moi,

Kubernetes est en train de le faire.
Enfin, il fallait qu'il fasse

depuis le début qu'il est en
train de OpenStack, mais c'est

d'une complexité monstrueuse.
Et aujourd'hui, il y a des gens

qui vont faire main basse.
Justement, on aimerait devenir un

framework et fin de l'histoire.
Mais il faut dire que j'ai vécu

les deux.
Comment on peut dire que

Kubernetes est complexe?
Kubernetes c'est fondamentalement

c'est quatre composants,
peut être cinq si on compte Etcd,

mais c'est l'API,
c'est le scheduler, le contrôleur

manager et un ou plusieurs kubelet.
C'est des trucs dedans et

pénible en fait.
Non, non, non, non, non, non,

non, non, non.
En termes de en termes de complexité.

Juste de comprendre comment les
choses peuvent faire tourner

dans Cube.
J'ai failli manger un OpenStack,

j'ai jamais fini la doc.
Enfin non,

mais il faut juste en arriver là.
La première version de serveur

et pendant des mois, les gens
attendaient au dessus D'openssl.

Et un jour je suis rentré dans
le bureau et j'ai fait Bon les

gars dans un mois et demi machin
dégageait alors Alors bon,

moi mon premier projet Cube
c'était d'installer OpenStack avec

Hibernate et ça marche très bien.
Mais vraiment très très bien.

Bon, la boîte qu'il a fait est en
train de tomber, mais encore pas

à cause de problèmes techniques,
mais à cause de problèmes

managériaux. Et c'est encore le cas.
Tu as, tu as, tu as.

Le rituel est vraiment un
logiciel vraiment très simple.

C'est pour ça que c'est une
brique que tu peux mettre

facilement sur des Raspberry Pi
que je veux dire sur Cube.

J'ai cru que j'allais mourir,
mais le problème c'est pas c'est

pas grave, c'est pas.
Je vais te dire, je connais des

clusters à base de 259 qui ronronne
et qui sont gérés par une personne en

carton parce que c'est des clusters.
Là pour le coup d'une centaine de

nodes de cubes à des personnes pour
les gérer et ça je le reconnais et le

truc tourne et il est extrêmement
propre, je peux te montrer.

Et en plus le pire c'est que ça
peut tourner très vite.

Tu es en train de démontrer ce que je
pense depuis le début. Personne.

Faire une mise à jour,
personne s'occupe du monitoring.

Quand je te parle d'avoir des
gens en carton, c'est parce que

ça veut dire que c'est les gens,
c'est pas leur boulot au quotidien,

ils font tourner les machins et
par contre ils ont la

responsabilité du fait que ça.
Ce qui veut dire que la mise à jour

est possible quand il y a plus
personne. Et ça je le vois très bien.

Des boîtes qui mettent des trucs
au cube et qui se disent à partir

de maintenant ça va, on fera pas
les mises à jour d'image de base,

on fera pas les mises à jour de cube,
il y aura des mises à jour de que

dalle. Mais, mais, mais, mais c'est.
Ces gens là faisaient déjà de la

merde avec Debian avant et moi à
l'heure actuelle.

Mon principal problème quand j'amène
Cube et c'est justement ce stress,

maintenant ils font de la merde
avec Cube.

Génial, On continue à tenir mon
discours qui est de dire je pense

que ce n'est pas une légende,
c'est de la merde.

Les gens qui faisaient de la merde
avant, ils continueront de faire

de la merde après, c'est pas grâce
à l'outil qu'ils en font plus.

Donc je reprends l'exemple de techno,
ils en font moins qui enferme

les gens, Tu prends,
tu prends du SQL, tu mets des

contraintes dans toute la base.
Je fais un jeu de contraintes

propres dans la base, personne
est capable de détruire la base.

Je prends le concept de boîte à
outil de cube faire juste les mecs,

faire juste le redéploiement en cas
d'échec, faire juste je sais pas

qu'est ce qu'il peut y avoir d'autre,
Le scaling et compagnie,

Les actions c'est une charge.
Ouais ouais, des trucs comme ça.

Et faire juste des actions de base,
mais de base sur n'importe quel

n'importe quel déploiement d'une
application à la con,

d'un webservice ou peu importe.
En admettant à l'époque, à l'époque,

avant que tout ce qu'on a dit, donc
en fait n'importe quoi. Ah d'accord.

Donc on met entre parenthèses la
sécurité aujourd'hui.

C'est le cas dans les entrevues,
vu que le système est mathématique,

on met, on met entre parenthèses la
réutilisabilité de la sémantique

ISO périmètre déclarative.
Et ça, en terme de sécurité, permet

déjà de savoir qu'aujourd'hui il y a
des innombrables petites actions.

Je termine ma phrase s'il vous plaît.
Il y a d'innombrables petites

actions qui sont qui sont
chipées avec l'outil.

Tu vas me dire avec aussi
n'importe quel outil, ça pourrait

être nomade et peu importe,
mais très bien utilisé en nomade.

Je ne suis pas contre, mais qui sont
shippé avec l'outil qui aurait été

faite par des scripts à la con,
par des trucs inventés à la

maison et par des trucs bien plus
dégueulasses que Kubernetes.

Je pense qu'en fait j'ai enfin
touché du doigt le problème.

Vous êtes traumatisé d'avoir vu des
infrastructures, mais lamentable

face au mauvais sens du management
et des infrastructures sans amour.

Je vous invite à venir voir ce
qu'on fait.

Parce qu'en fait l'histoire c'est que
moi, quand je juge une technologie,

je ne dis pas ça a tellement été
nul à chier ce qu'on a fait jusqu'à

présent, que gagner, ça m'intéresse.
Moi, ce que j'ai envie, c'est de

faire des technologies qui gagnent.
J'ai envie de faire autre

ethnologie qui règle
définitivement des problèmes.

Vous savez combien Adobe chez
moi ne fait pas 40 pour gérer

l'ensemble de Clevercloud?
Oui, ça me paraît pas déconnant.

Gérer 8000 machines, il n'y en a pas.
Il y en a parce qu'ils n'ont pas

le titre, vous savez.
Non, non, personne n'a comme boulot

de se connecter à une machine.
Une connexion SSH en Admin, chez

nous c'est une alerte de monitoring.
Lol non je te disais tout à l'heure

le zéro ssh c'est une philosophie,
mais moi moi le talos,

c'est le système dont je t'ai dit
tout à l'heure c'est un système,

il n'y a même pas de shell dessus.
Genre le système c'est un init

qui boot un process en API et une
fois que tu lui as communiqué,

il se coupe Talos.
C'est Il y a même pas de Shell et

même pas dans tout l'os, y a même
pas de shell pour s'y connecter.

Se connecter sur une machine,
c'est une hérésie.

J'ai toujours dit et j'ai
toujours dit dans toutes les

boites on est passé tant mieux
que vous y seriez arrivé.

Mais bon,
c'est pas ça la définition d'un os.

La définition d'un OS,
clairement, c'est pas le gars

qui se connecte en SSH,
même pas le gars qui est d'astreinte.

Ça c'est le techos d'astreinte.
Là dedans, nous on l'appelait, je

sais même plus comment on l'appelait.
Mais ouais, mais l'OP c'est

celui qui a la capacité à
comprendre le sous de la base.

Et la brique sous jacente c'est
et vous chez vous c'est génial,

c'est que vous avez eu des gens
qui sont capables de comprendre

la prog et qui ont construit un
peu ce qu'il y avait au dessus.

Ben ça c'est génial pour moi,
mais c'est vraiment,

vraiment très bien, C'est là dessus.
Et quand aujourd'hui les gens bon,

ils sont chez toi,
enfin moi dans toutes les bases,

mais n'importe qui peut être bon,
c'est un problème de travail,

mais si tout le monde peut être bon,
moi j'ai vu des tonnes de boîtes

et moi ma pensée c'est que tout
le monde peut être bon.

Et je pense qu'aujourd'hui,
quand on prend des ops et qu'on

leur dit ta mission à partir de
maintenant, c'est d'avoir une

communication sensée avec les
dev sur l'entrepôt de données.

Pourquoi, Dans quel sens faire
de l'archi avec eux,

expliquer comment on achète du matos,
calculer les TCO parce qu'on va pas

parler des envolées de coûts sur sur
les clouds publics et en particulier

Amazon faire de la protection de la
data parce que je parle même pas

de la qualité aujourd'hui de la
protection de la data européenne

vis à vis des Etats-Unis.
Enfin tu vois, on a un certain nombre

de problèmes et aujourd'hui on leur
dit pas ça, on leur dit Bah va

faire joujou avec ce nouveau toy,
ça s'appelle Kubernetes,

tu vas réapprendre le monde et
en fait rien ne va changer.

C'est à dire, au lieu de faire
apt get install, les maîtres font

kubectl quelque chose. Ok, cool.
Mais alors, alors, Alors on ne

va pas régler le problème.
Alors détrompe toi.

Alors moi c'est par exemple quand
je fais des formations Kubernetes,

quand je fais des formations
Kubernetes, j'ai trois tracks,

j'ai une première track,
une première et une deuxième

track dev et une track SRV.
Et alors la distinction entre les

trois, elle est claire et je pense
qu'elle répondra à ton besoin.

Celle que je déteste c'est la track
op et en fait je l'ai appelée OP

parce que ça c'est les gens qui
vont maintenir le cluster.

Et c'est ça d'ailleurs qu'on me
demande le plus,

c'est celle c'est comment j'installe
mon cluster moi les gars,

ils sont en train de se palucher,
de savoir est ce que je vais utiliser

Ansible, Terraform machin etc.
Parce que je leur dis à chaque

fois c'est installer le cluster,
c'est 1 % du temps, le plus

important c'est le run, c'est qu'est
ce que vous allez mettre dedans?

Mais je le fais quand même,
les gens le demandent.

La frag dev c'est comment?
Je déploie comment?

Enfin pas comment je déploie,
c'est comment je travaille et

q26 comment j'arrive à débugger
et comment j'arrive à aller

chercher des logs, comment
j'arrive à avoir du monitoring.

La plupart du temps, les gens ne
savent même pas ce que c'est.

Donc là je demande ça, mais avec la
plus importante que je fais le moins.

Mais la track la plus importante
c'est la tracasserie.

C'est de dire tout ce que tu viens de
dire c'est comment je maintiens,

mais comment je maintiens mes
applications, comment je le monitor

bien, comment je fais mes upgrades,
comment je, comment je j'audite

ma sécurité, comment je fais ça?
Ça pourrait être la personne qui

fournit des dashboards de reporting
de l'activité qualitatif et qui

aurait une discussion positive
avec les devs sur le fait

d'implémenter des métriques à la
fois techniques et métiers dans

l'appli qui cracherait des métriques.
Les crashs en Prometheus, se crasher

en stase, en JMX, je m'en fout,
nous on fournit tous les modèles.

Mais tu vois par exemple
aujourd'hui grapher un utilisateur

c'est connecté, mais juste ça.
Tu vois cette action de login,

Il y a combien de boîtes dans
lesquelles c'est fait?

Zéro Parce qu'au lieu de ça,
les mecs sont partis faire joujou.

Alors à qui fera du cube, à qui fera
du nomade, à qui faire du machin?

Et moi, ce que j'offre aux gens
comme techno, c'est à un moment où

ils ont plus besoin de faire ça.
C'est à dire que ta track de

comment on gère le cluster,
c'est pas un problème,

laisse les robots le gérer.
Pourquoi ça ne marche pas comme cube?

Parce que ça n'a rien à voir.
Nous on fait de l'AA,

c'est le bordel, c'est ça qui est.
C'est ça qui est bien, c'est que à

l'heure actuelle et d'ailleurs c'est
le talk de Leslie Tower à la dernière

keynote de la Kubecon San Diego,
Il va dans ton sens, il dit et moi ce

que j'arrête pas de dire, arrêtez
de vouloir proposer Kubernetes par

défaut aux utilisateurs Kubernetes,
c'est un builder d'infrastructure.

C'est que moi, si jamais demain
je voulais te concurrencer,

j'utiliserai en brique sous jacente.
Mais aucune sécu, aucune perf,

mais aucune rien.
C'est juste des conteneurs,

mais non, le container ou
n'importe quoi comme ça.

Et je règle pas tous les problèmes.
Non mais si vous voulez faire la

même chose, faudrait que tu réécris.
C'est ce que tu as fait,

Tu as dû réécrire.
Je le réécris en utilisant la

sémantique mais juste.
Le problème c'est que la sémantique

de cube a été pensé uniquement
pour un seul déploiement.

Le jour où tu m'amèneras un
modèle de runner propre,

je te dirais parlons en.
Le problème c'est qu'aujourd'hui il

n'y a qu'un seul runner dans Cube,
c'est de faire du container.

Et en fait, la sémantique de cube
est orientée uniquement là dessus.

Parce que cube c'est une
solution pragmatique qui part de

la base et qui a été remonté.
Et en fait aujourd'hui, quand je

te dis tu manipule des binaires
et des numéros de ports, ta beau

m'expliquer c'est une modélisation,
c'est pas une modélisation,

T'as pas modélisé ton problème
pour redescendre dessus,

Tu me dis moi j'ai besoin de lancer
des binaires sur tel port et du coup.

C'est ça que je mets dans le
manifeste.

Et en fait, si tu veux ton
problème il est là, c'est que tu

me dis ce serait extensible,
Fine, fait le, montre moi.

Moi aujourd'hui, j'ai analysé la
sémantique du truc dans l'espoir

de pouvoir utiliser le machin à
la place de me faire chier à en

maintenir ce que moi ça m'amuse
pas du tout d'en maintenir un.

Qu'on soit très clair sur
l'opération, ça me casse les couilles

parce que ça me coûte de l'argent.
J'ai décidé de ne pas m'en servir

parce que la sémantique du truc était
pétée, parce qu'encore une fois,

c'est un modèle empirique qui n'a
pas été monté d'après des gens

qui faisaient de la vraie prod.
La première version, c'était des gens

qui en fait voulaient concurrencer,
c'était des dev réels qui écrivaient

ça chez Google pour concurrencer
les gens de chez Docker.

Et petit à petit, ça agrège.
Mais il n'y a pas un moment où tu as

un comité technique de gens qui se
sont mis à penser le truc de façon à

ce que ce soit bien pensé dès le
début. C'est une accrétion, non?

Dans le tas il y a des trucs bien,
je te dis pas le contraire et

c'est pour ça qu'on va le
proposer à nos utilisateurs.

Parce que je pense très sincèrement
que le plus d'usage qu'on aura,

et ça, ça peut te faire chagrin
si tu veux, moi, l'usage qu'on

me demande aujourd'hui, le plus,
c'est d'utiliser Cube pour pouvoir

lancer le Elm qui permet de lancer
Open face. Et c'est magnifique.

Alors en fait, ravi,
là pour le coup, ils ont perdu si

jamais ils font de l'open face.
Mais c'est Ah mais non mais d'accord,

mais donc les gens ne devraient
pas faire d'elm mais les gens ne

devraient pas faire de machin et
les gens ne font pas ça.

Non mais les gens font du open face
avec du matos dessus, tu vas voir.

Mais bien sûr, mais, mais, mais,
mais parce qu'on a une trans,

parce qu'on a une transition.
Et moi, à l'heure actuelle,

quand les gens tu vois,
genre des trucs géniaux quoi.

Moi j'écris pour trouver une bonne
techno, c'est bien, sauf que c'est

quand même hyper opiniated, c'est à
dire que Jenkins x Si tu le fais

pas tourner sur Gke, ça marche pas.
Et si tu fais pas avec du github

même pas entreprise, ça marche pas.
Donc c'est marrant, il y a de bonnes

idées, c'est très amusant mais
ça va être bien pour l'instant.

Si tu veux, ça correspond quand même
au cas de start up dans la vallée.

Moi je regarde GitHub,
moi je regarde Tekton surtout.

Tekton est très intéressant mais
pour l'instant Tekton ça marche pas.

Ah mais je suis d'accord, je regarde
Tekton, j'ai bien dit je regarde.

Ouais non mais si tu veux que
tous les projets de la SNCF me

font un jour, ce sera génial,
On va en profiter, ce sera génial!

Alors ok, je fais de
l'agrégation dans Prometheus,

j'ai huit verres pour le cul
pour le cul et pas dans le SNCF.

C'est pas non, c'est dans la.
Dans la série Fondation de la

série Cl Fondation.
Non, non, je crois que c'est Tekton

pour le coup, comme ça appartient à
Google, ils veulent pas du tout.

C'est fact-checking.
Non non non non mais tu peux

checker Mais en fait je suis sûr
de mon coup maintenant.

Moi je suis la série Fondation.
En fait, Jenkins avec quelques autres

ont lancé une fondation, mais c'est
quand même beaucoup de Jenkins.

Enfin Cloudbees qui la pousse et
c'est une fondation autour du SI,

c'est aussi une fondation fille
de la Linux Fondation Machin et

en même temps non, non.
Alors à voir,

Mais à mon avis et à mes souvenirs,
Tecton appartient encore à Google et

ne veut pas la filer, tout comme
qu'est Native, Native et Tectum.

C'est les deux projets que
Google a dit.

No way,
on vous le filera jamais Et c'était

très récent ça pour le coup, mais
mes jambes avaient été intégrées.

Parenthèse Prometheus, c'est quoi
le le grief contre Prometheus?

Parce qu'avant Prometheus
c'était quoi?

Il y avait Centreon, il y a eu un
petit coup de influence mais influe,

ça vivote, même si c'est
moyennement parce que tu prends

toutes les technos de monitoring
de merde parce que c'est vrai.

Oui, aujourd'hui c'est un énorme
pas en avant.

Enfin pour moi et je suis d'accord,
c'est un énorme pas en avant.

Si tu pars d'un fichier dans
lequel tu écrirais tes trucs et

tu ferais passer du grep dessus,
c'est un énorme pas en avant.

Il y a des fois le truc dégueulasse
qui faisait des trucs des dashboards,

ça te dit?
Non, Tu parles de la

réimplémentation de c'était pas ça?
Mais non Graphite, non,

je parle pas de graphite,
il y a des trucs comme ça.

Oui, il y avait Shinken,
mais tout ça c'est au dessus de

tout ce qui était Nagios.
Mais oui, Non mais attends!

Mais en fait le truc c'est soit tu
considères le marché des outils de

monitoring et là pour moi, face à ça,
les bonnes qualités c'était du

juridique, des choses comme ça,
tout ce que tu veux,

mais très bonne qualité.
Soit tu considères le marché du

Time Series DB et en fait ce que
tu fais c'est de la time série

et tu l'analyse.
Et en fait oui, ça veut dire que

peut être ça vient moins bundle,
mais je pense aujourd'hui que ce sont

des solutions qui sont en dessous.
Prometheus Les problèmes avec

Prometheus sont simples, si tu lui
en colle trop dans la tronche,

il est pas content, il sait pas
agréger parce que le moteur de

stockage de Prom il est pété.
Ensuite le moteur de stockage de

Prom est empty, il n'est pas
capable de prendre de la donnée

qui a plus de quatre minutes.
Ce qui veut dire que si tu as un

incident et que tu es un peu
favorisé, ta donnée au moment où

tu remets to live et où la donnée
arrive sur le serveur Prometheus

et tu as envie qu'elle aille sur
le serveur Prometheus parce

qu'en fait c'est ce qui va te
permettre de faire ton forensic.

Bah en fait le serveur te dit va
te faire foutre donc du coup tu

pourras pas le faire de Francis
qui pour moi dans un système de

monitoring est assez rédhibitoire.
Et après il y a le dernier point

qui est plus un problème d'analyse.
En promutuel tu as huit.

Moi, celui que j'utilise,
c'est un truc qui s'appelle Wharton.

Il y a 900 verbes et quand j'ai
besoin de faire de la mise de

tendance, de la window tendentielle
beaucoup de machins et où en plus

je peux rajouter des notions
géographiques parce que etc.

J'ai un truc qui tient la route
mes premiers.

Prometheus répond que la
première brique qui est enfin

Prometheus n'a jamais voulu.
D'ailleurs tu dis que le modèle de

stockage est pété, C'est juste.
Il est tel qu'ils ont voulu

qu'il soit.
Il répond que à un problème,

à un problème et un besoin qui
est je le co-localisé avec mes

applications et après derrière
tout ce que tu dis, d'analyse etc,

ça doit être fait par quelqu'un
d'autre et ils l'ont toujours dit,

ça a toujours été le but derrière.
En effet,

c'est peut être pas très tu vois,
il n'y a pas d'outil scientifique en

terme de mais parce que justement ce
truc là doit être fait par quelqu'un,

extraire les données une fois
qu'elles sont dans Prometheus et

de plus ça pose un vrai souci,
c'est plus lourd comme opérateur.

Une fois on l'a testé, on a joué
avec, tu sais faire des choses,

Tu vois, moi j'ai jamais compris
pourquoi il y avait de l'engouement

pour ce truc, bien meilleur que
beaucoup d'outils et beaucoup

plus pratique à mettre en place.
Parce qu'en fait,

dans la notion même de technologie
et d'amélioration, la misère,

nous on est au dessus d'Adobe.
Après,

je vais être franc avec vous Wharton,
aujourd'hui c'est un Java jar.

Tu n'es pas obligé de le lancer au
dessus de nous, nous lance au dessus

d'Adobe pour X raisons liées à notre
charge et Machin a plein de trucs.

Mais le problème c'est comment aller
chercher la donnée Prometheus.

La seule chose qui répond,
c'est comment aller chercher la

donnée dans son système de label.
C'est quand même le truc over

super puissant pour aller
chercher de manière horrible.

C'est juste Prometheus plus
Service Discovery, c'est tout ça.

Enfin moi c'est le protocole où
tu fais du pull.

Je suis toujours pas d'accord
parce qu'il est pas fait pour ça,

il est fait.
Après il y a d'autres outils,

il y a deux. Non, non mais non.
Le pull, le problème du pull.

Il y a un vrai souci sur le pull.
Le problème du pull,

c'est que tu Tu vas charger.
En fait, tu ne laisses pas

l'applicatif décider quand est
ce qu'il t'envoie de l'info et

donc tu vas le charger à des
moments probablement incongru.

Et donc au lieu de rentrer dans une
gestion saine de ton applicatif qui

par exemple peut être lié à ton GC,
tu vas là, tu vas le charger des

moments qui sont.
Le problème du pull,

c'est que du coup le mécanisme
de pull peut être lui même.

La problématique que tu repères
dans ton monitoring, c'est là où

ton acceptation en Satoshi et moi.
Alors c'est quand même des cas

aux limites.
Je dis pas que c'est des cas

impossible, mais de là où ton
monitoring c'est des cas que

j'ai rencontré plusieurs fois.
Oui mais comme tu as dit,

comme tu as dit au début, c'est ton
expérience n'est pas l'expérience de

tous et à l'heure actuelle Prometheus
oui pose des problèmes, mais en

gros c'est comme à chaque fois
c'est une espèce de loi de Pareto.

C'est à dire que si jamais de
80 % du problème,

j'ai déjà à un moment, à un moment.
Enfin, soyons clairs, tu peux

pas budgétiser dans Prometheus,
tu ne peux pas lui dire j'ai

besoin de points bien réguliers
pour me faire un joli,

mais ça c'est clair et net.
C'est pas oui, ça n'a pas été conçu.

C'est quand même un souci si tu veux,
aujourd'hui,

quand tu as besoin de faire ça,
tu peux pas faire de prédictibilité,

tu peux pas, tu peux pas tracer
des courbes dans le tu peux pas

suivre des cours et c'est pas
pour ça qu'ils disent d'utiliser

les compteurs et pas les jauges.
Enfin typiquement, tu peux pas faire

de prédictibilité dans Prometheus.
Il y a un deuxième problème et

pour moi le problème.
Donc il y a un problème d'accès à

la donnée qui n'est pas computer.
Et comme tu n'as pas de drain

facile de la donnée de Prometheus,
ça reste pénible.

Et après il y a un problème
rédhibitoire pour moi qui est

l'histoire de Forensics.
Tu ne peux pas imaginer un système

de monitoring incapable de prendre
les données d'il y a une heure.

Je suis désolé,
c'est pas possible parce que ça veut

dire que tu n'as pas de forensics,
donc ça veut dire que tous tes

événements sont incapables d'être
compris, même dans la fédération

et même dans la fédération.
Regarde comment fonctionne

Prometheus, mais enfin c'est pareil,
regarder pour avoir mis en prod

pas mal de fois mais tu peux pas
prendre de la vieille donnée,

je t'assure, c'est lié à son
modèle de stockage. Je te. Je te.

Je te jure que Prometheus Bound se la
donner qui a plus de quatre minutes,

c'est lié au système de stockage
de props si tu le stocke ailleurs.

Non mais c'est dans le sens où
il prend, il bufferise,

ensuite il crée des bugs de temps
et ensuite il te les compacts et

il te fait des fichiers avec.
Il lui envoie de la donnée.

Il ne peut plus réécrire dans
des fichiers sur lesquels il a

déjà flusher.
Et donc tu ne peux pas faire de

forensic sur une infrastructure
monitoré par Prometheus.

Après les gens font ce qu'ils
veulent, tu peux me dire oui mais le

forensic on s'en bat les couilles et
de toute façon les mecs à l'époque

ne faisaient pas de forensic dans
leur infra donc c'est déjà un mieux.

Ok, il y a pas de problème,
mais si en fait c'est vrai que

ça va être la réponse qu'on a.
Oui mais en fait je vous refais

ma réponse encore une fois,
on ne va pas défendre toutes les

technologies médiocres, mais en
fait en disant que les mecs mais

c'est pas grave mais c'est médiocre,
elles sont pas utilisables.

Voilà, c'est ça.
Et très sincèrement Warp aujourd'hui

tu sais, une technologie que je
trouve d'une accessibilité.

Oui, il faut prendre deux
minutes pour lire la doc.

Oui les mecs ont un problème
parce qu'ils sont huit dans la

boite et non pas 160.
Et donc effectivement parfois il

faut aller voir un tout petit
peu plus loin.

Mais si au lieu de passer son temps à
taper de la queue comme un castor,

à faire du rabattage sur tous
les projets à la mode et qu'on

allait s'intéresser deux minutes
aux technologies plutôt que de

prendre les technos à la mode,
ça pose. Un souci.

Enfin c'est quand même ouf,
je suis pas dans un podcast où vous

boudez, Non mais sérieux! Et hop!
Et c'est ainsi que j'apprends

que votre système de monitoring
ne peut pas faire de forensique.

Enfin,
vous vous rendez compte du truc?

C'est dramatique, Vous faites vos
choix sans jamais regarder le code du

machin. T'as lu le code de Prüm?
Tu t'en sers pour faire ton

monitoring, tu lis pas ton code.
Enfin, c'est aberrant.

Vous pensez comment? Mais parce que.
Parce que en fait, en gros,

ça va répondre au besoin qu'on a
à un moment donné qui est que

celui ci sait que si tu as un,
si tu as un problème dans ton infra,

tu n'auras aucune idée.
Mais non, parce que mon Prometheus,

il est co-localisé avec mon infra.
Et en gros, si jamais, si jamais le.

Si jamais le Prometheus ne
marche pas, c'est que mon infra

ne marche pas et en gros les
deux ne vont pas marcher.

Donc en gros les logs que je
vais avoir ne servent à rien à

ce moment là.
Donc clairement, moi un Prometheus

à l'extérieur d'un cluster Kube,
c'est une hérésie.

Voilà, Donc c'est à dire que ton
Prometheus doit être co-localisé

avec tes applications,
s'il lui arrive quelque chose,

il doit lui arriver la même chose.
Derrière, tu mets la fédération

avec quelque chose d'autre et oui,
lui il pourra avoir des problèmes

à récupérer et encore non,
je ne vois pas.

J'ai l'impression que tu l'aimes
et lui ne fera pas de trafic.

Mais c'est tu reproche à à la fin,
tu reproche à quelque chose qui est,

qui est communautaire,
qui est déployé.

Enfin le comment dire quelque
chose qui est de la popularité

de quelque chose.
Tu lui reproche sa popularité,

ça devient au bout d'une certaine
popularité, tu dis Mais merde,

il y a que ça,
il y a du battage et du marketing.

Alors certes, il y a beaucoup de
marketing, mais je pense qu'il y

a des réelles raisons que le
marketing peut apporter.

Il y a cinq ans,
parler de Kubernetes,

c'était c'était une barrière,
enfin c'était une barrière.

Moi, je me suis fait virer de boîte
pour avoir parlé de ça alors que les

gars utilisaient des grosses merdes.
On a eu l'effet inverse en fait.

C'est à dire que maintenant,
en fait, moi j'étais au début anti

inverse de mode de rejet qui est
lié à il y a trop de popularité,

c'est qui on passe à côté de toi,
tu passes à côté d'autres choses mais

on est dans la totalité là dessus.
Les avez vous avez dit?

Oui, je te comprends tout à fait
et je suis d'accord,

mais c'est moins moisi.
Si on faisait un monde n'est pas là.

Oui non mais d'accord,
dans ces cas là,

pourquoi vous en parler plutôt que.
Enfin, vous vous rendez compte?

Du coup, vous vous retrouvez dans
des infra où vous passez un temps

fou avec des gens où en fait on
pourrait les remplacer par une

install du soft et les mecs pour
aller faire des trucs utiles.

Mais avec qui vous êtes en train de
comparer des gens à des grille pain?

Mais c'est le cas, non?
C'est le cas à l'heure actuelle

et clairement même pour eux.
Pour connaître des gens qui

passent d'un passe à Kubernetes,
clairement ils gagnent du temps.

C'est le cas à l'heure actuelle.
Et ben ouais, on pourrait dire

sur quoi ils étaient sur.
Ah bah voilà. Et mais, mais, mais.

J'ai écrit un article un jour qu'on
n'a jamais publié chez Clever, qui

est le plus gros problème du pass.
Ça a été le demi succès des Roku

parce que le plus gros problème
du pass, c'est Kroku a fait un

tel toy de Fisher Price que pour
l'éternité ce sera un toy.

Et c'est pour ça que maintenant
nous on dit qu'on fait de la it

automation,
qu'on dit qu'on qu'on fait de la

de la High Augmented DevOps.
C'est parce que le terme de

plateforme de service a été tué
par les seuls gens qu'on fait un

peu de sous dessus.
Ils en ont même pas fait beaucoup.

Ils en ont fait un peu mais.
Et oui, c'est un drame.

Pour autant, si tu veux, prenons le
nombre de conteneurs, de systèmes

de conteneurs et d'opportunités
de conteneurs qui merdouillent.

C'est pas parce qu'il y a un
pass qui a été mauvais.

Non mais la question c'est est ce que
les mecs étaient sur Heroku mais

vient tester du clever à la place?
Tu vas voir, c'est du one drop,

t'en entendra plus jamais.
Mais non, parce qu'en fait,

en fait, ils ont besoin de tester.
En fait non mais.

Mais en fait le truc c'est que
par exemple, t'as déjà testé?

Je vais tester mais le
clevercloud le problème,

moi je trouve ça vraiment génial.
Moi je suis pour l'hétérogénéité

des solutions, c'est à dire en fait
à un problème son sa solution.

Des gens qui me disent j'ai
besoin de faire tourner que une

application que j'ai codé moi même,
que je sais comment elle marche etc

et que j'ai pas envie de me faire
chier avec les briques sous jacentes.

Je vais sur Clever et je sais que mon
truc restera toujours accessible dans

le cloud etc. De par les internet.
Très bien moi avoir une première

oui mais moi mon email dans un
avion je vais pas mettre

clevercloud dans un avion.
En fait c'est quoi en fait mon

prérequis pour le faire là?
Moi je te parle, c'est quatre

machines ARM, quatre machines ARM
de aucune raison que tes machines

ARM marchent par chez nous.
On a une version où on a fait du.

On n'a jamais lancé d'offres
commerciales parce qu'aucun client

n'a jamais eu envie de faire tourner
du ARM. Est ce que tu as une offre?

Comment on appelle ça Edge?
Non, pour l'instant, chez nous,

ça dure, ça dure. C'est à dire?
J'ai pas une connexion qui est

fiable. Exactement.
En fait, ce qu'on est,

ce qu'on est en train de pondre
sur cette solution là,

c'est une solution qu'on base aussi
sur notre fonction de service,

donc notre fonction de service.
On boot une machine virtuelle pour

chacune de tes de tes exécutions
de fonction pour te permettre

une isolation pure à la WS.
C'est des lambdas à la WS,

il te boot ton temps de lambda parce
que Firecracker met 135 millisecondes

à peu près à booter ton appli.
Et après tu as le problème de

ton appli parce qu'en fait ils
sont restés dans un système oui

Non mais nous c'est autre chose.
Et en fait nous on a un unique

kernel. Enfin c'est compliqué.
Enfin, j'ai donné un talk là

dessus au Blanc de Lyon si vous
avez envie de voir.

Et puis on pourra revenir pour
que je vous explique ce qu'on a

fait là dessus.
Mais on se construit là dessus.

On se construit sur un système de
bufférisation qui a été construit

justement pour des cas de edge.
Le produit aujourd'hui n'est pas

prêt, mais il est construit justement
pour des gens qui font de l'IoT avec

au cœur un système de réacteur d'Io
capable de faire de l'auto compute,

enfin toutes les technologies
que tu as faites, etc.

Enfin, elles sont vraiment géniales.
Enfin, je te veux,

je te linkerais des articles que
j'ai fait justement là dessus pour

expliquer une kernel à des gens qui
savent pas ce que c'est à des et

de dire vous devriez en faire etc.
Vous devriez en faire plus.

Moi je dis pas aux gens qui
devraient en faire,

Je pense que c'est une assez mauvaise
idée les trois quarts du temps.

Oui, les trois quarts du temps, mais
c'est extrêmement amusant à faire.

Mais, mais, mais même juste de
savoir, même juste que ça existe

en fait. Déjà, ce serait bien.
En fait, j'ai même un article

pour te dire Kubernetes,
ce n'est pas ce que vous pensez et la

première chose que je dis, c'est
que je réhabilite la virtualisation

et j'ai tout un article entier qui
réhabilite là dessus en disant

arrêtez de penser que c'est lent,
arrêtez de penser que c'est de

l'overhead. Arrêtez de penser rapide.
Oui, bien sûr,

mais je le dis et voilà.
Et je le dis là dessus pour

plein de raisons.
Moi KSM Alors il y a plein de

problèmes KSM mais j'aime bien KSM.
Je trouve l'idée de KSM génialissime.

Alors KSM c'est kernel, same,
same memory ou un truc comme ça.

Enfin bref, ça vous permet de
booter sur une même machine.

Plus de VM que plus de VM avec plus
de mémoire que la capacité totale.

La mémoire est balooning dans le
kernel on va dire aussi ça même

nous on l'utilise pas.
Il y a même en plus le

ballooning c'est encore en plus.
Mais la seule chose que le fait

du copy on write sur la RAM mais
c'est ça, c'est KSM qui le fait ça.

Ouais, nous on le fait pas que ça,
que ça m'a un peu pété en perf.

Mais oui mais on le fait au
niveau de l'hyperviseur.

Mais vous avez, vous avez, vous avez
des solutions. Donc en fait c'est.

Tu as fait dans ta boite un peu
ce que j'aurais rêvé faire il y

a de ça cinq ans on va dire là
dedans ou je ne sais pas,

et c'est vraiment très bien.
C'est vraiment une chose où vous

avez pris les problèmes de manière
ingénierie, vous les avez fait avec

les technologies disponibles à ce
moment là et vous les avez fait bien,

et vous avez répondu deux choses.
La preuve votre solution,

elle tourne. Voilà, c'est ça.
Moi, ma question c'est encore et

toujours maintenant quelqu'un
qui aujourd'hui 2020 se pose les

mêmes questions là,
avec un avec zéro, avec rien.

C'est à dire il n'a pas déjà
codé son kernel,

il n'a pas déjà sa distribution,
il n'a pas déjà tout ça.

Quels sont les choix qu'il peut
prendre?

Et bien en fait c'est là et moi
c'est là où j'interviens.

Et c'est là en fait que tout le
monde arrive.

Quelles sont les solutions
qu'ils peuvent prendre?

Kubernetes peut être pas parfait,
mais en tout cas,

ça répond instantanément à une
tonne des problèmes qu'ils ont

et ça leur permet d'aller vite.
J'ai modulo modulo aller chez

toi en plus.
Bah c'est simple mais je suis

d'accord, en fait c'est un peu à
un moment si tu veux,

mais ta solution elle peut pas, Je
peux pas tout mettre dans ta poche.

Moi je suis pas sur le cloud,
je fais comment?

Mais par exemple on a une solution.
Mais au delà, au delà de parler

de ce que nous on fait, c'est.
Vous vous rendez compte qu'en

passant notre temps à parler de ça,
on assassine tous les autres projets.

C'est à dire que tous les autres
projets aujourd'hui intéressants,

ils ont du mal à vivre parce que
comme on répète en boucle des

trucs et tu vois,
il y a des technologies, tu parles

enfin comme quoi par exemple en
fait c'est comme quelle technologie

la sur attention et la sur,
c'est ça qui tu regrettes au final?

Et bien sûr parce que la plupart
des gens qui en parlent ne l'ont

jamais lancé parce que tu vois,
on leur dit en permanence la le

go to go, ce serait ça.
Et tu vois, on a une discussion là,

je t'ai donné tous mes points sur le
pass et tu me dis effectivement,

pour faire un pass,
peut être pas ce qu'il faudrait,

mais alors il faudrait recoder.
Et alors je parle par exemple par

rapport à Cloud Foundry parce
que beaucoup de Cloud Foundry,

je préfère Cube mais 1000 fois
cube oui Non mais enfin Oui mais

c'est ça en fait c'est si si si,
Mais en fait, à l'heure actuelle,

il n'y a pas de technologie qui
à l'heure actuelle est un tant

soit peu concurrente.
Moi je pense qu'il faut regarder

d'où partent les gens,
d'où partent les IT,

d'où partent les infrastructures et
elles partent de mais d'un niveau,

mais au ras des pâquerettes.
C'est pour ça qu'on nourrit.

C'est ça qu'on vend Un petit
backup MySQL avec des sink.

Et encore une fois, la solution du
cloud n'est pas systématiquement

pertinente, loin de là.
Donc des fois, ce qu'on fait,

on pense que le TCO global,
il est meilleur ailleurs.

Et par ailleurs, si tu veux, quand
tu regardes, j'essaye d'expliquer

pourquoi il y a cet engouement,
pourquoi il y a cette auto auto

marketing et l'engouement.
Mais en fait, l'engouement,

il est quand même essentiellement
lié au budget marketing qui ont

été dépensés dedans et le fait que
du coup, dans l'infrastructure,

c'est un peu cynique, un peu le oui
complet, mais non, non, non, non.

Le budget technique,
il a été mis à partir du moment où ça

a commencé à marcher et vraiment pour
l'avoir vécu il y a cinq ans, mais

alors vraiment pour l'avoir vécu,
on était dedans aussi, vraiment.

Le budget marketing était à zéro
et nous on galérait mais genre

pour tout.
Mais en même temps, toi tu l'as vécu

dans ta boite ici en France? Non?
Non mais toi il y a cinq ans tu l'as

vécu dans ta boite ici en France,
C'est pas ici que s'est joué le

match. Le match.
Il s'est joué dans quatre pâtés

maison à San Francisco et je te
jure que là, le budget marketing,

il a été mis.
Il n'y a pas de discussion sur le

sujet et le budget marketing qui a
été mis sur Cube. Il est délirant.

Et aujourd'hui,
soyons très clairs sur Cube Cube,

c'est la seule chose qui permet
à Google de continuer à dire

qu'ils ont un pied dans le cloud.
Parce que la réalité du cloud

aujourd'hui, c'est 47 points Amazon.
On pourra finir sur le nom parce

qu'il y a encore c'est 47 %,
Amazon, 25 %, Azure 3 % à Google

et aujourd'hui ça s'appellerait
pas Google, on en parlerait pas.

Mais je suis entièrement
d'accord avec toi.

C'est même d'ailleurs l'annonce
qui était plus ou moins là.

On ferait quoi auprès du soir,
auprès du nomade?

Enfin, il y aurait d'autres choses,
ou alors aucun de ces trucs là,

et on aurait eu des gens qui auraient
créé des solutions intéressantes.

Mais non, justement, la solution
intéressante, c'est quand même

l'idée d'avoir un truc qui est
commun à tout un corps de métier.

C'est intéressant, ça a de la valeur,
ça a de la valeur pour un standard,

c'est un paquet de scripts, non?
Standard, ça l'est de facto.

Je dis pas que c'est énorme,
c'est pour l'instant le seul standard

que je ressens dans le cube,
c'est Elm, alors je suis pas sûr

que ce soit une bonne nouvelle.
C'est celui qui est le plus

basher vraiment la communauté
dans la communauté? Non?

Celui que je vois utilisé par
des gens à l'extérieur.

Le plus c'est des gens qui me disent
c'est génial, on va lancer du script.

Non mais elle aime ce qu'elle
fait à la fin,

c'est qui génère des manifestes.
Moi ce que je peux faire c'est

que à la fin, à la fin.
Mais même il peut faire la merde

qu'il veut, il ne peut pas écrire
sur sur un node un cluster.

Ce qu'il fait c'est qu'il génère
du Yémen que je vois là.

Je fais quelque chose avec ce
YAML là.

C'est un générateur,
c'est un générateur de YAML avec

tous les problèmes qu'il a derrière.
Mais alors vraiment?

Mais, mais, mais enfin il a changé!
Non, non non, J'ai toujours des

gamelles mais il était toujours avec
un template et ça a commencé par des

zips, dans des YAML, dans des if.
Non, ça c'est encore les générations,

les générations, la fin du fin
du fin, ça fait des YAML.

Et c'est parce que tout le monde
est un peu obligé, forcément.

Quand on fait.
Le relais, il y a plein d'opérateurs.

Enfin si, après si,
après tu l'installes, c'est tout.

Mais je ne manipule pas les tar.gz,
je. Fais des gestions de dépendances.

Du coup tu maintiens,
tu fais des gestions de dépendances.

Moi en fait, si tu veux,
encore une fois,

je ne vous dis pas le contraire,
Je vous dis je pense que cette

techno est floue à la base.
Donc voilà, vous me dites non,

il y a des trucs intéressants,
c'est moins moisi que ce qu'on

faisait avant.
Ok, j'admets, c'est moins moisi

que vous faisiez avant,
je n'étais pas avec vous peut être.

Je pense que c'est pas le futur,
mais ça l'est pas.

Oui mais le problème c'est qu'à
force de nous casser les couilles

avec ce truc là, on est obligé
de l'intégrer. Tu crois quoi?

Comment Moi je l'intègre dans mon.
Enfin tu vois, genre on est 17 h.

Voilà, au moment où je mets deux
gus à intégrer ce machin là,

très concrètement,
le projet est passé à la trappe.

C'est le projet de description
sémantique de service.

Ça, c'est la réalité.
Les gens intelligents, tu crois quoi?

Que les gens qui ont fait des
opérateurs élastiques,

ce n'était pas des gens brillants?
Ces élastiques ont des

partenaires élastiques.
On va bientôt lancer l'offre.

Gardez ça pour vous.
Entre gens qui écoutent le podcast,

on on est partenaires,
on discute avec ces gens là.

Les gens qui font ça sont des gens
brillantissimes qui auraient pu

faire à la place des choses utiles.
Et en fait, aujourd'hui,

on a tous tous les éditeurs,
on a une taxe Kubernetes qui est

réussir à faire tourner plus ou
moins notre merdier dans ce bordel.

Alors c'est oui, ça aurait pu, oui,
on aurait pu trouver un truc mieux,

on aurait pu aussi trouver un
truc pire.

Et vu comment effectuer un test.
Et surtout quand tu as cité

l'exemple D'openstack, c'est qu'en
vrai des bonnes technologies qui

sont bien sorties etc.
Des gens qui pensaient que leur

technologie était bonne et qu'en fait
elle était toute moisie et qu'elle ne

marchait pas, Il y en avait plus
que ce que l'on peut imaginer.

Et j'en suis passé par plein des gens
qui ont essayé de réinventer la roue

comme ça. Tu vois, c'est le cas.
J'adore cette technologie là,

mais tout le monde en a fait de
la merde et c'est pas un problème

de chef, c'est un problème de
plein d'autres choses,

même de chef. C'est du scripting.
Le scripting c'est du binaire,

le binaire c'est la mort.
En fait toujours la même chose,

on prend le truc au sexe fournisseur,
je reviens au métal,

on va chez OVH, on va chez OVH.
N'importe quel mec qui fournit du

métal, il y a une interface web,
OK, on va la planifier chacun,

il va se dire OK,
moi je vais fournir une espèce

de Schindler de machine physique
et on va avoir X provider X API.

On fait la même chose avec les VM,
on va avoir plein de mecs qui

fournissent des VM avec chacun,
qui fournissent son skylink machin.

Il y a un intérêt à avoir
quelque chose de commun,

que ça soit OpenStack, que ça soit,
mais ça fait pas des films.

Non, non, non, On arrive avec le
concept là tu Kubernetes,

je suis sur Kubernetes en disant il a
créé aussi, il a créé des choses,

mais absolument génialissime.
Si jamais demain on rase Kubernetes,

on gardera les autres.
C'est à dire que quand Kubernetes

on s'en débarrassera, enfin,
on aura le legacy de ce machin.

Non, c'est pas du legacy.
Je termine juste. C'est.

Tu es en train de regretter le fait
qu'on te force à mettre Kubernetes,

mais s'il n'y était pas, tu devrais
valider un truc fait maison.

Imaginons un fait maison ou
autre qui serait complètement

différent des autres.
Alors un truc open source qui

fonctionnerait pour tout le
monde parce qu'on aurait pu

faire un format, mais on aurait,
on aurait réussi en fait.

Mais en fait on ne l'a pas
réussi parce qu'on était embêté.

C'est là où on n'est peut être
pas fort,

mais on n'est peut être pas d'accord.
C'est que c'est arrivé déjà très

très tard par rapport à ce qu'il
aurait du.

Il est arrivé déjà quinze ans après.
Quelque part,

c'est une mise en commun.
Alors certes,

c'est pas une mise en commun,
c'est une mise en commun, mais en

quoi c'est une mise en commun?
Aujourd'hui,

j'ai pas le droit d'aller contribuer
dans Cube a fait autre chose.

Enfin tu vois. Non mais non.
Mais il a le droit d'aller

contribuer dans Cube aujourd'hui.
Mais qui a le droit de contribuer

dans Nomad? Qui est OpenStack?
Qui a le droit?

Je suis pas en train de défendre
Nomad, j'ai jamais dit que Nomad

c'était bien et j'ai jamais dit
que c'était bien.

Je te rappelle que je suis rentré
dans mon bureau un jour et j'ai dit

à mon équipe bon, ce machin là,
dans un mois et demi, on l'a dégagé.

Enfin ok, c'est pénible.
Ok c'est pas cool, mais.

Mais en fait tu as pas l'impression
que ça sent la même chose?

Je veux dire, ça sent tellement la
même chose que je me souviendrai

toujours la première Dotscale,
la première Dotscale la conv

d'ouverture c'était moi et j'ai
fait toute la journée.

Après l'avant dernière conf,
c'était Solomon X qui pendant 30

minutes nous a parlé de l'industrie
de la logistique alors qu'il y

connait que dalle en racontant des
conneries et pendant dix minutes nous

a dit j'ai fait la même chose et
vous allez voir c'est des mini VM.

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

Je lui en veux pas,
il vendait sa boutique,

il fallait qu'il sauve sa boite
qui était docteur à l'époque et

qui n'avait pas fonctionné comme
pass et du coup il faisait ça et

à sa sortie je lui ai dit je vais
implémenter ton truc sur mon machin,

on s'entendra et c'est pour ça qu'on
était le premier cloud à sortir et

le talk suivant, c'était le mec de
la D'openstack qui nous a décrit

que le projet OpenStack ça allait
être génial parce que c'était cool.

Driven Community, non,
Il faut quand même le dire sans

trembler des genoux.
J'aime bien le foutage de gueule

absolu de ce machin là.
Et t'avais toute la pièce qui

applaudissait en disant que c'était
génial et moi qui était consterné

en me disant mais les gars,
ce truc est une énorme daube.

Et tu tu parlais à n'importe qui
qui était dans la pièce, tu disais

ce truc est une catastrophe, Ils
disaient mais non, c'est le futur,

tu t'en es déjà servi, non?
Et aujourd'hui, Cube,

c'est la même chose.
Qui pense que Cube est le futur

qui s'en est déjà servi.
Attends encore quelques mois debout

Et là, tu fais un sur mini cube.
Mais on prend pas de risque à dire

qu'un truc va se casser la gueule.
Et là et là c'est vraiment un

problème,
c'est qu'à l'heure actuelle,

personne ne dit qu'ils sont sur Cube
parce que tout le monde se dit putain

ça fait cinq ans que ça existe,
je vais pas dire j'y suis, sinon je

vais passer pour un boloss avec ça.
Ah oui, 500 en 2007 et 2014

c'était juillet 2014 et leur
première release.

J'ai checké c'est novembre 2014 et
qui sont tagué bêta mais c'est pas

grave, ça vient par dessus les applis
bêta, mais il y en aura toujours.

En fait, à chaque fois il y en
aura et c'est pas pour rien.

C'est que mes parents, que le pod,
le pod, il a jamais été bêta. Le pod.

l'Unité de base n'a jamais été
le Réplika.

C'est que tu prends un binaire
lance le il est replicaset n'a

jamais été beta.
Ouais enfin on s'en sert, mais si le

déployer il utilise le réplika set.
Mais oui, parce qu'en fait c'est

basé sur des bases saines.
C'est la même chose que quand on

avait le GCP qui nous expliquait
Mais non mais vous ne faites plus

d'essais pour moi, je fais des JSP
et t'es là genre mais les Kara et

résultat des courses on en parle
de l'état de géo au sein de l'état

de Java Enterprise Edition?
Vous voulez vraiment qu'on ait

cette discussion?
Parce que ça n'avait pas cette

vocation, mais ça avait
complétement cette vocation,

ça avait pas cette vocation là de
gérer l'infrastructure, ça avait une

application, ça gère son contexte,
mais bien sûr, ça gérait les

Enterprise Pattern de la vision SOA,
mais franchement, ça allait

beaucoup plus loin que être capable
de faire un run sur un binaire.

C'était Java Enterprise Edition.
Et donc si vous voulez, à un moment,

quand je vous dis on n'apprend pas
des erreurs du passé, pour moi on est

dans les mêmes contextes et quand on
me dit mais si c'est un standard,

tu peux le ré implémenter et là bas
il y a déjà des implémentations.

Non, Il y a quand même, il y en a
d'à peu près tous les composants à

l'heure actuelle, sauf l'API Server.
Je connais des implémentations

d'à peu près tout,
d'à peu près tout, des vrais NPM.

Genre c'est une emblème ou c'est
plus ou moins parce que virtuelle

complète, c'est une applet?
Non, non,

mais il manque la moitié de l'API.
Enfin, c'est comme si tu dis non,

ça dépend,
ça dépend du backend derrière, genre

en fonction du backend derrière,
il peut manquer des choses parce

que les casts à l'heure actuelle
sont merdiques et moi j'adore.

Moi par exemple je suis pour que
non mais moi mon truc c'est que

j'en ai ras le cul.
Je me suis battu pendant cinq

ans pour dire aux gens arrêtez
de dire master sur cube,

c'est un control plane avec moi,
même en technologiquement je

suis dans la même chose que toi,
c'est que moi ça fait trois ans

que je dis Kubernetes,
c'est un control plane,

il faut le bouter comme un control et
arrêter de penser tout un cluster

avec des master et des slaves,
enfin avec des master et des workers.

Et je dis c'est pour ça que je
disais mettez Kubernetes dans des

dans des Kubernetes parce que il va
savoir gérer ou dans des nomades ou

dans je sais pas quoi d'ailleurs
j'avais commencé à coder mais tu

sais que c'est ce qu'a fait.
Oui c'est trop bon,

mais deux ans après que je leur ai
dit absolument pas. Ah bah c'est non.

Pour le coup,
j'allais voir les équipes et j'allais

voir les équipes à la Kubecon.
Je suis allé voir les équipes à

l'école,
je leur ai dit Mais regardez,

j'ai ce projet là qui a été fait.
Ils ont dit pourquoi t'es pas

venu nous voir?
Et parce que j'étais allé le voir.

Tous les gens que je connaissais
d'OVH, qui étaient des gens

marketeux et qui sont jamais allés
le dire aux gens techniques,

Mais les gens techniques qui ont
fait Cube, je les connais bien,

Ils ont pris le projet assez
tardivement, avant son delivery.

C'est des gens qui ont fait un
très bon boulot après,

mais globalement c'est du cube.
Enfin c'est du cube en cube avec

tous les problèmes que ça a généré.
Et franchement, je pense que t'as pas

idée des problèmes que ça a généré,
mais vraiment un nombre de

conséquences encore une fois à
exécuter des process de gens.

Enfin des process qui ne devraient
pas être sur les mêmes OS que dans

le cube, un truc ultra important.
Si jamais ils ont mis les runner

dans Kubernetes, je te promets
que c'est des photos de famille,

les runner et le control play.
Le control playing pour le coup

il est complètement isolé.
Tu peux le mettre dans un cube

ou dans n'importe quoi et c'est
un peu plus délicat que ça.

Je vais pas raconter à leur place
et en plus je sais pas si j'ai le

droit de le dire, mais c'est plus
délicat de ça parce que il y a SAP

qui le fait aussi depuis bien plus
longtemps avec Gartner et je pense

que les mecs ont rencontré d'autres
problèmes qui sont résolus autrement.

Je te dis je te dis c'est pas plus.
Non mais peut être, mais je te dis

que c'est plus que ça en a l'air.
Mais non mais on peut pas,

c'est tout ça, c'est des choses
qui se règlent et vraiment.

Et oui oui il y a des problèmes, mais
comme on ne va pas le faire comme ça,

bah c'est dommage, mais c'est un
orchestrateur qui marche très bien.

Alors Oui, mais alors alors alors?
Mais non mais c'est dit avec

Nomad ou quoi que ce soit,
mais le control playing,

encore une fois, ni l'un, ni l'autre,
ni l'un, ni l'autre. Pourquoi?

Parce qu'aujourd'hui, et c'est
probablement là où vous ne comprenez

pas pour moi le problème du scaling
et de l'orchestration aujourd'hui.

Est ce que je reproche le plus à
cette techno là?

C'est qu'elle pense que tu peux
faire de l'orchestration sans

connaître le contexte.
Or, ce qui fait que nous ça marche,

c'est qu'on fait de l'orchestration
qui comprend le contexte.

Oui, mais ils le disent,
c'est vraiment tous les gens qui

vendent des orchestrateur closed
source sur cube, c'est skinny.

Parce que le scheduler c'est le
projet le plus bâtard de tout

Kubernetes, c'est le truc où il
y a le moins d'investissements

parce que tout le monde sait que
c'est compliqué et qu'on laisse

la communauté curatrice et le
projet le plus. Comment dire?

Donc en fait,
il faut réécrire ce truc là aussi.

Mais tu te rends compte?
Mais c'est pas se plaindre,

c'est pas réécrire.
C'est qu'en fait, en gros, ce que

dit Kubernetes, c'est on ne veut
pas devenir OpenStack, on ne veut

pas faire des choix à votre place.
Nous on a une implémentation qui

marche pour l'instant,
qui est hyper simple parce qu'on

ne veut pas, mais un peu à la GOT,
un peu à des choses comme ça.

Pareil pour le pour les paquets
Django et tout, c'est genre Google

disait nous on sait pas faire du
packaging, on sait pas faire du

versionning parce qu'on a notre
mono repo donc on fera pas sortir.

Faites le vous même et une fois
que ça marchera, on essaiera peut

être de l'intégrer dans le groupe.
Et c'est ce qui s'est passé.

Kubernetes, c'est exactement la
façon dont on succès.

Bah ouais c'est super engueulé,
ça a été le fumier.

Aujourd'hui c'est la pénibilité
absolue de faire du go à cause

de systemd.
Si je puis me permettre,

il n'a pas du tout dit ça.
Moi non, parce que j'étais quand

ils ont lancé Go, j'étais là,
les mecs ont dit non.

Le système de gestion des dépenses,
on a résolu le problème, non?

Alors là, j'étais là.
Genre vous avez fait quoi?

On n'en a pas? Non.
Ah oui, si, si,

je t'assure que c'était ça que
les gars et que les gars.

Mais toutes les toutes les issues
que j'ai pu voir là dessus.

Parce que pour le coup,
ça a été un débat, alors.

Ah non mais attends,
ils ont changé leur fusil d'épaule

il y a un an Et des bananes?
Non, non. Tout comme sur les.

Non, non, c'est du glide.
C'était quoi? C'était en 2015.

Au début, ils nous expliquaient
que ça servait à rien.

C'était bien. Non, Ils disaient.
Ils disaient on ne sait pas faire.

Genre, vraiment, quand tout le
monde leur proposait des trucs,

ils disaient nous on sait pas faire.
Et vraiment, mais.

Mais Kubernetes, c'est pareil, c'est
le projet le plus, comment dire?

Rétrograde, rétrograde, rétrograde.
Mais genre camper sur ses acquis,

c'est qu'à l'heure actuelle,
incluant une fonctionnalité

incubatrice, ils ne veulent pas,
ils disent maintenant on a fait un

système extensif, faites le ailleurs.
Si un jour la communauté arrive

à converger dans une solution,
on l'intégrera.

Mais pour l'instant c'est pour ça que
c'est dur de coder dans Kubernetes,

c'est qu'ils ont les codes,
c'est un fait, mais c'est

politiquement non. C'est que.
Mais oui,

mais c'est extensible à l'infini.
Imagine, imagine ce qui se passe,

C'est Linux.
Mais non, mais Linux ne se passe

pas du tout comme ça.
Je suis désolé, Linux,

ça marche très bien comme projet,
mais c'est le débarquer et

contribuer à rien de parler.
Il faut que tu connaisses,

il faut que tu arrives à envoyer
l'e mail au bon mainteneur du

bon sous système, etc.
Dans la bonne mégaliste ça va,

il y a une doc, il suffit de la lire.
Enfin il y a un moment faut se

prendre par la main, c'est pas
accessible au tout venant non plus.

Mais si tu veux, il y a un cas où la
méthodologie demande apprentissage.

Dans l'autre cas,
on ne va pas prendre ton commit

à cause de ta tronche.
Je suis désolé, dans un cas c'est

de la politique, dans un autre
cas ça démontre ton approche.

Tu vois effectivement les patchs
par mail, c'est un sujet dont on

pourra vaguement discuter si on veut.
Bah écoute, franchement, je suis

pas un grand fan du patch par mail,
mais si ça marche, c'est comme ça

que ça marche. Non mais si tu veux.
En fait c'est juste qu'à l'heure

actuelle, tu ne veux pas devenir
OpenStack et c'est d'ailleurs pour

le coup c'est vraiment un truc
OpenStack, c'est qu'on intègre rien,

on retire du code ou on en fait
pas plus. C'est vraiment ça.

Alors est une Kubernetes qui
n'intègre plus de nouvelles

fonctionnalités.
Ce qu'ils font,

c'est qu'ils rentrent.
Ils rendent non bêta les tags qui

étaient bêta sans rien changer.
Mais il n'y a pas d'évolution

politique.
Mais non, regarde,

regarde comme moi je vois le bordel.
Tu as un truc qui est tenu par

une boîte?
C'est son seul lien sur un marché

dans lequel ils ont dit qu'en 2023,
s'ils faisaient pas réellement de

l'argent, ils disparaissaient.
Donc c'est quand même un vrai

souci ce machin.
Tout le monde en parle, c'est hype,

Il y a la moitié moins de la moitié
des contributeurs, moins de la moitié

des toutes les places dans le cycle,
c'est pas la question,

c'est eux qui sont dans la dans dans
la tête de tout le monde déteste

tout le monde pensait Google.
Tu as toute la SNCF autour et dans

la SNCF, c'est essentiellement
des startups qui ont été créées,

qui sont financées par des VCS.
Dont l'objectif est qu'un jour

ça rapporte du cash.
Et ces gens là se battent pour

prendre chaque segment de
management de ton infra sur des

projets open source avec des
versions entreprises ou whatever.

Et tous ces gens là s'engueulent
dans l'objectif qu'un jour le

tas de pognon que ça générera,
ils arrivent à se le partager.

Et donc tu passes essentiellement
du temps à faire de la politique,

bien sûr,
mais comme dans toute entreprise,

comme dans tout projet humain, moi je
suis désolé, c'est pas mon kiff.

En tant que développeur,
en tant que développeur open source.

Non mais la politique avec Linus
Linus, elle est énorme aussi et c'est

très bien que le personnage est un
personnage hautement politique.

Rien, rien.
Rien que le ZFS,

juste là à l'heure actuelle.
Tout le truc sur ZFS comme quoi Linus

n'intégrera jamais les projets DFS.
Tant que t'as pas le manager de

VMware d'Oracle qui crie sa
couille sa couille dans dans un

timbre quoi c'est des fesses est
un problème largement plus élevé

que juste Linus s'il ZFS n'a pas
été intégré au démarrage.

C'est quand même que ZFS Linux
c'était de la daube à la base ça

ne marchait pas.
ZFS est génial dans Solaris, ça a mis

du temps à être propre dans Linux.
Aujourd'hui, ça ne sera pas ajouté

facilement parce que sinon ça va
finir comme d'habitude par une grande

annonce et un truc pas propre.
Que ce soit intégré, propre,

il faut du temps.
Moi j'ai entendu beaucoup parler

de politique dans Linux.
On a quand même beaucoup moins

que dans d'autres projets.
Node est un projet où la politique.

Enfin, entre les fork et réunion,
fork et réunion, ça a été l'enfer.

On l'a vécu en tant que main
OpenStack,

la misère absolue en politique.
J'étais obligé d'envoyer mes commits

aux gens de chez Canonical pour
qu'ils les resignent et que ça passe.

Et pendant ce temps là,
on avait les gens qui disaient

c'est ce qui tourne en prod.
C'est bizarre parce que moi,

le code source qui me permet de
savoir si il y a assez de RAM ou

pas sur la machine pour booter
une machine virtuelle.

Je l'ai écrit il y a trois jours
donc tu pourras me faire croire

tout ce que tu veux.
Soit tu me dis que Rackspace ne

check pas s'il y a assez de RAM
ou pas pour booter une machine.

Soit c'est peut être pas ce qui
tourne en prod en fait,

ce serait peut être un peu du
foutage de gueule, tu vois,

c'est quand même la réalité.
D'openstack tu vois au moment où

on en parle.
Et pour moi Cube c'est la même,

on me dit c'est cube,
c'est cube, mais ça c'est Gecko.

Ah oui mais geek c'est que c'est
cube. Sauf que les diff.

Si tu veux, quand tu envoies des
machins et que tu les reçois,

les les.
Enfin si tu fais les mêmes choses

entre du vanilla et du machin,
t'as pas les mêmes payload.

Moi je veux bien que ce soit la même
chose, mais à priori c'est pas le

même code. Non mais c'est mignon.
Je parlais des API mais c'est

pas le même code et on sait pas.
Du coup comme c'est pas la même

période.
En fait les apps sont slightly

différente était exactement dans la
même histoire et l'histoire du du

comité Java avec des gens qui disent
on respecte la pièce X et donc du

coup on va mettre en place un TCK,
on a le TCK, Kubernetes Certified,

Tagada et maintenant pour chaque
module on va prendre un TCK. Alors.

Godless, la SNCF, le TCK et gratuit.
Le logo ne l'est pas mais le TCK

est gratuit.
Le logo tu dois payer, tu dois être

membre de la SNCF, c'est pire.
Il faut être membre Platinium

Tagada bidule.
Enfin ça te coûte pour te dire,

pour te dire je suis.
Bernadette a dit,

elle a dit tout, tout se répète,
un grand cycle et tout aussi

Kubernetes, c'est un concept.
Pas encore une fois,

je bosse sur des projets qui ne
répètent pas ces patterns là.

Pour moi, on est sur des projets
politiques dont l'objectif est

de vendre des choses aux gens et
pas de leur régler leur problème.

Ok, mais alors mis à part je
sais pas qu'est ce qu'on a?

On a Linux, on a je sais pas quel
projet de la fondation Apache.

Non, tout ce qui tourne dans
freedesktop org c'est très bien,

mais les gens de systemd,
ils sont pas là pour te vendre

un truc, ça marche très bien.
Oui ok, mais là j'ai pas le temps,

c'est un troll,
j'attendais plus en plus.

Désolé, je te connais pas mais je
suis d'accord, je suis d'accord.

Mais bon, ça va mourir je le sens.
Mais plus audio c'est génial En

vrai c'est génial!
Mais alors cette intégration?

Non attends, attends,
L'intégration audio a été un peu

le même argumentaire.
Je l'ai donné aujourd'hui à

quelqu'un.
Il avait tenté le coup sur Beryl,

ça c'était passé nickel.
Il y a eu une fuite de mémoire

monumentale, c'est activé les
poissons, mais ça c'était passé

nickel qu'on puisse guérir.
Pour ceux qui se rappellent de FF

sur lequel j'ai envie de vomir,
qui m'était absolument,

ils ont tenté la même sur PulseAudio,
ça a merdé tu vois.

Genre parce que on avait pas grand
chose d'autre à ce moment là à faire.

Enfin tu pouvais faire du
streaming audio.

Enfin ça a marché,
t'avais la ZX, ça fonctionnait,

alors sur ces deux applications,
t'avais plus de sources.

Enfin tu avais, je suis d'accord,
mais il restait l'intégration de

PulseAudio.
Ils l'ont fait huit mois trop tôt,

tout le monde leur est tombé dessus.
Catastrophe. Admettons.

Mais en fait si tu veux,
il ne faut pas. Enfin si tu veux.

Aujourd'hui,
la plupart des projets freedesktop,

ils sont plutôt dans l'open.
Dans la fondation,

tu as quand même un paquet de
trucs qui marchent très très bien.

Enfin je suis pas au niveau.
Enfin au niveau neutralité de ce

genre d'outils.
Node c'est Il n'y a pas que des

produits commerciaux.
Mais peut être posez vous la

question, peut être posez vous la
question à ce moment là de vous

en tant que communauté des OPS.
Le problème qui est de continuer

à penser qu'on devrait vous
fournir des outils sur étagère

qui fonctionnent et pas que vous
avez à ouvrir le code et poster.

Et fondamentalement,
je suis entièrement d'accord.

Salut Cube, tu as lu le code de
cube avant de le coller en prod?

Non, j'en ai lu des parties,
on a lu et on sait,

on sait comment aller chercher.
Et moi le premier jour, premier

jour où je suis allé à la BNP,
à la BNP, bosser, j'avais en moi

et en face de moi une armée d'IBM.
Il y avait un bug,

on va mettre des gros guillemets
à désespérer, des bugs, etc.

Et ben le jour même, je suis
allé leur sortir le code source,

je leur ai pondu dans les temps
Là dessus, la première réponse

est ah mais toi tu sais lire le
code source de cube. Voilà.

Mais genre ça arrive et avec
Cube justement, c'est du go,

c'est du go ultra mauvais, mais ça
reste du go à peu près lisible.

Ça dépend, ça dépend des coins,
ça me pénible, c'est quand même non

mais alors il y a un truc du FOSDEM
de l'année dernière alors voilà tout.

Et tous les trucs merdiques que
je trouve dans un talk de l'année

dernière du FOSDEM qui disait
pour récupérer le CLR parce que

ça a été écrit par des bugs et
en gros c'est du c'est du.

Alors moi je défends rarement
Java en tant que langage, mais en

fait je défends beaucoup la JVM.
Je trouve que la GDM est une

très très belle.
Le problème en fait,

c'est juste des développeurs qui
ont codé d'une certaine façon

alors que le langage s'y prêtait
pas et donc ils ont fait un truc.

Je fais plein de choses.
Scala ça ressemble un peu au C

du kernel Linux en fait.
Partie mais il est compliqué quand

on le regarde dans les yeux.
Il y avait même le C de systemd

aussi. Et vraiment c'est bizarre.
Enfin genre 1C1C poilu quoi.

Enfin c'est un C qui fait des
choses quoi et qui fait des

choses peut être un peu trop.
Enfin moi encore une fois,

moi je suis pas à la base,
je suis un vrai dev donc j'étais

le seul homme de la boîte.
C'est pour ça que j'ai créé avec

Oliver à la base. Mais.
Mais moi si tu veux, ma vision sur ce

genre de produit est plus le produit
est intégré dans du code, moins il

y a de bash, mieux je me porte.
Et avec systemd j'ai réussi dans des

fichiers de couches de cinq lignes
à remplacer 800 lignes de bash.

Et bah j'ai fait ça.
Je suis d'accord.

Moi j'ai remplacé toute la prod,
toute la prod.

Vous avez des docker lancés à la
main?

Non mais tu t'imagines que t'imagines
que toute la prod de ta bouteille,

toute la prod de ta bouteille,
elle tourne sur un script shell qui

est inclus dans une ressource Chef?
Non, c'est le chef.

Ah non, non, non, non, non, non,
non, non, non!

Les chaînes qui appellent des fouets
du rugby pour faire des opérations,

etc. Tout ce code là, en gros.
Oh combien il y avait 200 lignes de

codes qui n'utilisaient que la stdlib
avec une couverture de couverture de

test à 60 % d'open SSL je crois.
Non, non, non du tout.

J'utilisais que la stdlib et
elle était testée, etc.

C'était toute la partie qui décrit
le déchiffrer et chiffrer et

déchiffrer les secrets que j'avais.
J'avais un gars, il est arrivé,

il a mis un truc ici dans la liste
des technologies, il n'y a pas marqué

Go et pas marqué Shell non plus.
Encore une fois, si je vais pas,

je vais pas.
Toutes les erreurs managériales et

politiques que tu as dans ta vie
pour le bien et bon pour la santé

mentale des gens qui nous écoutent.
On pourrait,

on pourrait se dire d'abord là,
en ce moment, ils nous voient,

ils nous entendent plus normalement.
On va essayer de coller.

Les morceaux sont sortis,
c'est devenu terrifiant pour eux.

Et je vous propose qu'on essaye
de Roundup le truc, quitte à ce

à se revoir une autre fois.
Je pense qu'on s'est compris sur

un truc.
Moi j'ai des griefs techno à

apporter au truc.
Vous pour vous,

ça vous a libéré parce que vous étiez
dans des écosystèmes déplorables.

On arrive, on arrive à faire.
Je pense que les écosystèmes

déplorables sont manifestement
majoritaires, malheureusement. Soit.

Néanmoins, moi,
les les problèmes techniques que

je vois sont non excusables dans
un cadre de prod selon moi.

Après,
vous faites bien ce que vous voulez.

Je rappelle que des gens mettent
encore du Drupal quatre en prod.

J'ai eu l'impression,
la totalité de l'expression de me

souvenir de mes premières années
en web agency où je disais on va

quand même pas utiliser du SPIP,
c'est de la daube et on disait ouais

mais ça ira plus vite et ou en fait,
très concrètement, on avait des

projets où la complétude allait très
vite et on mettait des mois à aller

vers le bien et on atteignait jamais.
Parce que la dette de concepts

et de trucs qu'on avait fait au
début était non remboursable.

On avait fait des flots majeurs
au démarrage.

On est entièrement d'accord là
dessus.

Mais après je pense que c'est la
même chose.

Mais au moins peut être que je me
trompe et que des bons samaritains

débarqueront et corrigeront les bugs.
Je pense que le projet tel qu'il

est politiquement interdit,
ça alors, on peut attendre 6.2 %.

Soit on s'adresse à des gens comme
vous qui sont dans l'incapacité

de le faire, soit on investit
sur ces projets précis là dans

une infrastructure dédiée qui
ont qui ont à mon avis une flow.

Aujourd'hui, il y a des trucs qui
vont être très difficiles à corriger

la spécialisation, l'hétérogénéité,
dire on va pas corriger un

nouveau projet après, mais, mais
moi je le souhaite de tout genre,

mais vraiment de tout mon cœur.
C'est genre Kubernetes,

j'ai plein de griefs contre lui etc.
Il y a des choses qui sont des choix.

Par exemple comment le mono repo
de Kubernetes à l'heure actuelle

avec plus de 25 binaires,
25 main Go dans un même repo, etc.

Que même le client GO, c'est en
fait un vendeur qui est enlevé,

qui est mixte mais c'est de la merde,
c'est de la merde.

Tout ce truc là a été bloqué par
les gars de Kubernetes,

de Google au début et moi j'ai
vraiment beaucoup de problèmes

avec comment ça a été fait.
Donc je souhaite absolument que

tout ça, ça saute.
Je suis entièrement d'accord, mais

vraiment. Et je n'attends que ça.
Et le jour où ça arrive,

j'irai dessus.
Je serai un early adopter le

premier jour et je continuerai
le premier jour où ça se fait.

J'espère juste que les gens qui
feront ça ce jour là auront

trouvé un modèle économique.
Parce que, en sous jacent,

le problème c'est le modèle
économique de l'open source et

surtout en France.
Et là c'est ça le problème que

j'ai envie de dire en France,
Je ne sais pas, je ne sais pas

comment vous avez réussi, vraiment,
mais je trouve ça fabuleux.

Et même d'ailleurs,
c'est un plus l'exploit.

L'exploit premier de Clevercloud,
c'est d'avoir réussi à tenir en étant

en France avec l'écosystème de la
tech française, je te le cache pas.

Alors moi c'est ça.
Et pour le vivre,

même tous les jours avec des gens
qui sont avec des étrangers,

qui font des trucs plutôt bien
dans des boîtes assez grandes,

et les Français qui sont en train
de bloquer des cinq fers pour

essayer de faire en sorte que ça
ne se passe pas bien en France.

Et ça, c'est quelque chose que je
vis à peu près tout le temps et

donc clairement c'est le cas à
l'heure actuelle et je le vivre.

Vivre de bonnes technologies à
l'heure actuelle,

c'est un problème et c'est et je
pense que pour le faire, il faut

continuer à défendre cette vision que
LaTeX c'est un truc d'ingénieur.

Et moi j'en ai marre qu'on me
vende un truc de pas ingénieur,

j'en ai marre qu'on vienne me parler
de technologie en me parlant des

problèmes de management, moi,
que les gens ne sachent pas faire

du management, alors leur proposer
hormis de lire des bouquins, mais

surtout faisons des jolies choses.
Et moi c'est ma position,

les gens font bien ce qu'ils veulent,
Je maintiens que c'est ça le truc.

Et après, après après tu sais bien
que le goûts et les couleurs,

moi par exemple,
je trouve ça extrêmement élégant

dans la manière où c'est fait,
mais parce qu'on a des goûts et

des couleurs différents.
Et lancer des binaires au pif les uns

à côté des autres, ça finit à la fin.
Je trouve ça cool. Mais.

Mais en fait,
surtout dans l'ingénierie, c'est

l'optimisation en domaine contre.
Et ben j'ai des contraintes qui

sont un peu du management,
j'ai des contraintes qui sont de

plein de choses, etc.
C'est je fais de l'optimisation où je

peux et ça c'est de l'ingénierie,
c'est pas de la technicité,

c'est c'est de l'optimisation de
domaine et c'est ça l'ingénierie,

l'ingénierie dans la définition de
Jancovici, parce que c'est la pure,

c'est du Jancovici,
c'est des Jancovici, etc.

Je suis pas nécessairement
d'accord pour accepter

l'environnement humain là dedans,
parce que pour moi c'est pas un

domaine contre un environnement,
c'est toujours ce que tu présuppose

de ce que vont penser les managers.
Et si tu veux, moi il m'est arrivé de

rentrer dans des pièces où on me
disait c'est mort et d'en sortir

vainqueur et sans avoir tué personne.
De façon très simple, très carrée,

en expliquant concrètement aux
gens comment ça allait se passer.

Et à chaque fois qu'il y avait
quelqu'un qui avait une objection,

je lui ai débunké son extrait,
son objection.

Je vous ai expliqué ce qui était
selon moi, des griefs

technologiques sur ces technos qui,
à mon avis, sont des dangers qui

sont des dangers forts.
Parce que si on a beau avoir dit la

vertu, c'est cool, le machin etc.
Aujourd'hui,

c'est pas là dessus que c'est basé.
Aujourd'hui,

on a des problèmes de mise à jour,
on a un problème de dockerhub,

on a un problème d'isolation,
on a un problème de contrôle,

de conformité, du control, du control
manager, il y a plein de problèmes.

Alors on me promet que demain ce
sera génial et je te promets

qu'on te promet. Pas du tout.
Je pense qu'il y a personne

d'entre nous, c'est juste que je
pense que ça va rester pareil donc

ça va rester aussi bloqué avec,
on sait pas là dedans,

mais il y aura, il y aura demain.
Moi je rêve, je rêve de conteneurs

qui sont plus des leaders etc mais
d'autres choses avec une envie.

Tu rêves Mais est ce que je veux
dire par là?

C'est que toi aujourd'hui, tu vois le
potentiel du projet, tu te dis la

la communauté va le faire. Soit.
Ouais, le potentiel du projet,

je le dis Non mais moi j'ai vu,
moi j'ai vu ce qui était avant

et surtout les technologies, moi
j'ai fait du méso, je suis désolé,

c'est une merde, c'est une merde.
Et moi j'ai du apprendre à faire

des containers, j'ai mis de la
prod sur tous les containers,

sur tous les orchestrateurs.
Très sincèrement, celui qui va le

moins appeler Seveso, j'ai pas
aimé ça. On parle pas de moi là.

Non, je parle de mes OS. Vraiment.
C'est que je sais que je mets quoi

dans mes os si tu fais juste tourner
mes os? Non, non, non mais non!

Mais oui, mais dans ce cas là,
tu vas pas comparer avec

Kubernetes si tu fais.
Pas du tout le même degré de

flexibilité. Mes os, mes os.
Tu mets un framework par dessus,

c'est mes os.
Quelque chose qui ressemble à

Kubernetes, mais mes OS tout court.
Mon marathon,

c'est pas si pénible que ça, tu vois.
Ah bah ça va, on a wipe la prod

juste avec un push merdique
parce que les pieds à y aller,

la vie est une merde en disant
que c'était pas très exigeant,

voir même pas, tu ne peux même pas
savoir le check que tu as mis,

genre tu pousses un check,
tu peux même pas le récupérer.

Et moi c'est comme ça que
devrait fonctionner les check.

Mais ça c'est encore une fois.
Toutes les autres technologies

que je connais, que j'ai vu
technologiquement sont en dessous

de cube. Tu n'es pas parfait.
Est ce que je sais pourquoi

notre monitoring fonctionne?
Ça,

c'est un sujet qui est très amusant.
Pourquoi notre monitoring à nous

fonctionne?
C'est par rapport à toutes ces

technologies que tu as des problèmes
de box, de machin, de truc.

Mais Prometheus, j'ai eu peu de
problème. On pourrait en avoir.

Enfin,
tu as vu que ça demandait quand même

vachement d'avoir un Prometheus
exporté dans la technologie que

tu monitore aujourd'hui.
Bah ok, c'est pas c'est pas très

très grave, ils auraient du même
cash avec. On t'en reparle.

C'est Oui c'est facile,
il faut que tu modifie webcasts,

il faut que memcache tu décides
qui peut répondre à tes questions.

Ils ont dépassé le stade que si
tu as besoin de plus des stats,

tu vas aller dans les. Couilles.
Il a fallu que je me cache moi même.

Donc ouais, ç'aurait été un échec.
Non mais d'accord.

Une fois que ce que je veux
t'expliquer c'est que moi j'ai

pas envie qu'un process externe
puisse parler à mes machines.

Donc mon monitoring fonctionne.
C'est entre autre parce qu'on est en

vertu, C'est à dire que aujourd'hui,
c'est parce qu'on peut se permettre

d'avoir un vrai gestionnaire de
processus qui va avec chaque

apps que tous ces problèmes là,
on peut les résoudre.

Après tu peux me dire oui,
mais on peut bricoler machin.

Oui, c'est vrai, mais justement moi,
si jamais j'ai envie de ça dans

ton code, tu peux très bien lui
mettre un exporteur.

Et ils sont vraiment ensemble,
Ils sont connectés?

Non, ils sont totalement ensemble,
isolés, tout ça tout ça.

Ils sont pas isolés, ils sont dans
le même os que tout le reste.

Ce qui veut dire qu'à chaque fois
que tu vas chercher de la data

sur l'OS en lui même, soit tu as
bien configuré des conteneurs et

il n'a pas accès à slash proc,
soit les données qui sont

remontées par proc ne sont pas du
tout ce qui parle de ton propre

mais de l'intégralité de l'OS.
Et donc tu as des problèmes de

monitoring ne serait ce que ça
tu vois?

Enfin en fait, si tu veux,
à chaque fois que je pourrais avoir

des problèmes, tu en as beaucoup,
tu en as, tu en as.

Mais en fait, avant,
dans toutes les prod où je suis allé,

les gens ils se lançaient tout
en mode yolo avec seize bits.

Et en fait,
arrête de me répondre à chaque fois.

Ouais mais avant je bossais dans
un endroit où les mecs faisaient

de la civilisation qui ne
bénéficie à personne.

C'est pas une optimisation,
ça bénéficie à tous mes utilisateurs.

Mais non.
Oui mais si concrètement ça ne pas

l'avoir fait, ça n'aurait rien
changé. Tu as perdu du temps en fait.

Et ça a tout changé chez le
monde entier.

Le monde entier ne peut pas juste te
dire que j'ai fourni un exporteur

pendant X années sur un memcache.
Il faisait le travail, il fournissait

de la valeur à mes clients et
j'ai ressenti aucun problème.

Il ne s'est passé rien pour nos
clients alors qu'au bout de 20 ans,

il s'est passé quelque chose.
Peut être qu'au bout de 40 ans,

il s'est passé quelque chose, mais en
attendant, je ne suis même pas sûr.

Donc est ce que le risque en
vaut la chandelle?

Et en plus, le principal étant
d'avoir une telle exigence,

est ce qu'il y a vraiment une valeur?
En fait, la différence entre avoir

une telle exigence et pas avoir une
telle exigence est que ton sommeil

la nuit est extrêmement qualitatif
parce que je sais exactement ce

qui va se passer puisque ça a
été calculé. Non mais faire.

Mais je pense qu'il y a quand
même une certaine part de fait.

En fait non,
Dans un domaine que je gagne et à

un autre endroit dans un domaine.
Mais tu vois, c'est toujours le même,

mais dans un monde limité,
tu peux te le permettre.

Et je suis entièrement d'accord
avec ça.

C'est juste que Kubernetes,
il a un principe de base qui est

de pouvoir faire tourner des
applications legacy, des applications

que je ne fais pas tourner,
des applis legacy dans Kubernetes.

Arrêtez de déconner. Il a.
Il a comme but de pouvoir le faire.

Oui d'accord, mais c'est à dire que
c'est pas en passant, ça veut dire

qu'en gros oui mais nous on passe,
on fait tourner des applications.

Pour le coup très legacy,
c'est vraiment des choses qui

ont été en fait en gros le but
normalement non, mais c'est en

fait en gros on a pas de prob.
De ce type là, nous on a que des

trucs, peut être pas, mais je le
garde pour nous les vieux trucs.

Mais non, ils sont sous contrat avec
IBM puisque sous contrat avec Solaris

ou encore la machine à écrire.
Mais en tout cas, voilà, je pense

que là vous avez déjà ce podcast,
c'est le plus long qu'on ait jamais

fait et on avait d'ailleurs un des
plus intéressant et j'espère que

vous m'entendez puisqu'on parle.
Donc là on a eu un problème de son

Si jamais on a on a tout baisé,
voilà, il n'y a plus rien.

Donc le zoom nous enregistre
depuis tout à l'heure,

mais ça se trouve pas.
Terminer la conversation au resto,

c'est ça?
Mais en tout cas,

merci beaucoup d'avoir écouté.
Je pense qu'il y aura des suites,

il y aura tout ça etc.
En d'épisode on va le sortir en trois

parties donc la dernière partie.
Mais.

Mais en tout cas merci à vous
d'avoir écouté, merci à toi Quentin

d'être venu nous parler etc. On a.
On a vu que genre hotline Twitter

on peut discuter normalement
avec des gens, mais c'est très

bien de le dire avec les gens
qui regardent ça de l'extérieur,

on a l'impression peut être que on
est des grands méchants qui, qui,

qui, qui ne savons pas parler, etc.
Non, on peut avoir des divergences et

pourtant s'entendre et et voilà,
c'est juste des il souffle

Franchement les mecs on s'entend.
Mais non mais c'est d'accord,

en fait on est pas d'accord sur
de multiples trucs,

mais en fait c'est un problème.
Enfin comme souvent c'est un

problème de contexte.
Moi je il y a des choses c'est

en fait.
Après ça dépend ce qu'on fait

dans la vie, mais c'est peut être
le fait d'avoir été connu jeune

pour mon code, mais en fait moi
j'ai un truc, c'est les gars,

je mettrai pas de la merde en prod.
Et en fait le truc c'est que si

ça se passe comme ça, je vais
passer la porte et pas revenir.

Et du coup moi je mets pas de la
merde en prod, il n'y a pas de

discussion sur le sujet tu vois.
Et ça c'est ça me rend beaucoup

plus serein et du coup ça nous
permet de construire des choses.

Je dis pas qu'on a eu raison sur
tout, on a fait plein de merdes,

il n'y a pas de,
il n'y a pas de discussion.

C'est juste que je pense que là
on a pris des mauvaises,

des mauvaises décisions.
Après, j'entends le discours qui

dit ouais mais avant on avait
vraiment de la daube et j'ai pas

les moyens de tout recoder.
Ma réponse c'est de dire

regardez ce qu'il y a d'autre,
voilà. Mais c'est ça, c'est ça.

La question qu'on m'a posée,
c'est qu'à l'heure actuelle, il n'y

a pas grand chose d'autre viable,
mais au moins vous en avez fait par

des équipes qui parlent français,
qui font le boulot qu'avant et.

Et la question elle est jusqu'à
quel point on va continuer à aller

embrasser Google sur la bouche?
Et je pense que la base plus IBM

qu'autre chose.
Enfin quand tu vois ce que.

Non mais un jour auprès des
oiseaux ces jours ci.

Enfin je sais pas, il y avait.
Il y avait moyen aussi à un

moment de t'embrasser ça au tout
début et d'y être.

Ça a été le cas avec certains de
mes amis.

On s'est fait défoncer en plein de
boîtes françaises etc qui n'ont pas

pu y aller, moi et des scaleway.
OVH a passé à Cuba dès le début

pour être des vrais acteurs
français de cubes,

pour pouvoir peser dans le game etc.
C'est pas pour dire, mais ils

n'ont jamais pesé dans le game.
Je sais pas à quoi tu rêves,

mais sans déconner, tu tu.
Tu vas souvent dans la vallée

parce que pas souvent. Mais.
Mais t'as pas senti.

Enfin moi j'échange des mails
des fois. Surréaliste.

Il m'est arrivé de faire des
trending hackernews avec des techno.

Tu vois, les mecs de plusieurs boîtes
connues m'ont envoyé des mails en

disant c'est génial ce que vous avez
fait, On boit un café pour en parler,

leur dire on va faire un call
parce que moi je suis à Nantes,

on va pas boire de café demain parce
que ce que je suis à Nantes France.

Mais par contre je passe probablement
le mois prochain dans laquelle

on se voit à ce moment là.
Ah non parce que vous savez

coder en dehors de la vallée?
Non mais tu sais,

t'es là genre Mais va mourir.
Alors qu'en vrai, quand tu bosses

dans les boîtes de la vallée deux
minutes, vu qu'il y a un marché de

l'emploi qui est tellement tendu
qu'en vrai tu prends un cuisinier

de burritos et c'est pas négatif
envers les cuisines burritos et

tu lui mets un t shirt cube.
Le mec est embauché développeur star

à 300 zéro zéro zéro balles à Noël,
ce qui fait que tu as un tocard

au mètre carré en code mais qui
défonce l'entendement quoi.

Et franchement, t'as cru deux
minutes que si OVH avait migré mais

six mois plus tôt sur Kubernetes,
il devient leader dans le marché.

Regarde Zalando, Zalando s'en
sort super bien mais regarde sur

Docker Docker, il y a eu trois.
Alors je sais pas, c'est reparti.

Il y a eu plein de fois au mois
de janvier de signer du dock du

docker datacenter dans le monde,
dont une énorme française.

On a donné le moindre poids, mais
c'était genre ça a jamais marché.

Ouais, c'est bien ce qu'on dit,
mais en plus c'était une version

closed source. Mes souvenirs.
Mais bien sûr! Comment tu veux peser?

Moi je suis à l'open source avec
des gens qui baisent de manière

open source.
C'est genre on parle,

on parle open source quoi,
qui peuvent protéger des gens,

des gens qui achètent, de l'IBM, de
l'IBM closed source sur le mainframe.

Ils vont pas peser non plus dans
la construction.

Et moi mon ticket de support,
c'est bien ce que je t'ai dit.

Je ne vois pas en quoi ça nous pèse.
Il y a Bloomberg qui pèse aussi.

Il y a quand même pas mal
d'acteurs européens.

Le truc c'est que en France,
c'est un néant.

Il n'y a aucune kubecon qui est
jamais là en France et je pense

qu'il y en aura aucune qui viendra
en France comme en Europe.

Elle viendra jamais,
il y en aura pas en France parce

qu'en France il n'y a pas d'autres
villes que Paris pour organiser une

kubecon que Paris c'est extrêmement
cher et que les infrastructures

sont pénibles à gérer.
On peut parler du marché de la

conférence, c'est pas un souci.
C'est beaucoup plus simple

d'organiser une conférence à
Amsterdam ou à Barcelone.

Enfin, franchement, je connais très
bien le game des conférences et pour

avoir organisé plein de conf à Paris,
c'est pénible à souhait.

T'as pas les hôtels que tu veux,
t'as pas les infras avec l'aéroport,

t'as pas les Ne serait ce que louer
le palais des congrès de Paris un

an à l'avance, c'est impossible.
Et ensuite louer le Palais des

congrès de Paris,
Faire un dossier en soi, ça c'est

un problème d'infrastructure,
d'organisation événementielle.

Et sincèrement, c'est ça le problème.
C'est pas le plus gros aéroport

d'Europe, c'est pas les
aéroports les plus simples.

Tu dois prendre des aéroports où
c'est très simple de venir des

États-Unis.
Barcelone,

c'est un excellent hub Amsterdam,
c'est un excellent hub Londres,

c'est un excellent hub.
C'est juste que tout est cher.

Donc non, non, franchement,
c'est pas pour ça.

On n'a pas pesé dans le game
Kubernetes parce qu'on n'avait pas

les gens pour jouer dans le game
Kubernetes et parce que la vallée

n'est pas du tout ouvert à nous
laisser. Et ça c'est un énorme point.

Mais on doit être le point de
notre prochaine discussion.

La question est est ce qu'il faut
continuer en tant qu'Européens,

à être une dépendance du réseau
américain maltraité ou est ce

que on devrait construire notre
propre vision d'internet ou aller

sur les chinois? On va le faire.
Moi j'ai une équipe à 80 % de chinois

et les technos chinoises, mais c'est
en gros là à l'heure actuelle.

Le truc c'est qu'on n'y arrivera pas
si jamais toute notre tech reste

tout le temps dix ans en retard.
Tu vois, c'est pas le cas chez moi.

Mais enfin, c'est à moi qu'on a
dit que j'étais, j'étais daté et

que j'étais un cacochyme qui
savait pas de quoi il parlait,

tu vois? Non, non non non.
Mais dans les conteneurs,

au final, tu utilises quand même
in fine une notion de conteneur.

À mon sens, les conteneurs c'est
une notion, c'est pas une

implémentation. Let's go!
Non mais attends, après la bouffe,

je vais t'expliquer comment
marche le truc.

Et en fait, l'histoire que tu dois
comprendre, c'est que justement non,

c'est parce que nous,
notre truc est sémantique,

c'est pour ça que ça marche.
Encore une fois,

ce que je reproche aux conteneurs,
fondamentalement, c'est leur

absence totale de sémantique,
c'est de faire un zip de binaire.

Je trouve que c'est dommage.
Ouais, mais dans ce cas là,

t'as plus du tout la génération,
la génération mais oui, non, non,

non mais attends, une entreprise,
non, non, non, non, non non!

Mais que exécuter des binaires
c'est pas.

Expliquer comment ça marche,
on va le faire au resto,

on va pas repartir en arrière au
x ième fois. Merci à tous.

Et puis et puis à une prochaine.
On espère beaucoup plus vite que

les dernières fois.
Faites nous du feedback.

Je pense que vous allez nous
dire que c'est un chouilla long,

mais écoutez, écoutez,
les ont plusieurs, c'est pas jouable,

c'est pas juste du blabla.
Non, c'est bon, allez, à plus.

Merci aussi.