Bonjour et bienvenue dans ce nouvel épisode de Messages à Caractère Informatique,
épisode numéro 106.
On est toujours les 6 mai de 1224 et aujourd'hui je suis accompagné de Yann Merveillet
tel que David Cossinus.
Bonjour.
Est-ce que vous êtes là ?
Bonjour à tous.
Antoine Blondeau.
Hello.
Et moi même.
Donc dans ce...
Bonjour Horacio.
Bonjour.
Et je ne vous cache pas cet épisode, c'est la suite de précédent.
On a beaucoup trop de Yann et il se trouve que je ne sais pas.
Donc on va reprendre la on la veut.
Arrêtez, une présentation rapide quand même.
Antoine, aussi connu comme Panda, t'y es qui ?
Eh ben moi c'est Panda, je travaille chez Clever Cloud, je suis développeur, je travaille
sur la partie Control Plane et la partie virtualisation.
Steven, qui êtes-vous ?
Et moi je suis ingénieur Citiou chez Clever et je bosse avec l'équipe d'ingénierie.
David, tu nous racontes qui tu es ?
David Cossinus, donc je suis de Citiou de Clinique, une escène française, client et partenaire
de Clever Cloud.
Et moi c'est Horacio Gonzales et je m'occupe de la partie de Frère chez Clever Cloud.
Et donc directement dans les bannes on avait plein de souillets pour les derniers épisodes
et je reprends la honnête, arrêtez.
On a vu, depuis longtemps on a entendu des trucs plutôt compliqués sur la façon
comme les villes sur les estreaux et faits, type Citiatro de requête par erreur,
tu payes énormément, Citiale C'est un boquette avec un lien public et en concurrence
on s'amuse à l'essentiel officiel de milliers de fois type A enorme main mais,
ce mois dernier on a vu une qui était encore plus surrealiste, on va dire,
que les autres type T'es retrouvé avec une facture extra de milliers de dollars
même si t'as un boquette privé et même si les gens qui essayent de se connecter
n'ont pas de sa autorisation pour le faire,
ça veut dire que ça, si tu complètes pour moi ou moi,
que si tu te connectes à un boquette privé et tu essayes de faire un put par exemple,
même si tu te donnes de toquer d'authentification ou de toquer d'authentification bidon,
le propriétaire de boquette se fait facturer.
C'est cette découverte ni façon trade-roll que le canacré un boquette privé
et la donner un nom de boquette dont d'adresse,
qui correspondait au nom de boquette utilisée comme exemple d'amplucer l'ogicel open source.
Effectivement, tu se loges le open source ou le mand de l'install,
avant de très bien configurer et si tu essayes de se connecter sur le boquette,
que tu configures de la code comme un boquette d'example.
C'est possible que tu puisses faire un boquette en ligne
pour que la facture monte à plus de 100 milliers d'euros.
Effectivement, tu sais que tu sais que tu peux mettre sur le boquette
sans toquer d'authentification, si tu te prends d'erreur,
mais il est à la fois facturer le propriétaire.
Si tu montres encore à quel point la facturation
est prévisible et potentiellement dangereuse ?
Ben ouais, AWS fait n'importe quoi avec sa facture épisode 528.
Oui mais celui-là, ça me semblait beaucoup plus bizarre que le reste.
Parce que Corequine a dit quelque chose.
Ben c'est ce que j'ai dit, ouais.
Corequine, c'est énorme troll qu'elle a quand même fait un tool
pour calculer ta facture AWS parce que personne ne pigerait rien
au coup caché que vous voyiez avoir.
Mais non, j'ai une tée là-dessus, je pense que en vrai,
c'est du gress ou yfi, je pense, qui tape.
Yfi, c'est à là ? Oui.
Ça veut dire que là où nous, tu vois,
dans le design, on essaie de se dire,
il va falloir qu'on valide le...
comment dire, le mec a le droit de venir assez tôt dans l'infra
pour pas que ça nous coûte trop cher en infra
parce que vu que c'est du mutualisé,
on va essayer d'éviter machin,
que les clients nous prennent trop de ressources
sur tout ce qui rentre sans droit.
AWS, ils font juste, non mais en fait c'est chiant à dev.
Du coup on va le dev à l'endroit où il y a les données
et puis si les données, ils arrivent jusque là
et qu'ils n'ont pas rêvé jusque là,
ben le mec paiera.
Et c'est juste un peu usant, tu vois,
à quel point il y a peu de recherche en genre de choses
et à quel point ça leur pose peu de problème
de facturer des trucs qu'on aucun sent, ce genre.
C'est juste usant.
En même temps, on peut pas les accuser.
Ils ont quand même créé plein de nouveaux métiers.
Je vais pas avancer.
C'est quand même un énorme progrès.
Sans ce mode de facturation, il n'y aurait pas de fin-ups, les gars.
Donc à un moment donné, voilà,
il faut savoir ce qu'on veut en fait.
Consultant fin-ups.
Oui, il n'y aurait pas non plus d'aucœur.
Vous avez bien tout fait.
Pour ceux qui n'ont pas l'histoire d'un d'aucœur,
il est né parce que les coûts d'Amazon étaient tellement importants
que les gens de DotCloud à l'époque se sont dit
qu'on saucissonne un peu la manière de provisionner, etc.
Et du coup, ils sont mis à jouer un peu avec Denen Space,
les six groupes, à la poudre script Bache.
Et ils sont arrivés à ça.
Finalement, il y avait Go qui était un peu le truc trendy du moment.
Ils se sont dit, tiens, on va essayer avec ça,
mais à la fin, c'est la même chose que faire du Bache.
C'est juste utiliser Denen Space et des six groupes sur un Linux
pour faire l'isolation de process.
Mais ils ont amené le concept d'image, etc.
Par-dessus, tous les trucs troués avec des images
qui ne sont jamais mises à jour, etc.
Et du coup, en fait, le truc est parti de là,
mais l'objectif, c'est effectivement de découper,
de ressuscissonner du YAS en VM de provider
parce que c'était vendu trop cher.
Commençons le matos de 2017, vendu en 2024.
Ça vaut pas le coup, comment ça ?
Moi, je comprends.
Quand tu as un système de facture comme ça
et que tu asille faire ce genre de truc,
je l'ai fait aussi quand on était justement facturé par IBM
au mois avec des coûts de VM qui étaient excessifs.
C'est comme ça qu'on est passé au container.
Moi, je le comprends.
Après, oui, effectivement, AWS,
c'est une entreprise pour faire de la facturation.
On ne s'est pas fait pour faire de la technologie.
Mais oui, en fait, c'est ça qui me vue.
C'est qu'on nous dit quand même régulièrement
que vous voyez, les YAS, c'est merveilleux,
ils ont plein de produits et tout.
J'encourage aussi les gens à se poser la question
d'avoir partenaires commerciaux.
C'est-à-dire que les pratiques d'Amazon
en termes de facturation, c'est n'importe quoi
depuis très longtemps.
On m'attire de concurrence, c'est pareil.
C'est-à-dire qu'ils n'ont aucun scrupule
à se mettre en concurrence avec leurs clients
voire à repomper leur fonctionnement.
Parce qu'on peut quand même parler rapidement
de Netflix versus Amazon Prime.
Mais c'est classique, en fait.
Et du coup, oui, c'est bien d'avoir plein de produits.
Après avoir plein de produits,
je fais un mec qui, 1, te facture du frère réseau
à la con comme ça, qui, 2, te fait des factures
et que tu comprends jamais rien.
Et qui, 3, a des pratiques commerciaux
qui sont très douteuses du genre
te mettre des vm, de démo sur des cpu
qui marchent très bien.
Et puis, 1 heure après, te laisser au tulle, tu vois.
Parce que bon, de toute façon, tu ne t'en sers pas, tu vois.
Enfin, je ne comprends pas.
Je comprends l'engouement sur les produits,
mais ça vaut aussi de se poser la question
de savoir avec qui tu travailles.
Bon, comme tu disais, les pratiques d'AWBS,
Episode 645,
On va passer au sujet suivant.
Et là, je vais avoir besoin que vous me disiez,
parce que, à une époque,
j'étais bremé en guic et linux, sa faune,
mais je crois que mon dernier carnel,
ça doit faire 200, que je n'ai pas compilé.
Et après, ça n'est sur le gouvernement,
je suis devenu un banel utilisateur fédora.
Donc voilà, je arrive à comprendre
qu'il y a un truc qui s'appelle SystemD,
que tous les distribuent pris ces dernières temps,
mais qui fait de la polemique.
Mais j'ai entendu dire que la dernière,
ou en nième polemique,
c'est une proposition pour un nouveau type
de remplacer sudo ranzero,
et que ce serait pas cahier avec SystemD.
Quel campagne me c'est aidé,
me expliquait ça, d'une façon que un vieil geek
puisse comprendre ?
Moi, j'ai une vraie fascination de la manière
dont Racieus décrédibilise
pour passer le sujet, tu vois.
Eh, tu comprends pas.
C'est ça, n'est pas voir d'ego,
tu peux te permettre de te faire l'alte.
Exactement.
Ça me fait penser à Jean Kruger,
qui est dans un stateur de Nightlife,
ou je sais pas quoi, elle expliquait
comment elle parlait en allemand,
ou en anglais, ou en français,
selon différentes situations.
Et quand elle était prise sur le fait
d'un contrôle de police, ou je sais pas quoi,
elle parlait avec son accent français,
je dis, sorry Monsieur Legend,
je ne comprends pas, je sais pas ce qui m'a réjoui.
Tu veux dire que Horacio n'a pas d'accent ?
Normalement, en vrai.
Non, il y a les prétictions, madame,
pour les garder après 25 ans, c'est très compliqué.
Je vous invite
fortement
à accompagner Horacio
dans des conférences anglaises en Espagne.
C'est magnifique.
Oui, il y a le souci pour changer de langue,
et changer de s'y lancer dans ces langues,
et c'est compliqué.
Je vais parler à des gens en espagnol,
enfin des natifs qui de parler espagnol,
et même moi, je disais,
mais Horacio, mais moi, j'ai plus compris que lui.
Moi, ce qui mettait des mots français,
anglais, espagnol, tu vas comprendre.
C'était magique.
Horacio, il ne savait plus où il était,
il avait trop de langue.
Alors, RunZero versus Sudo.
Alors, on va refaire un peu d'histoire.
Sudo,
qu'est-ce que c'est ? C'est un outil
qui permet, quand tu veux
exécuter un binaire
avec des droits supplémentaires,
d'invoquer Sudo en tant qu'utilisateur
pour dire que ce binaire-là
va être exécuté avec plus de droits.
Ça va, le geek qui
s'amène en toi.
Ça y arrive encore à les faire.
Ça y arrive encore à les faire.
Par contre, Sudo,
ça a toujours été un peu décrié.
Ça a toujours été décrié
pour une raison qui est
que c'est un outil
qui utilise
ce qu'on appelle
la user ID, dans l'acronyme,
qui permet
de faire de l'escalade de privilège
sur du binaire exécuté
en cible,
mais en passant par
un contexte non privilégié.
C'est-à-dire que tu pars
de ton contexte utilisateur à toi
ou tu t'authentifies avec ton mot
de passe utilisateur
pour passer par
ce binaire Sudo
qui a des droits supplémentaires
pour faire de l'escalade de droits.
Donc ça
pose régulièrement des problèmes.
T'as régulièrement des failles
d'exécution,
des CVE sur Sudo, etc.
Et ça veut dire que
si l'utilisateur est
corrompu, entre guillemets,
dans ces droits, etc.
Selon
les droits que tu as donné
à l'utilisateur,
tu peux avoir un débordement
inhérent à ça.
Donc sur un modèle d'ingénierie
de sécurité, Sudo pose
énormément de questions.
C'est la voie royale sur l'élévation
de privilège. C'est-à-dire que tu vas te dire
je vais laisser une petite capacité
à un seul user
d'exécuter un seul le ciel
dans un contexte privilégié
et tous les gens qui ont déjà fait
un peu de pétésse,
ce genre de domaines savent
que tous les logiciels
cibles de ces trucs-là
souvent trabaluent une faille à la con,
genre un buffer overflow,
genre tout genre de choses,
ou une exploitation de la mémoire,
ou un truc. Et du coup, ils vont servir
du fait que celui-ci est
exécuté de manière privilégiée
pour, depuis un compte, pas privilégié
prendre la main sur le système de voiture et en eutrateur.
Et d'où le fait que ce mécanisme
soit un bon modèle.
Quand on a créé Biscuit,
on l'a créé dans l'exact opposé.
On s'est dit qu'on parle
d'un modèle de droit
avec tous les bienfaits Biscuits
sur la capacité
de faire du décentralisé, etc.
de l'autorisation décentralisée,
mais on s'est dit qu'il faut
être capable de dégrader les droits,
mais pas de les augmenter. Une fois qu'on s'est dit ça,
tu fais quoi de pseudo ?
Et en fait,
il n'y a pas
de chemin
d'amélioration
de la situation.
Et donc,
c'est là que
l'énarte
c'est marrant, parce que
quand l'énarte est une temps qu'il y a chez Microsoft aujourd'hui,
quand il y est, tout le monde
c'est dit, c'est la fin,
ça y est, il nous a contaminé avec systeme
de mains, de bar, tout ça a été prévu,
c'est drôle.
C'est drôle.
C'est pas l'épisode drama,
c'était celui de la semaine dernière.
Et donc,
en gros, quand 6MD est arrivé,
d'une, il a quand même résolu
un paquet de trucs. Je ne te parle pas des
systemes d'eshore, des trucs machins,
systemes d'eshore pour l'exécution des services.
Avant, on avait quoi pour faire ça ?
On avait Init, qui est un système sémantique
très faible pour gérer
l'interdépendance
des services. On avait
Systeme 5,
qui paraît
très léger,
mais c'est fait pour l'embarquer,
c'est pas fait pour
gérer des serveurs.
Tu avais des gens qui faisaient
tourner leurs services dans Supervisor,
Supervisor D,
tout l'écrivant Python,
bricoler pour faire tourner
tes services. Ok, tu vas très bien.
Mais ce n'est pas des outils system,
ce n'est pas un truc propre pour faire tourner
un OS proprement.
La Systeme 5 est arrivée et a résolu ça.
Il y a des débordements,
parce que Systeme 5 devient quasiment un OS
avec tout ce qui propose dans son écosystème,
mais on a le choix d'utiliser
ou pas, des bouts.
Et là, donc il propose
Systeme 5, Run 0,
je crois que ça se fait comme ça,
et qui apporte
une nouvelle façon de faire. C'est-à-dire que
tu pars
du gestionnaire de service, et donc
c'est un nouveau système des run
qui est implémenté,
et qui permet, du coup, de venir dire
ce programme-là,
il faut le faire tourner dans les droits cibles,
et donc
plutôt que de faire une escalade de droits
en partant de ton utilisateur,
tu pars du
système de service, qui va
exécuter dans les droits cibles,
en faisant un transfert
de ce qu'on appelle le TTY
vers le PTY.
Alors on va faire un peu de...
...
...
Le TTY
c'est la représentation du terminal.
C'est un outil
d'ailleurs, TTY sur l'INUS, qui vous permet
de savoir si vous êtes dans un environnement
terminal ou pas.
Et le PTY, ce qu'on appelle
le pseudo-terminal, donc c'est un
environnement qui vous...
Merci, pendant...
...pendant qu'il y a eu bon courage pour sortir de là,
salut gros !
Et donc voilà, le PTY
c'est le pseudo-terminal,
qui du coup fournit différents environnements
pour se mettre dans un contexte
de terminal.
Et donc, ce que fait RunZero,
c'est qu'il permet de créer
un PTY dans
l'environnement cible, et de faire un
transfert du PTY
d'exécution vers le PTY dans
les bons droits, ce qui fait que l'environnement
d'exécution est dans
les droits cibles d'exécution,
mais qu'il n'y a pas de remontée possible.
Parce que tu n'en rends pas
un PTY, entre guillemets,
conforme.
En théorie,
ce n'est toujours pas de la virtualisation,
qu'il y ait personne qui vient de faire un nouveau docker like
en se disant, on va faire docker sur RunZero
et ça va être fabuleux, ça reste du process.
C'est toujours le même...
Maintenant, il y a Wazom, on ne fait plus de docker.
Même Solomon Hayek, ça dit,
s'il y avait eu Wazom à l'époque, on n'aurait pas
fait docker. Et c'est normal, et c'est bien,
c'est l'avenir de l'informatique.
Dans 10 ans, il n'y a plus de docker.
En fait, docker,
c'est...
Non, faut pas, je pense, parce que là,
si même...
On se fait pas, mais il se saut pas faire.
On peut y aller après, sur docker.
Donc, pour finir
sur RunZero versus sudo,
la proposition, c'est de dire,
on a un modèle
qui inverse la logique de sudo,
qui pour moi est plus sain.
Je sais pas pourquoi il y a
autant de bruit alors qu'en fait, sudo
était par les bons ingénieurs
qui ont un trait
sur la sécurité.
Sudo n'a jamais été une solution très acceptable.
RunZero, ça m'a l'air
plutôt sain dans l'approche.
Ça m'a l'air plutôt bien golé.
Je ne suis pas là à regarder en détail, détail.
Mais je me dis que vu ce qu'on avait
et vu ce verquant, on va. C'est plutôt mieux.
Et...
Du coup, l'énarte, visiblement,
contribue toujours à faire ensemble.
Déjà, je pense que le premier problème, c'est l'énarte
qui pose polémique
sur l'énarte
et son collègue, je ne sais plus comment il s'appelle.
Qui s'est fait
jartez
du déploiement, enfin de
de la capacité de faire des patchs
par Linux.
Je ne sais plus comment il s'appelle.
Ils étaient deux à développer
et SystemD, c'est essentiellement
il y a de la polémique.
Moi, je vois un truc souvent
perso
j'aime bien SystemD.

Ne me tuer pas aussi.
Et on le rend plus mal.
Les gens aujourd'hui qui râlent
sur ça, beaucoup,
je veux rester à l'ancienne
à gérer mes VMs, comme je faisais
et je peux comprendre qu'il y a
des sujets, que ça fait trop de choses, etc.
Mais on gère
plus des machines, surtout quand on
doit en gérer beaucoup, à la main
en faisant des lignes de commande
et en faisant
on gère plus comme ça.
Sudou, ça a rendu 7...
Moi, j'ai fait du Sudou pendant 30 ans
non, parce qu'il y a un moment
que je ne fais plus d'admins. C'est pratique.
C'était ça en fait, c'est pratique pour l'admins
qui doit se connecter
et relancer un procès.
Quand on dit
dans une entreprise et qu'on doit faire redémarrer
les services, on fait du Sudou, on a
pas ces considérations en tant qu'admins
de système, il ne faut pas croire,
la majorité des admins de système n'ont pas
ces considérations de sécurité et compagnie. Ils doivent
exécuter des services.
Sudou, sur moi.
Exactement, Sudou, sur moi.
C'est ça, la réalité du terrain, elle est là.
Oui, mais du coup,
ce que tu dis, c'est que les gens qui
ont refusé systemes des entre guillemets
je parle pour encore une fois l'aspect
de service, je pense
c'est même pas pour de la VM,
c'est des gens qui m'aident tout
non isolés sur la machine
tout dans OPT, dans Home, je ne sais pas où.
Pas d'isolation aucune,
tout va bien se passer,
parce qu'aujourd'hui,
tu peux avoir quand même du system dnspone
ou voir comment s'appelle le nouveau
VMSpawn ou quoi.
Ou machine CTL,
tu as des outils pour gérer même des VM
sur ta machine qui industrialise ça bien mieux
que d'aller le faire,
de le trouver mis à la mano.
Ouais, il y a un côté
de refus de changement, parce que
effectivement, tu as des gens qui vieillissent et qui disent
wouh, c'était mieux.
C'est ça, déjà il y a ça.
Mais en vrai, on est quand même dans
un domaine qui évolue, il faut le suivre.
Le UNIX dans sa définition,
tu vois, c'est Sudou.
Et Sudou, c'est un défaut du UNIX,
clairement, faut se le dire.
C'est pas parce que,
je suis pas un ingénieur, je suis pas un religieux.
Je mets pas
des trucs sur leurs pieds d'estal en disant
tiens, ce truc là,
c'est une fin en soi.
C'est là pour l'éternité, etc.
En fait, on est censé
faire vivre des choses.
Il y a des qualités dans plein de trucs.
Les systèmes bsd, ils ont plein de qualités.
Ils ont aussi des défauts, les systèmes Linux,
ils ont des qualités, ils ont des défauts.
Tout ça évolue, mais c'est sûrement pas en restant
sur ce que tu as toujours fait depuis 40 ans
que les choses vont mieux se passer.
Non, c'est clair.
Pour le coup,
quand on a commencé
à faire, moi, quand j'avais commencé avec mes équipes,
j'avais une vingtaine d'ingénieurs
qui faisaient, alors ils faisaient pas du Linux, ils faisaient de la IX.
Tant vous dire que
comme système,
l'UNIX d'IBM, comme système qui est un peu
figé dans le temps, donc vous avez des personnalités
qui sont très figés dans le temps.
Et c'est très compliqué de leur dire,
non, mais ça, ça va changer en fait.
On va faire évoluer les pratiques, on va passer
à de l'automatisation.
Et le premier réflexe, c'est comment je pourrais
me connecter à la machine pour aller faire mes commandes,
mes scripts, mes machins.
C'est très compliqué, on est très attachés
à une énorme résistance.
Et après, il y a aussi le fait que
même si le produit n'est pas parfait, il y a eu
quand même des problèmes de personnalité de celui
qui gère le projet, de Lénart
qui est pas forcément
ouvert à la critique
ou ouvert à comment
potentiellement des évolutions
de son système.
Il y a ça aussi qui coince.
Ce côté complot, hegemonie de système D
pour devenir un SV host
comme sur Microsoft.
Ça aussi, j'en ai lu 2, 3D comme ça,
c'était assez épique.
Non, le démarrage d'une machine
avant,
en fait, c'est vraiment un problème
d'égo. Oui, mais système D,
ça ralentit le démarrage des machines.
Parce que moi, quand je fais
mes petits scripts de démarrage,
ça démarre vachement plus vite.
Quand tu as une machine, je veux bien,
quand tu en as 150 à démarrer,
à un moment donné, et puis que
tu dois garantir que tout est
tout fonctionne de la même façon,
ce n'est pas la même problématique.
C'est ça,
ça peut être un peu un étage
plus industriel.
Et en fait, contrairement à ce qu'on pourrait penser,
quand on voit un peu les galèques de système D,
le fédérationnalisé ne serait-ce qu'un peu la façon
de gérer les services par rapport
à une idée, ça rend tout de plus simple quand même.
Ça aide bien quand même.
Et justement,
je trouve que ce qu'on a
du mal souvent à entendre dans
notre domaine, c'est que
des fois, c'est bien de suivre la quête
de la simplicité.
Alors, il y a la transition, c'est bien,
mais en vrai, il y a un autre truc,
c'est le côté ingénierie encore une fois.
Ce n'est pas parce que le système D
c'est bien que tu vas le mettre partout.
Si demain ton projet, c'est de faire
une mini box avec
une sorte de firmware, etc.
Système D, c'est aussi trop gros,
trop gros pour ça, et tu vas peut-être
aller sur du système V, etc.
Mais, encore une fois,
question d'ingénierie.
Pas que de simplicité.
Là où parfois la simplicité
apporte des choses, ce n'est pas pour d'ailleurs.
La quête aussi éternelle
de la Silver Bullet,
la technologie. Il faut avoir
les transitions. Oui, ben attend.
Il faut avoir les transitions.
On a tout le monde après.
Moi, je vois les discours qui sont faits
chaque fois, c'est la nouvelle technologie
qui va tuer tous les autres.
Tu viens de te dire ça va tuer tout.
Et en fait, ça dépend du contexte,
ça dépend si c'est adapté, ça dépend ce qu'on veut faire. C'est pareil.
On a l'avantage d'avoir
plein de technologies disponibles.
Il suffit juste de les adapter, de
prendre celles qui sont les plus adaptées
aux besoins réels.
Aux besoins réels.
Histoire de pas tout compliquer.
C'est ça.
Ouais, c'est ça. Je te l'ai tué.
Non, mais pour ceux qui n'auraient pas eu
la chance d'assister
à la dernière session
de DevOps,
France,
les replays sont sortis avant
la première session de l'année.
On a un petit coup d'œil
qui s'appelle
Faire simple
la clé de la durabilité
que je vais regarder un petit peu.
Et en fait, qui me renvoie pas mal
à mon rôle
dans quelques discussions
qu'on a de comment on va faire les choses
un peu d'archies de logiciels
qui est de dire
en fait
dans le domaine et surtout quand on est passionné
on a tendance
à déconvoi un truc un peu shiny
un peu sympa
qui pourrait améliorer notre vie, elle le prend direct.
Et du coup
on a une petite tendance
à aller faire l'over engineering assez facilement
c'est un biais qu'on retrouve pas mal
et en fait je trouve ça pas mal
parce que tout le cas il amène
à s'interroger
déjà est-ce que livrer un truc extrêmement complexe
c'est un gage de qualité
ou pas
et en fait ce que ça peut être un peu dur à vendre
qu'on a passé des mois à faire de la R&D
qu'on a livré un truc très simple
alors qu'en vrai si, c'est à dire que le temps que tu passes
à amener quelque chose
à amener une solution simple
parce qu'affite bien le problème
ça a de la valeur
et en fait
l'idée
ce que j'ascentre c'est que
faire quelque chose de simple
mais de pas simpliste ça le rend robuste
parce que quelque chose qui est simple
c'est facile à maintenir et trouver
un moyen à régler un problème potentiellement compliqué
avec quelque chose de simple
mais en fait c'est bien, à la fois c'est légant
à la fois ça marchait de scale
j'en veux pour exemple
souvent je prends cette référence là
l'élément
qui va gérer par exemple
le
l'asservissement de l'altitude d'un avion
dans l'idée, ce genre de chose
ou le suivi de nos consignes
le suivi
d'une consigne de chauffage
c'est un truc en automatisme qu'on appelle un PID
un PID
c'est une boucle de rétroaction
c'est un grand mot mais en gros on prend
la valeur qu'on veut mesurer
et on compare la consigne à cette valeur
là et on la compare
c'est trois critères PID, c'est proportionnel intégral dérivé
donc on prend
un facteur de la température actuelle
si on prend l'exemple de la température
l'intégral
de cette valeur
et en faisant une opération combinatoire
sur ce truc là
juste avec la température
et une consigne on est capable de piloter le truc
de manière extrêmement simple
l'opération
d'un PID
j'ai plus le détail exactement
mais c'est une combinaison de cette proportionnelle
de cette intégrale de cette idée
c'est extrêmement simple à débugger
il n'y a pas de logique très compliquée
c'est juste trois produits
c'est structurellement simple
à la fois avoir eu l'idée de faire ça
ça prend beaucoup de temps
mais une fois qu'on a ce système là en place
il est extrêmement prévisible
on sait quels sont ses défauts
on les connaît, on les voit
on peut améliorer le truc
c'est globalement du tuning de chacun des effecteurs
c'est un bon exemple
du fait qu'en
travaillant un peu on est capable de sortir des choses simples
et qu'en fait c'est meilleur
parce que ce qui est simple est robuste
donc en fait
ce tool cache c'est un bon prétexte
pour
venir parler du fait qu'il faut
ramener un peu de simplicité
oui mais c'est pas vendeur
on est d'accord
moi je suis complètement d'accord avec toi
mais c'est difficile de valoriser
du temps
pour arriver à une solution simple
avec des réflexions de type
tout ça pour ça
c'est exactement
ce que je crois est adressé dans le tool
c'est la valeur
de l'expertise au final
c'est simple
pour moi
quand on parle d'ingénierie on nous dit
que dans notre rôle on se trouve
de solution qui soit simple
efficace, résistante
et on parle de
de la solution
de la solution nouvelle
je vais faire un commentaire
je vais faire un commentaire
tu parles de l'élégance
tu parles pardon
de l'itéraire
c'est pareil
il y a le côté tu fais simple
mais tu fais passer exactement ce que tu veux
avec le moins de choses exprimées possible
et ça c'est un peu
comme l'élégance
les latins ont inventé ça
je te mets avec nous ratio
les espagnols, les italiens
les français on a
ce bout de la bonne bouffe etc
mais particulièrement
le raffinement
c'est le modèle
où tu viens mettre des caisses
tu mets tout ce que tu peux
nous on a été éduqués dans le truc
on a été élevés et on le voit
c'est lourd
et tu es capable de le dire
dans l'architecture c'est pareil
après on revient à la question
il y a les bons
il y a les bons ingénieurs
alors le bon ingénieur
il va faire un impi
et puis ils ont chacun leur expérience
donc tu vois certains qui vont faire de la prod
d'autres pas
en soi c'est pas livré du soft
qui compte tu vois
encore une fois c'est combien ton soft
rapporte quantitourin
je vais faire un petit clin d'œil
il y a quelqu'un qui va sûrement écouter
ce comment, ce podcast
et c'est lui qui m'en a parlé il y a quelques années
la loi de Conway
ben nomme-le
c'est lui un petit délit
c'est Romain
c'est lui qui m'a expliqué
c'est pas du tout la loi de Conway
qui je trouve s'applique
un peu souvent
avec le fait que
quand une entreprise
doit concevoir un système
il y a de grandes chances que
ce système soit le reflet
de son organisation
et quand il y a
une organisation d'entreprise
qui est très compliquée
on peut arriver à des systèmes
très compliqués
il y a le MIT qui l'a mis en évidence
qui a réussi à prouver qu'elle était vraie
qu'à partir du schéma
du site web
de la hiérarchie des pages d'un site web
on peut rentrer à la structure de l'entreprise
et je crois que
la phrase de base c'était
quand deux équipes
sont impliquées
dans le développement d'un logiciel
il y aura une compilation de deux étapes
et on va avoir tendance à vouloir
en fonction de là où on est
à se replexifier
je suis à la CQ donc je vais rajouter ces briques
et on arrive à des solutions
qui sont à la fin très compliquées
et très difficiles à maintenir
c'est valable pour du produit aussi
faire un bon produit
c'est pas simple
parce qu'il faut mettre tout le monde d'accord
mais avec le bon dosage
quand tu as l'équipe machin qui veut s'exprimer
à l'auteur de ça
à la fin tu as un gros mouya
c'est ça
et je pense que ça devient
surtout dans la conception de système
je pense que ça devient de plus en plus
un enjeu surtout avec la croissance du marché qu'on a
qui est de dire qu'on commence
à se rapprocher
enfin ça fait un moment qu'on le fait
mais il faut qu'on continue dans cette voile
à se rapprocher des logiques industrielles
de chaînes de prod de grands volumes
il faut que dans la conception
on rationnélise le truc au maximum
et on essaie d'arriver avec des solutions simples
fiables
qui scale bien
et ça on ne l'aura pas en faisant
des choses avec des mal décorations
et des ferritures dans tous les sens
et on a testé tous les derniers trucs hype parce que c'est bien
mais aussi on est rationnel
et je pense que ce qui est important c'est pas de dire
il faut pondre un truc simple
initialement
parce que ça c'est pas possible
par contre je pense que ce qui est important de garder en tête
et c'est ce que j'essaie de mettre en place
c'est de dire ok
tu me propose d'apporter cette amélioration
là dans le design qu'on est en train de pondre
c'est quoi le bénéfice de la amélioration
par rapport au coup qu'elle a en complexité
et souvent c'est un truc qu'on oublie de mesurer
et c'est comme ça qu'on se fait avoir dans ce piège là
parce qu'en ZRS ça c'est bien, ça porte un petit truc
qui est pas dingue par contre ça te complexifie
la codebase dans tous les sens
et du coup je pense
cet équilibre là il est intéressant
à avoir et c'est comme ça qu'on ira vers
des choses qui fonctionnent bien
il faut pas sous-estimer ça
c'est hyper dur de faire les compromis
parce qu'en fait
sur le papier t'as envie de tout faire
t'as envie de tout mettre etc
et être capable de se dire on enlève ça
parce que tant pis parce qu'à la fin le produit va être meilleur
et j'ai fait des choix et je les assume
pour l'utilisateur
c'est hyper compliqué
et enlever
ouais enlever c'est toujours compliqué
alors déjà des fois enlever c'est compliqué
parce qu'on sait plus à quoi ça sert
je l'ai vécu ça
c'est une des trucs c'est dedans ça existe
c'était tellement pas documenté
on sait même pas si on l'enlève ce qui va se passer aussi
parce que ça pourrait être vachement plus simple d'enlever
ouais mais on sait pas en fait
bon on le laisse alors
et tu vis avec des contraintes que tu as gardé
parce que tu ne sais plus à quoi ça sert
clairement typiquement le meilleur exemple de ce classe
c'est les interfaces HTTP
ou les protocoles de message
que tu gardes qui sont là depuis le début
tu vois
tu as la moitié des gens qui sont dedans que tu gardes pour de la rétro combat
mais euh
en vrai tu n'aurai pas besoin du coup tu passes ta vie à les réimplémenter
quand tu fais évoluer les systèmes
parce qu'en fait il faut que ce soit là
parce que sinon le truc va péter la déstabilisation
machin
ça un peu l'enfer
sur le volet un peu
tu vas prendre conscience que la complexité
c'est un peu un ennemi
et qu'il faudrait
et qu'il faut doser pour avoir
que ce qu'il faut de complexité
je pense qu'il y a quand même un peu une prise de conscience de ce truc là
notamment au niveau des gens qui font les langages
j'en veux pour preuve
un deuxième talk que j'ai vu que ça s'appelle
les nouveautés de Java 21
alors
Java 21 est sorti depuis un moment
mais justement il y a eu un talk aussi
à DevOps là dessus
qui amène des nouveautés de Java 21
et ces niveaux de la sont assez intéressantes
parce que c'est des outils
où justement
il y a une réflexion profonde qui a été
faite sur
comment
faire en sorte que les gens
développent avec du code plus simple
et quelles outils on doit leur fournir
et ça a été fait de manière un peu intelligente
un des points les plus intéressants
à mon avis dans Java 21
c'est l'avènement
des virtuals threads
pour ceux qui connaissent un peu
c'était
ça bled le projet Loom
avant
l'idée des virtuals threads c'est d'avoir
des threads plus légers qui tournent sur les threads physiques
et en fait
d'avoir un contexte switching
qui est vraiment peu coûteux dans la majorité des cas
on appelle les green threads
c'est ça
et ça permet d'avoir
du coup
de tirer partie
des threads
d'utiliser beaucoup de threads virtuals threads
qu'on pourrait créer de threads avant
et ça permet en programmant de manière assez simple
impérative
à la suite tout va bien
d'avoir des performances qui sont assez impressionnantes
ça va déjà optimiser pas mal
de codes qui tournent déjà mais surtout ça va
potentiellement pousser une bonne partie des gens
à ne pas faire du code très plombri
typiquement
pour un certain nombre d'usages pas tous
mais pour un certain nombre d'usages
ça enlève un peu la nécessité
d'aller faire la programmation réactive
dans l'approche
donc ça c'est déjà un point
qui va simplifier
et après j'avais à Spodernis pas mal
en amenant
des
des paramètres anonymes donc la capacité
d'ignorer un paramètre
dans une destructuration ou dans une boucle
ou dans sur deux choses
ça amène aussi
de mémoire le pattern matching sur les
types
si je dis pas de bêtises
à vérifier
et donc chose intéressante
toutes ces features là viennent
plus ou moins ou une inspiration commune
avec Scala
et en fait
ça me rend de voir que
tous les
langages et ça va y compris
ont tendance à vouloir les simplifier la façon
d'être utilisé
ce qui est plutôt une bonne chose dans le paradigme
dont on parlait tout à l'heure
dans cette même
veine là
il y a une news qui est tombée
le mois dernier
un mois d'avant je la sais plus
on n'a pas trop parlé en dehors de cet ecosystem
mais qui est assez intéressante
on fait beaucoup de Scala parce que notre control plane
est écrit dans ce langage là
mais
dans la dernière release de Scala
qui c'est Scala 3.4
je sais pas si on fait une depuis
mais ils ont mis
en experimental
une feature qui s'appelle le Capture Checking
le Capture Checking
c'est assez similaire
au Boro Checker de Rust
je sais pas si vous voyez ce que c'est
je peux réexpliquer depuis le début
ouais ce que je vais faire
en gros l'idée c'est que
quand on écrit
un programme
on va avoir des variables
et qu'en fait
en façon
en fonction de comment
et à qui on passe ces variables là
potentiellement elles pourront être absorbées ou non
si par exemple
je crée une variable
que je vais appeler non je vais mettre mon nom dedans
et je vais passer
en paramètres
mon nom à une fonction et bah après je ne peux plus accéder
à la variable mon nom
et si j'essaie d'y accéder ça va poser un problème
parce qu'en fait cette variable elle a été copiée
dans le contexte mémoire de la fonction
et le contexte mémoire de la fonction
quand la fonction a fini de s'exécuter il est supprimé
si on ne contrôle pas ça
ça amène
notamment des failles de sécurité
à la base des bugs mais aussi des failles de sécurité
qui est que si j'essaie d'aller lire
la variable nom
après l'exécution de la fonction
je suis en train de lire à un endroit où je ne suis pas censé lire
parce que j'utilise
l'adresse de
cette variable
ça c'est un exemple
parmi d'autres mais du coup il y a eu
plusieurs... une des façons historiques de gérer ça
ce qui s'est fait en ce cas là c'est de dire on fait plus de variables
en fait
on fait que des variables
immutables entre guillemets
et du coup on les déclare
avec une valeur par défaut puis ensuite on ne les passe en paramètres
et une fonction, cette fonction change la valeur
retourne une valeur et on prend la nouvelle valeur
retourner par la fonction pour continuer
ça résoule le problème
parce que du coup
on ne cherche plus à écrire
ou à accéder un truc
dans tous les cas ça ne doit pas serre dedans et être tourné
par contre
ça complexifie pas mal de codes
pour programmer comme ça depuis
2-3 ans
c'est un peu l'enfer
parce qu'il y a plein de situations à la con on se dit
là j'aurais adoré une variable parce que là je suis obligé de faire une copie
ça sert à rien, puis potentiellement on waste pas mal de temps dans la copie
sur des trucs qu'on a besoin d'optimiser
un peu et tout
l'approche que Rust a choisi
de prendre c'est de dire
en fait on va laisser, on va faire
des variables par contre au moment
de la compilation on va aller regarder
dans tout l'arbre du programme
est-ce qu'il y a un cas
où on essaie
d'accéder à une variable qui a été mangée par un autre contexte
ça s'appelle le BorrowChecker
le Browing c'est le concept
de prendre une variable
et de la déplacer dans son scope
et du coup Rust
en plus de plein de checks qui font sur la mémoire
font du BorrowChecking
c'est à dire que
le compléateur fait du BrowChecking c'est à dire qu'il regarde
tout l'arbre au sein du programme et regarde ce que tu fais avec les variables
dans tous les scopes
et à quel point tu les utilises bien ou pas
ça ça permet de coder
encore une fois plus simplement
parce que du coup on a pas besoin de mettre des complexités artificielles dans notre cop
comme le fait de justifier uniquement
des valeurs et pas des variables
et du coup ce cas là
ils sont un peu partis là dedans aussi
et du coup ils ont appelé ça du Capture Checking
j'ai pas trop la différence
mais dans l'approche ça semble être quand même assez similaire
et ça ça nous va nous permettre
là où ce cas là on se donne la programmation très fonctionnelle
très créé les effets de
enfin cacher les effets de bord etc
à peut-être dans un certain nombre de scénarios
pour pouvoir aller faire des choses beaucoup plus simples
et je pense que c'est une bonne chose
et je pense que c'est simple pour l'industrie
que les langages continuent de pousser
pour être le plus adapté et fournir des outils
de plus en plus
puissants et à la fois simples
pour permettre d'avancer dans le bon sens
donc à tous les gens qui pensaient
moi ils comprenaient il y a quelques mois
que peut-être j'avais allé commencer à bouffer ce cas là
c'est pas prêt d'arriver
et ce cas là continue de pousser dans son coin
pour ce qu'est de ce domaine là
non mais il y a plusieurs choses
d'une ça veut dire que
ce cas là
peut devenir demain un langage natif
ne plus forcément dépendre de la JVM
à ta scala native mais c'est un peu long
ouais ouais mais là
le brochaker fait qu'à un moment donné
tu vas pouvoir avoir entre guillemets
à la compilation ta gestion de mémoire
qui va être effective et ne pas avoir de dépendance
importante à ton gc
et de deux bah ça veut dire que d'un point de vue
industriel
l'écosystème java il est hyper
dynamique fin il bouge
comme jamais le java
21-22 ce que ça va devenir
c'est un langage hyper moderne
autant il y a quelques années il y a des gens
qui sont un peu allés sur cote ligne parce qu'ils étaient
13 jvm ils voulaient la compatibilité
ils voulaient un langage un peu plus
moderne etc
je suis une entreprise aujourd'hui
je suis pas seul je vais sur cote ligne
euh
j'ai pas un gros passif de développeur java mais
ça fait penser
et une vanne
qui m'est venue quand t'as parlé de java 21
je pense qu'il y a encore beaucoup de boîtes
qui se font avec un java
à un seul chiffre
ouais
on va pas se mentir
je pensais pas dire ça
un jour mais le live cycle
enfin le release live cycle de java
c'est le même que kubernetes maintenant
je pensais pas dire ça
un jour mais c'est tous les 6 mois
beaucoup de langages ont
arrivé j'ai pensé
pendant que tu nous expliquais
tout ça
ça devient très compliqué pour les entreprises
c'est un peu plus compliqué

justement avec la logique
notamment un peu franco-française
j'ai investi le déploiement
voilà
et quand je dois faire la migration
je dois porter la migration
en java 21
il y a 1500 jours de test
à faire pour les utilisateurs
je peux pas y aller machin donc ça reste
on va rester en java 8
ça devient très compliqué à suivre
pour les entreprises en termes d'investissement
en termes de comprendre qu'en fait
l'investissement il est constant
c'est à dire que le cycle de vie de ton application
et bien une fois que tu as lancé ton application
c'est jusqu'à ce que tu
fermes ou jusqu'à ce que tu changes
ton outil c'est ton outil
on n'est pas habitué à ce genre de fonctionnement
en termes de développement
je pense pas forcément aux applications
pas aux entreprises
du monde de l'ITEM mais vraiment les entreprises
qui veulent se développer leurs propres outils
entreprise de transport maritime
par exemple
c'est un peu compliqué de devoir
gérer ces cycles de vie qui sont très très très
court
là où on a une logique comptable
d'amortissement sur 3 à 5 ans
un cycle de vie à maintenir tous les ans
c'est compliqué
et justement
il y a
le monde du test évolue pas mal
ça fait on commence à voir pas mal
le chose arrivé
du genre
dans le domaine notamment de la simulation
pour se dire comment est-ce qu'on est capable
de avoir du coverage de test
qui est très pertinent avec peu d'efforts
avant on se disait
au début on faisait pas de tests
après on se disait
on va faire des tests unitaires machin
puis fonctionnels, pluie d'intégration etc
mais on s'est rendu compte que c'était très coûteux
et qu'on avait jamais 100% de coverage
chaque fois qu'il y avait un truc qui bougeait il fallait faire les tests
ou alors ça a poussé à l'immobilisme
du coup les gens se sont dit
comment on attaque le problème autrement
il y a eu pas mal de choses dans le domaine de la simulation
et du fuzzing qui sont arrivés ces derniers temps
et
moi je suis en train de bosser en ce moment
sur du système distribué
je me suis retrouvé
à me dire j'aimerais bien sans aller
jusqu'à la simulation
pouvoir faire de l'injection
d'erreurs TCP
entre différents composants
et je suis tombé sur un projet alors qu'il n'y a pas neuf
mais c'est une découverte pour moi qui s'appelle
Toxy Proxy
qui a été développée par Shopify
et en fait c'est un
proxy TCP
qui est configurable
dans lequel on peut introduire la latence dans les paquets
on peut drop des paquets, on peut faire un peu plein de choses
merveilleuses
qui vont avoir tendance à créer des effets de bord un peu marrants
entre différents composants TCP
l'avantage que ce soit au l'ailleur de TCP
c'est que ça permet aussi de tester des choses comme des bases de données
des choses qui ont des protocoles un peu plus bas niveau
que purement de le faire en proxy HTTP
et la chose qui est merveilleuse
pour les gens qui connaissent
c'est qu'ils ont un test-containeur
je ne sais pas si tu connais David
les tests-containeurs
si tu vois ce que c'est
je vais être très honnête de vous
les tests-containeurs
c'est une libre
qui existe notamment en Java
en Rust et il y en a plein d'autres
de support de langage
mais dans l'idée c'est des conteneurs
du coup d'aucœur
que tu peux lancer depuis
une classe dans tes tests
tu dis par exemple si il y a un trait
qui va s'appeler un Redis-containeur
tu va exercer le trait Redis-containeur
et l'extension de ce trait là
va te démarrer un container Redis à qui tu peux parler
et du coup
là typiquement
je vais faire
une classe ou un trait qui va étendre
le Redis-containeur et qui va en même temps étendre
le Tuxi Proxy
et me dire je vais avoir un bad
Redis-containeur
et quand je vais me connecter
à lui et dynamiquement
moi pendant mes tests je vais pouvoir lui dire
tu rajoutes 210 ms de latence au paquet
à tous ou à 3
et faire un
ton scénario test pour un check
tu peux dire
je configure le proxy TCP comme ça
et du coup
je trouve ça assez merveilleux
et ça permet de faire du phasing un peu marrant
et éventuellement vu que tout est pilotable
programmatiquement du random phasing
ce qui est encore plus intéressant
c'est à dire que quand tu fais tes tests d'intégration
tu lance
10 fois tes tests
avec des règles de tests ou d'injections de faute différentes
pour essayer de voir si tu peux pas réussir
à déclencher des effets de bord et augmenter encore ton co-prach
c'est pas mal
après c'est vrai qu'on est encore loin de la culture du test
notamment en France
on est quand même un peu loin encore
parce que ça coûte cher
et qu'on veut faire le time to market
c'est très cher
et ça prend du temps
et c'est compliqué de dire
mais il faut tester
et donc où est ça ?
c'est pas ce que tu développes aussi
il y a plein de trucs
sur lesquels on est passé au-delà des tests
effectivement on fait de la simulation
c'est le cas de notre serveur SDB
c'est le cas de l'orchestrateur
c'est le cas de plein d'autres trucs
et en fait
en termes de coûts
je suis pas si sûr que
ça dépend de ce que tu fais
ça dépend du logiciel etc
mais tu vois il y a des trucs sur lesquels
ton orchestration tu veux qu'elle marche
tu veux être sûr que tu veux pas
tu veux être sûr que tu veux pas
tu veux pas qu'elle te donne client
j'espère que vous testez
au programme
et même t'as DB
tu as t'as DB
tu veux pas faire ta donnée
le maximum d'intégrité
sur ta donnée est possible
et tu veux être sûr que dans tous les cas
tu vas vérifier ta Strict Serializability
Serializy
bref
ton modèle d'isolation
derrière
et tu veux le vérifier
parce que le jour
où tu as un problème
de production dessus
et que t'as perdu de la donnée
ou t'es dans un incident
et que tu perds de l'argent toutes les secondes
parce que t'es pas en train de résoudre le problème
le service
bah là
tu vois le coup de tes tests
il te donne très relatif
quand tu...
oui pour une entreprise comme t'as...
tu vois ce que tu veux dire ? oui c'est pas un budget
tu as le budget maintenant c'est le budget de développement
mais en plus quand t'es une entreprise lambda
qui développe un outil pour elle
en général 80% du temps
ce qu'elle va développer c'est un outil gestion
c'est un outil de...
tout à fait, très souvent
et après malheureusement
la solution c'est peut-être pas...
tu vois c'est peut-être pas hyper adapté à ça
mais les tests fonctionnels même pour de la gestion
en vrai c'est pas cher
mais c'est pas cher
en fait le problème
moi ce que j'aime bien justement
tu vois
t'es en train de parler
tu vois ta réaction en tant que développeur
de se dire tiens je pourrais faire ça
on a quand même créé une génération de développeurs
la génération d'avant
notamment qui faisait du Java
à bosser sur...
avec pas mal de gars qui sont partis
faire des MBA d'ailleurs
très stombard
à qui on a dit
ne vous préoccuper
que de l'aspect
métier de ce que vous développez
finance
compta
pas du reste
parce que le reste c'est la prod
c'est...
c'est sale c'est le monitoring
le machin c'est leur boulot
c'est leur boulot et puis si votre application
elle marche pas c'est pas grave on va rajouter des CPU
on va rajouter de la RAM on va rajouter du...
voilà ça ça a été quand même
ça a duré un bon moment
on commence à sortir de là
mais pas partout pas partout
comment se faire discuter
même j'ai eu des discussions avec des développeurs
représentant de l'infra
de leur dire les gars vous êtes sûrs de...
un data scientiste
j'ai besoin pour faire machin d'une machine avec
46 CPU
mon appelier elle tourne pas
une machine avec 46 CPU
obligé de lui montrer que son truc en fait
il était tellement mal codé qu'en fait on avait qu'un qui tournait
parce que son truc des monos rd
les gars
on les a serinés quand même à bosser
d'une certaine façon
et le reste c'est pas le problème
un data scientiste il bosse en piton
non mais data scientiste
c'est un bon appart
les data scientistes je vous aime
mais euh...
ce qui est intéressant dans ce que je dis
c'est que...
effectivement les tests a un coup
et toute la nouvelle approche de tests qui est de se dire
en fait on va simuler
où on va faire un peu de random fazing
ou des trucs comme ça c'est qu'il y a quand même
il commence à devoir de plus en plus d'approche
ou en fait c'est un investissement
que tu fais initial pour tout un grand scope
et que même pour plusieurs applications en fait
et euh...
ça te permet justement de pas avoir à coder les tests
c'est à dire que tu fous le truc dans ton simulateur
et ça te sort les bugs
t'as plus besoin de te dire
qu'est ce qu'il faudrait que je le code comme test
donc en fait à court terme c'est un investissement
à moyen long terme sur la même application
c'est une économie
tout à fait et en fait
j'en veux pour preuve un projet
enfin une boîte que je trouve super intéressante
qui s'appelle Antithesis
où les gars ont carrément fait un hyperviseur
de tests
déterministes
ou en fait à partir d'une seed
une graine
pardon ce mén
et en fait
le hyperviseur va toujours avoir le même comportement
et du coup il va
introduire plein de choses via le hardware
qui vont mal se passer
et du coup
là c'est magicster
tu code ton app
tu définis le comportement qu'elle devrait avoir
et t'attends
et tu lances juste le truc plein de fois
et ça te donne
comment est-ce que l'app a foiré
donc ça t'a vraiment
quasiment 0 coups
tu dois juste dire comment est-ce que ça va fonctionner
c'est le niveau 0 du test
donc en fait je pense qu'on
va se diriger vers un moment
où il faut aller
il faut que tout le monde aille par là
et que ça fera en sorte que les applications marchent
pour peu de coups
le problème
enfin moi je suis entièrement d'accord
et je valide ce point
mais tu te retrouves quand même confronté
on en parlait
il y a un petit moment
il y a énormément aujourd'hui de gens qui sont
développeurs
qu'on fait
du GIS dans leur vie
il y a énormément de systèmes qui leur proposent
tout un tas de choses
ou c'est magie qui n'a pas besoin de se préoccuper de plein de choses
et ils ont l'impression
de faire des applications
moi pour moi c'est ça c'est qu'on leur donne
l'illusion de développer des applications
avec tous des services package et des services manager
vous n'avez pas besoin de gérer ça
vous n'avez pas besoin de vous préoccuper
les services manager
pour faire le café
votre place
et qui vont se préoccuper de toutes ces notions
de résilience
de la perte de données
c'est tout, y'a pas besoin
ouais mais ça pose des vrais problèmes
c'est ta proche que du coup les gens qu'on prennent plus qu'ils font
j'en veux pour preuve
ouais
mais que tu
quand tu viens du monde
où tu
ont tuis là un espèce de
de conteneur
Kubernetes ou Steroid
où tu colles ton oeuvre dedans et ça te fait tout
ça fait le réseau, ça fait le machin, ça fait le truc
en fait ce que tu fais c'est que tu déquelles la complexité
c'est ça
de gestion dans le système
mais sauf que comme pour tous les autres problèmes
quand au lieu de très des problèmes à la source
tu déquelles la responsabilité sur un autre truc
ça rend les problèmes 10 fois plus complexes
donc déjà c'est une nouvelle idée
et à force aiori parce que les gens
pour les meilleurs actionneurs pour faire en sorte que ça se passe bien
c'est les gens qui développent les problèmes
donc en fait tu faut arrêter je pense ça de logique de se dire
on va découper le problème
et de toute façon
on va faire que du code métier
même ton code métier à la fin il faut qu'il fonctionne
il faut certes
traiter les problèmes de optimisation quand ils arrivent
mais
il faut les traiter
et ça on le voit pas mal de mon point de vue
quand on a des gens qui viennent de ce monde là et qui débarquent sur le pass
c'est qu'en fait
bien tu vois
c'est qu'en fait
du coup
là on fait beaucoup de choses
dans le pass on fait beaucoup de choses pour toi
c'est à dire que
c'est sûr que si le truc crash
eh ben on le remet en ligne etc
mais par contre on te donne des indicateurs
et toi tu dois servir des indicateurs
pour améliorer ton poids
et là t'as plein de gens qui sont perdus
c'est en fait vraiment que le code métier est métier et ils comprennent pas les indicateurs
et du coup ça demande un peu
une réacculturation
à une re responsabilisation
sur
bah oui ce que tu codes
ça impacte les performances
ce que tu payes etc
parce que
bah c'est à la fin c'est ton code qui tente
non mais ça c'est
moi le passe
une grosse partie de ma vie je t'ai contre
position étonnante pour quelqu'un qui vient du système
exactement
et donc
chez Eclanique on a une digital factory
justement qui fait des développements
et c'est comme ça que je suis arrivé chez vous en fait
c'est comme ça qu'on est arrivé
donc on a entièrement migré toutes les applications
il y a eu
quelques petits
réglages à faire
pour se mettre dans le contexte de
on est en train de développer une application
qui
elle est pas dans un endroit
au sein d'un cluster cube
ou au sein d'une vm
où on peut se parler
parce qu'on a le comment
l'illusion qu'au sein de la vm on peut
parler
librement
les flux ouverts voilà
quand on doit migrer ça c'est à été
quand on avait fait du justement j'avais mis
j'avais démarré avec de l'openshift aussi il y a longtemps
où je demandais au développeur de chiffrer
la communication entre les containers
pourquoi faire ?
parce qu'un jour vous aurez
votre container A qui sera dans un endroit
votre container B qui sera dans un autre endroit
et si vous n'avez pas déjà prévu
le mtls entre les deux
et ça va être la merde à gérer
et c'est arrivé et là c'était pas
quand on est passé de notre cube
notre eks traditionnel
où on avait déployé nos applications
à claveur cloud
les
containers frontes on va dire les anciens
containers frontes avec les containers back
ils pouvaient pas s'appeler de la même façon
donc il a fallu un petit peu changer les paradigmes
mais l'avantage que ça a justement
d'être passé c'est que ça a un petit peu
ouvert les chacras de nos développeurs
c'est à dire qu'il y a maintenant ils ont une conscience
avec la console claveur etc je vais faire peu de pub en même temps
mais
voilà c'était
je trouve ça le passe c'est très très adapté
au développeur
moins aux ingés système
maintenant c'est vrai qu'avec le recul
je suis plus vraiment un ingé système
je prends des décisions un peu financières aussi
mais
toujours sensibiliser
ces développeurs à être conscient
de ce qu'ils sont en train de faire et pas juste
ça marche sur mon poste
enfin le nombre de développeurs qui m'ont dit mais ça marche
sur mon poste
mais en fait c'est
complémentaire c'est à dire qu'il y a des trucs
tu fin quand c'est une application
que tu développes toi même et sur laquelle tu t'aires
beaucoup c'est le passe c'est très avantageux
quand tu vas vouloir aller faire tourner
un sombre soft distribué qui est utilisé
par trois personnes et qui est pas proposé par ton
cloud provider tu vas vouloir le gérer toi
on y est pas encore
mais on va proposer des produits qui permettront
d'avoir plus de contrôle
c'était le moment que j'ai cité
ça fait partie des choses sur lesquelles je travaille
mais oui bien sûr que le passe
ne répond pas à tout mais c'est pas non plus
qu'on devient mais par contre ça répond
bien au besoin des développeurs
tout d'accord
on revient à ce qu'on disait
et on va couper
il n'y a pas de solution unique idéale
il y a des solutions adaptées
à ce qu'on est en train de faire
et on peut arrêter
le dernier débat là
sur cub ou avec le mec qui avait lancé sur twitter
si à notre époque
tu es admin 6 tu fais pas du cube
change de métier
parce qu'il parle bien sûr de cub manager
ce mec là
ton cube qui sait qu'il le fait tourner
tu crois pas qu'il y a des mecs qui ont du congouis dans les mains
et qui sont en train de le faire tourner ton truc
enfin c'est...
c'était mon ancien métier
c'était mon ancien métier
dans les mains dans le congouis
c'est des hype driven
oui
c'est ça
alors
moi je dis rien
ça peut résoudre des enjeux pour certains
moi je pense que ça va
il faut être conscient que quand tu es une boîte
si tu passes sur cub
tu vas aussi te construire une équipe de 5 à 10 personnes
pour le faire tourner
5 personnes pour le faire tourner en boîte astrante etc
et avoir d'autres personnes pour faire
la méthode
tour, l'observabilité, le truc, le machin etc
l'outillage
c'est pas gratos
je te dis pas que ça peut pas servir dans certains enjeux
mais
de ce que j'observe la plupart des gens
n'ont absolument pas besoin
et se créent plus de problèmes que de choses
quand on est passé chez AWS
dans mon chêmon l'ancien employeur
la réponse des architectes c'est
ah on va faire que du lambda
le silver bullet
j'ai trouvé une techno
où j'ai pas besoin de payer des admin 6
machin etc pour gérer tout ça
je vais faire que du lambda
et les gens ont cette illusion
en fait de se dire j'ai la techno
où
ça va être magique
j'ai plus besoin de personnes
de monitorer de machin c'est tout cuit
bon courage les gars
et surtout bonne chance
il y a de ça
voilà voilà
bah
ça me semble une bonne réflexion
pour arrêter ici
on a encore quelques liens
pour aller voir les prochaines épisodes
donc merci beaucoup
merci beaucoup David
pour nos autres compagnies
de dernier épisode
merci Antoine, merci Esteven
et à très bientôt
ciao
au revoir