Bonjour, bienvenue dans ce nouvel épisode de messages à caractère informatique, épisode
sans set.
Aujourd'hui nous sommes les 10 juillet de 1224 et je suis entouré de Yann-Merveilleute
el Qé, Antoine Sabodorin.
Bonjour !
Oula.
par ce présenté.
Antoine, qui tu es ?
Alors, moi je suis
un architecte technique d'experts,
plutôt en technologie Java.
Aujourd'hui, je travaille pour une société de conseil
qui s'appelle Siam, qui est basée à Paris et à Toulon,
et j'interviens chez des clients
sur comment sauver des projets qui sont plantés,
les gros projets en général, soit les concevoirs.
C'est ce que j'ai amené à faire ces dernières années
où j'ai travaillé sur un très gros projet pour un très gros banque,
et où j'ai fait du claque, justement, dessus.
Et avant ça, j'ai dit vie antérieure, la plus intéressante,
et tant que j'ai été chez Red Hat pendant 7 ans.
Et voilà, exactement.
Le mien, il est un peu plus usé que ça.
Moi, j'en ai un vrai.
J'ai été en charge de spécifications sur Java E,
principalement CDI, depuis c'est devenu Jackarta E,
et la spécification micro-profile.
J'ai travaillé sur les spécifications full-tolerance et help-check.
Et puis j'étais un peu là, on va dire, au lancement de Corcus,
avant de partir, pour revenir vers le service mes premières amours.

Ah oui, je suis Java Champion.
Je suis Java Champion, je suis Outstanding Speckleed
en 2017 ou 2018.
Non, le most Outstanding Speckleed, je sais pas ce que ça veut dire,
je sais pas si ça va être très...
J'ai un joli truc en plexiglas dans le service.
Voilà.
Stylé.
Bon, voilà.
Nickel, Erwan et Kitie.
Ben, moi, je suis donc un geek auto-didacte
qui a eu le privilège de servir pendant dix ans
une association à but non lucratif qui s'appelle la Mission Laïc française,
qui a pour but de construire et d'opérer des écoles françaises
à l'étranger de façon associative.
Et donc j'ai été DSI de cette structure.
Et puis depuis peu, j'ai eu le plaisir de rejoindre
Clever Cloud pour animer toute la partie croissance internationale
en tant que vice-président.
Nickel et Flo, tu nous rappelles Kitie ?
Parce que tu as habitué de ma si quand même.
Je fais quelques épisodes, effectivement,
mais c'était plus aux alentours des épisodes 50 de mémoire.
Bonjour à tous, je m'appelle Flo en tant
du bon du coup, je suis un dîner imager à Clever Cloud.
Je travaille beaucoup sur la partie réseau et automatisation autour du réseau.
Et du coup, l'opérationnel,
du lebanthigne, un petit peu de toi, Clever.
Voilà.
Merci. Et moi, vous savez, les discours, blablabla,
Espagnol perdu en bétagne, blablabla, les petits accents que vous pouvez apercevoir.
Et tout ça, je voulais refait pas.
Je m'occupe de la partie des frêles chez Clever Cloud.
Et j'ai l'honneur aujourd'hui d'animer ce podcast.
Bon va.
Vu que on a fait le présentation, on peut attaquer.
Je veux que on a plein de souillets
dans notre tiroir.
Allez, qui va se lancer sur un des souillets ?
Moi, je suis chaud à proposer
des rallyeins assez rapides qui se liaient autour du plugin et l'extension
qui était présente dans Chromium, qui a un petit peu fait le tour de Twitter,
notamment, Twitter Pikes.
Le plus vide, un Chromium de la version open source de Chrome.
C'est lui là.
En fait, on dit Twix maintenant.
On dit Twix maintenant, pardon, j'aime bien.
Dans l'idée, pour résumer l'article de...
Parce que c'est un tweet, du coup, à la base, pour résumer ce tweet là,
c'est une personne qui dévare, qui travaille sur Chromium et qui fait ces bizarres...
Je suis tombé sur une extension dans le code de Chromium qui permet d'exposer
à tous les sites qui sont incorporés dans le nom de domaine
étoiles.google.com.
Toutes les infos hardware et plus qu'un navigate.
Il peut vraiment proposer toutes les informations hardware.
Tous les métriques systèmes et pour les outchains.
C'est à toutes les propriétés systèmes.
Et possèmement, il peut faire plus que ça.
Et du coup, en fait, c'est parti, Norman.
Mais qu'est-ce que fait Google de ces données là?
Sachant qu'à la base, ce plugin était prévu pour pouvoir
faire fonctionner Google en goutte et MIT.
Voilà, et du coup, de là, on est parti sur un débat de pourquoi cette extension
est dans Chromium, qu'est-ce qu'elle y fait?
Du coup, elle est forcément plus dans Chrom et c'est dérivé.
Dans Brave aussi, et du coup, ça a suscité un petit peu...
Tu veux dire que c'est un Brave qui s'intargue
de être un de navigateurs les plus respectueux de la vie privée des serres et tout ça?
Exactement.
Il y a d'ailleurs Brave répond dans le
sred en disant, nous, à partir de la prochaine release, on va désactiver ce plugin
dans l'automatique parce qu'en fait, il n'y en a plus besoin pour utiliser Google
et tout Google in and out sur le browser.
En fait, ce n'est pas quelque chose de requis.
Et bien entendu, il n'y a pas eu de réponse officielle
de la part de Google ni de la team DEF.
Bien entendu, j'en ai pas vu en tout cas.
Après, j'ai regardé ça plutôt de loin en me disant quelles étaient les impacts
et ainsi de suite.
Et il fait un petit parallèle dans son sred.
Du coup, j'ai mis le premier, c'est un tweet dans lequel il s'autorépoue.
Et justement, il parle de Zoom, de trucs et des différentes affaires qui ont eu derrière.
Et je trouve ça intéressant.
Et il explique tous les navigateurs touchés parce que du coup, il fait le tour des
navigateurs, donc il me dit Chrome, Opéra, Brave, Microsoft Edge, du coup,
qui est une base Chromium et touchée aussi.
C'est assez intéressant de voir à quel point ça peut être assez violent dans
sa propagation.
Ça va, moi, je suis sur Vivelli.
Vivelli, ce n'est pas une base Chrome, mais...
Oh mon dieu !
Complètement.
Et je sais que
ce Firefox, on me parle maintenant, c'est pour une seule feature qui était trop
bien, c'est que du coup, je peux faire matcher ma barre en haut avec la barre
de recherche, avec la couleur de la page web et je trouve ça tellement bien.
L'espétique importante, Florent.
C'est ça.
Et du coup, quand je suis trouvé là-dessus, j'ai fait, ah,
effectivement, bien à l'eau, c'est hyper intéressant.
Voilà, je sais pas si vous avez plus d'avis là-dessus, c'était vraiment un
histoire de partage des animations de la base.
Tristement, ça me surprime pas trop.
Non, pas trop.
Et après, je me suis toujours surpris
et que ça fait écho à plein de progrès.
C'est à quel point quand il commence à creuser dans des progrès open source,
tu peux trouver des choses comme ça et tu dis, oops, c'est un peu trouvé par hasard.
Quoi ?
Alors, je vais ressortir un peu les cartons, mais je repense à
parce qu'ils sont en train de développer un OS qui s'appelle Fuchsia,
qui est censé remplacer Chrome.
Chrome est un jeu.
Et je demande à quel point ça
on n'est pas dans, ça ne serait pas imbriqué cette logique là dans cet OS.
C'est ce qui me fait un peu peur.
Et il y avait un blog poste, alors là, je ne l'ai pas sous la main qui parlait
justement de ce qu'ils pensaient faire côté remontée de neve, de l'OS,
jusqu'au Google.
Et c'était un peu effrayant de pouvoir se dire, en fait, tu fais une recherche
sur ton navigateur web et en fait, où tu cherches un truc,
dans ce sens, c'est le fichier.
Et ça fait des recherches sur Google et ça te propose des trucs et pour seulement
des trucs que tu peux acheter ou autres pour de la plus.
Mais ce n'est pas déjà le cas sous Android, en partie, non ?
Parce que j'avais vu des articles qui montraient pas mal d'infos
qui remontaient des smartphones sous Android, même si c'était
rendu par quelqu'un autre que Google.
Dans le milieu, il y avait des choses.
Je ne saurais pas dire.
Ça fait un moment.
C'est le problème de Google et c'est qu'ils ont donné des projets,
des produits, des outils incroyables, notamment pour le développement.
Mais moi, j'ai toujours un tout petit peu partagé parce que
on sent toujours qu'il y a un trade-off à un moment donné qui va arriver.
Ou alors pour les outils de développement, tout à coup, le truc disparaît.
Et voilà, le truc de développement est arrêté, il laisse les gens rascampagne.
Je regarde toujours ce qu'ils font de manière très intéressée parce que c'est
toujours, c'est souvent très intéressant, mais j'hésite toujours à utiliser leur techno.
C'est un truc superbe.
Mais tu ne sais pas que je vais décider que l'équipe qui le mantient, il est redondant,
il est lancé dans des subliettes.
Je me souviens du lancement notamment de Google Cloud Platform.
C'était des premières offres accessibles à tous de Cloud.
C'était fin des années 2000, je sais plus.
C'était peut-être 2010, un truc comme ça, peut-être un petit peu plus tôt.
Et c'était génial, mais il y avait plein de limitations.
Il fallait tordre son code dans tous les sens.
Développeur Javan, il y a plein de trucs qu'on ne pouvait pas utiliser.
Et j'ai l'impression qu'il y a un temps monstrueux à rentrer dans des standards
quand d'autres acteurs se sont lancés.
Et en même temps, ils ont travaillé sur des projets type Kubernetes.
Donc en fait, on est toujours très ambivalents avec Google.
Moi, je me suis bien que quand Kubernetes a commencé à pousser
et que j'ai attiré plus attention,
il faut que Google, la île de l'Ebonchoua,
plutôt que de sortir comme employé, pensons à Google,
ils sont poussés pour qu'il y ait la science,
qu'il se crée, pour que ça soit en gouvernance collaborative.
Ça me semble déjà très bon garantie pour Kubernetes,
mais aussi à la vue de...
On sait qu'on n'est pas bon pour maintenir ce type de projet.
Et que plus les gens vont avoir de mal à nous faire confiance.
Donc là, c'est à eux qu'ils sont faits les choix intelligents.
Mais je pense que ça montre qu'il y a des individus chez Google
qui sont probablement pas complètement alignés avec cette politique
qui fait que certains projets sont... comment dire...
récupérés ou transformés de telle sorte que tu perds tout l'intérêt du truc.
Et donc là, ils ont manœuvré pour faire ça.
Quand le truc était encore pas trop prévalant.
Mais bon, c'est...
Après, ce qu'il faut voir aussi, c'est que Kubernetes,
c'est une réécriture par des gens qui sont partis de Google de Borg.
Exactement, oui.
Et c'est quelque part comme le projet Prémétheus,
qu'une réécriture, je ne sais plus,
c'est pas de Monarch, par un ancien Googler.
Et en fait, ça apporte cette vision qui est assez intéressante,
même si elle est forcément un portée débat,
de venir refaire des outils qui existent,
qui en open source, et ta Google qui revient sur le mail dedans,
en disant c'est quand même venu que chez nous et on aimerait piloter le truc.
Mais en même temps, des fois, tu poses des questions
d'un point de vue technique qui sont en discussion
sur les scoliers qui ne font pas perdre du temps
que mettez open source pour en fait qui débarque sur le prochain truc.
Et juste toi, t'as perdu ton temps à faire du Kubernetes,
parce que avant, tu avais...
Je l'avais oublié le nom.
Je crois que c'est pas Nomad.
Nomad, oui. Nomad, c'est...
Qui faisait à peu près le même taf.
Alors, personnellement, moins bien.
Je ne sais pas, j'en ai jamais fait, mais pour le coup,
de ce que moi, j'en connais,
conceptuellement, c'est censé faire la même chose.
Et pensément, tu as tu fait perdre du temps à un industrie comme ça.
C'est...
Je pense que c'est un peu trop
de pensée pour penser à ce niveau de machiavellisme.
C'est très réel.
Il y a pas mal de précédents, quand même,
sur ce genre de problématique,
de créer une entité à part pour gérer
quelque chose important.
C'est... Il est toujours de bon ton de critiques A.I.B.M.
C'est les premiers qui ont fait ça, quand même.
La Fondation Eclipse, à la base...
La Fondation Eclipse, c'est l'idée quoi.
Mais là, au monde te reconnaît que c'est parti de vie, mon ami.
Mais oui.
Non, non, mais Eclipse, c'est l'idée d'eux,
mais aujourd'hui, c'est plein de trucs.
Il y a plein de projets qui sont dedans dans la Fondation Eclipse.
Mais à l'origine, c'était...
C'est quand ils sont sortis l'idée.
Moi, j'ai utilisé, moi, je suis assez vieux pour avoir utilisé Visualage.
Moi aussi, Visualage 4 Java, c'était mon premier éditer Java.
Voilà, exactement.
Le premier fois qu'il y a gagné de l'argent en Codan,
c'était avec Visualage 4 Java.
Et donc voilà.
Et on voit aujourd'hui pas mal d'acteurs du monde d'Open Source.
Alors, moi, j'ai parlé de mon ex-employeur Redat.
Il y a des décisions autour de projets
plus ou moins stratégiques de se déplacer vers des fondations.
Ça a coercus, ils sont en train de réfléchir à le bouger dans une fondation.
Moi, peut-être moins utilisé, mais toute la partie
de gestion des workflows cogito et tout ce qu'il y avait derrière KIE,
je crois que ça s'appelle, on suit ça de près,
parce qu'on l'utilise sur un projet.
Ils sont en train de bouger.
Ils sont dans le processus d'aller sur un page.
Apparemment, ça a l'air d'être très, très, très compliqué.
Ils ont beaucoup, beaucoup de mal avec les process.
Toutes les fondations sont pas veilles.
On a essayé de contribuer.
Et on s'est rendu compte qu'ils étaient complètement en focus.
Pratiquement,
toutes leurs tâches étaient salinées sur les processus.
Mais bon, je pense qu'il y a vraiment besoin aujourd'hui,
dans le monde Open Source, de trouver des moyens,
de rassurer les gens sur la pérennité des techno.
La meilleure façon de le faire,
c'est de le donner à un tiers, à un reprendant.
Et donc, on a accepté de perdre la gouvernance.
Ce qui est accepté de perdre de la gouvernance,
c'est quand même un truc, c'est courageux.
Mais je pense que ça aussi a une réalité business.
On a quelques pertes pour vestir
moins de temps et d'argent à maintenir quelque chose
que des gens peuvent maintenir à côté.
Donc, ça sera le métier.
Ils sont frimentés autrement dit,
c'est pas la même ligne comptable.
Et aussi, ça n'a pas garantie si tu veux avoir de maintenir,
comme Antoine a dit, si tu veux que d'autres personnes contribuent,
moi, je vais aller plus à Touréman,
contribuer un projet qui est dans son fondation,
qui contribue un projet qui est dans son entreprise
et qui demande de faire un rédice si tu vois ce que je veux dire.
Avec faire un rédice, c'est terrible.

Est-ce qu'on en parlerait pas du coup ?
Pardon ?
Est-ce qu'on en parlerait pas de rédice ?
On peut parler de ce qui s'est passé avec Rédice.
Mais pourquoi ?
On a dit que ça n'a pas révenu carrément parce que ça,
la blessure est ouvertée.
Juste pour clencher le sujet sur le move Quarkus vers une fondation,
aujourd'hui, on voit qu'il y a quand même
un nombre assez important de contributeurs à Quarkus
qui sont principalement des salariés rédat.
Je pense que quand il a rapougé, ce sera toujours le cas.
Mais ça permettra à des gens de venir
de manière plus sereine contribuer au projet.
Ce qui est déjà le cas, les gens, les contributions sont assez faciles à faire.
Mais bon, on se pose toujours des questions sur
le projet, à pas le contribuer, qui va devenir le code qu'on fait, etc.
Et là, je pense que ça va ajouter de la transparence
sur la destination du code, sa propriété intellectuelle et sa gouvernance.
C'est un peu différent pour moi entre la SenseF et d'autres fondations Open Source.
C'est le fait de organiser ce énorme truc, de attirer les contributeurs,
de les faire se rencontrer, de choses comme l'ancien CubeCon ou la SenseFCon.
Ils sont vraiment
une façon de faire
qui fait que c'est très agréable de contribuer carrément et que tu t'es
en sécurité, tu sais que ça va profiter, entre guillemets,
tout le monde de contribution code.
Ce qui est plutôt beau dans CubeNative et dans la SenseF,
parce que je trouve vraiment bien, c'est là où ils ont été très, très bons.
De mon point de vue en tant que tech, c'est qu'ils ont réussi à mettre des
abstractions un peu partout des interfaces, ce qui fait que tu peux un peu
décabler tout comme tu veux et câbler ce que tu en veux ou d'avoir
ta propre implementation de certaines, la certaine brique de tes composants et autres.
Ce qui fait que tu arrives, tu peux vraiment adapter à ton besoin.
C'est là où vraiment ils ont été très bons, de mon point de vue.
Si tu veux qu'ils te remontent,
aussi, dans des trucs qu'il y a d'autres fondations,
mais en plus, c'est force et tu les proyé à avoir de documentation.
A ce bien fait, à ce jour ou jour,
je veux que tu aies un peu de
toi en tant que geek auto-direct et tu te frotais à ça, Kubernetes et à sa dog.
Non ?
Ouais, les débuts de theCUBE, ça a été pour moi
baptême du feu parce qu'on avait fait le choix dans l'ancienne association où j'étais de passer sous docker.
Tout ce qui était VM historique parce que suite au...
parce qu'il y a eu un pire attache de l'état islamique de l'association à l'époque.
Et donc du coup, j'avais eu pour mission de tout reconstruire derrière et plutôt que de reconstruire
à l'identique à l'époque, donc 2015.
L'idée, c'était de se dire où on va partir sur du docker, on a commencé sur du soir,
et puis à la suite d'une docker cone, je suis tombé sur Cube via Rancher.
Je sais pas si vous connaissez la solution Rancher pour le foyer.
C'était le premier Rancher, le Rancher,
où que tu permettais de monter facilement ton petit cluster.
Exactement.
Tu sais pas où tu es, de quoi tu es, carrément ?
C'était super facile à déployer.
Donc tu avais une sorte de mini-tube déployé.
On a commencé à se lancer là-dessus.
Après, on a commencé à internaliser ça sur des bères métales serveurs,
et on a commencé nous à automatiser avec l'association.
Et comme beaucoup de petites équipes, même si on a essayé d'être agile,
même si on a essayé d'être DevOps à fond,
on s'est heurté à pas mal de problèmes.
La V1 a été un échec, la V2 toussait fortement, et la V3 a fini.
Malheureusement, je suis à AWS parce qu'au final,
on gagnait plus de temps à coder nos trucs, et essayer de maintenir une infrastructure.
Puis un jour, dans un TGV aléatoire que je devais pas prendre parce que j'avais eu
du retard, j'ai rencontré une autre personne au bar qui lui aussi ne devait pas prendre
ce TGV qui s'appelle Quentin Indan et qui m'a présenté la solution Cleaver Cloud.
En quoi j'ai présenté ce qu'on faisait sur Kubernetes, ce à quoi il m'a répondu
mais c'est de la merde.
J'ai dit, écoutez, monsieur, c'est compliqué de dire ça.
J'ai quand même économisé pas mal d'argent.
Il m'a dit oui, mais je pense qu'on peut faire mieux.
Effectivement, après, on a regardé pour passer chez Cleaver Cloud pour faire
des sacrées économies.
Mais c'est vrai que cube, l'avantage qu'il a eu pour nous, c'est que grâce à sa
documentation, et comme le disait précédemment, le côté plug and play où tu vas pouvoir
brancher tes load balancers, tu vas pouvoir jouer avec tes règles comme tu veux,
ça, franchement, ça nous a vraiment graffé facilité la vie parce qu'on a maintenu
à notre pic d'activité pendant le Covid.
T'achant qu'on géré des établissements scolaires dans plein de pays différents.
Il n'y avait aucun établissement en France.
Ça va de San Francisco jusqu'à Wuhan en Chine.
Donc pour un, si vous ne vous connaissez pas comme petite ville, elle est réputée pour
son laboratoire P4.
Mais donc du coup, on a dû maintenir 400 micro-services 24 heures sur 24.
Et on les a maintenues avec 1,5 Tp et pour un budget de 200 cas à l'année.
Donc pour une petite association à but non lucratif, ça nous a permis de faire
quand même beaucoup de choses sans mettre beaucoup d'argent.
Et c'est vrai que pour le coup, la documentation était vraiment bien écrite parce qu'en
terme de développement, on n'y a pas passé beaucoup de temps.
On a eu les expériences précédentes où on s'était nous casser les dents avant.
Mais c'est vrai que la transition sur une sorte de passe qu'on a créée automatisée
avec GitLab nous a fait économiser beaucoup de temps.
Et là où c'était vraiment intéressant, c'est que si vous voulez derrière, on a dû
acculturer, former tous nos collègues qui développaient dans les établissements dans
le monde à ces technologies-là.
Et l'avantage qui est, c'est que Internet, il est sans frontières.
Les connaissances, elles sont facilement accessibles.
Et très rapidement, on a commencé à monter des pôles d'expertise avec des équipes
qui après prenaient le relais et allaient former sur des bonnes vieilles commandes
CubeCuttle pour débugger quand il faut débugger.
Et puis surtout déployer facilement.
Et puis du coup, nous, ça nous a forcé à écrire aussi toute une grande quantité
de documentation souvent en anglais, mais des fois contextualisés dans différentes
langues comme l'arabe ou autre.
Le projet, les rendre les plus complets possible, c'est chouette.
Et à côté, il y a beaucoup aussi travaillé avec la fondation Apache.
C'est un peu la même retour que Antoine disait.
En termes de procédure, c'est carrément
compliqué, c'est extrêmement carré pour le meilleur et pour le pire.
Et de fois le pire, c'est...
Alors moi, c'est plus que ça.
Je me suis testé comme Antonio, comme Horacio, désolé.
J'ai testé la fondation Apache et la fondation Eclipse,
puisqu'on parlait d'Eclipse tout à l'heure.
C'est quand même Eclipse, c'est quand même un tout petit peu moins contraignant.
Ils sont un peu plus souples sur leur procédure.
Et quand on a...
Moi, j'étais au démarrage du projet Micro Profile
et j'ai vu la migration de JavaE vers Apache, vers Eclipse,
c'est déjà qu'à eux, désolé.
Et c'était beaucoup plus...
beaucoup plus souples et beaucoup moins,
comme on dit, passer 80% du temps dans les mises en place des procédures que sur Apache.
Effectivement, moi, j'ai vu deux, trois projets démarrer sous Apache et des beaucoup plus petits.
C'était un enfer.
Quelque part, merci pour la transition parce que ça me rappelle
de vous dire au cas où vous savez loupé que Cléver vient de rejoindre la fondation Eclipse.
Tout à fait.
Voilà. Et il y a plein de raisons.
J'ai vu l'article de bloc qui a fait un
maître d'Aléliane et tout ça, mais il n'est pas
si simple, mais il fait que
si la celles fondations qui aiment, les branches, les hauts pènes,
que les gens qui passent à
d'être, si, parce qu'on peut dire
l'opportunité, va s'en appartre de nationalité.
Oui, non, peut-être.
C'est beaucoup plus compliqué que ça.
La règle que s'applique à la fondation qui contrôle le code de projet que tu utilises,
et le van d'etre à la souillée,
non, c'est clair.
C'est pas que les gens oublieraient si les liens.
C'est ça.
Boba,
que penses que
qu'une fois plaignant ses souillets, si non, va
passer le podcast sur le Cidon qui a vu propos de Pioche, un autre
dans la liste.
Antoine, tu me disais que
que tu voulais nous parler un petit peu près de
de grands groupes, de Cloud, de tes expériences.
Et surtout de la partie de Bob, que c'est moi qui te fais tripper.
Oui, donc alors, là, j'ai vu Erwan avec les yeux plein de lumière sur
son utilisation, sa découverte de cube, etc.
Et je comprends très bien.
Moi, j'ai,
donc là, j'ai quitté en début février un gros projet qui va continuer sur moi
parce qu'au bout de trois ans, j'ai dû m'arrêter à cause du client.
Et c'est un projet qui a commencé en 2021 et qui finira en 2030.
Et donc, ce projet, c'est
ce projet, donc, c'est pour une très grosse banque européenne, le portage de
toute sa plateforme comptable de la farmigrée vers
les mainframes qui tournaient depuis 40 ans vers une architecture,
donc Cloud, micro-service.
Donc l'environnement Cloud, c'est du cube.
Alors c'est du cube.
C'est de l'IBM Cloud déjà.
Je pense qu'à là-bas, c'est peut-être pas le meilleur socle,
mais ça a un socle qui fait le taf, mais qui a été mis à la source de
de la banque en question.
Donc ils ont un Cloud privé qui s'appuie sur la stack IBM Cloud et dans
laquelle ils ont rajouté tout un ensemble de, comment dire,
un élément de sécurité.
Il y a des vies partout qui reproduisaient en fait ce qu'ils avaient dans
l'environnement précédent, qui était beaucoup plus orienté par Métal et à
mes compagnies. Et comme ils ont été poussés par le directeur informatique
d'aller très vite sur le Cloud, ils ont le dire, on va réinventer des processus.
Ils ont porté des trucs tels quels.
Donc on s'est retrouvé nous à être un des premiers vrais projets à faire
vraiment des microservices, à avoir vraiment besoin d'utiliser de la
scalabilité horizontale.
Donc d'abord, il y a tous des processus, la gestion de fichier très,
très volumineux.
Et donc l'idée, c'était évidemment de lancer plusieurs instances
comme dans un même service pour pouvoir démultiplier en parallèle la lecture
des fichiers.
On s'est rendu compte que tous ces trucs là qui étaient qui allaient de soi,
quoi, dans les environnements Cloud, c'était un enfer pour le faire sur
la plateforme.
Et en fait, on prend l'endure là, sur le moment où on s'énerve, on finit par
retrouver des solutions, ça prend beaucoup de temps, ça consomme énormément de temps.
Et on se rend compte que en fait, le problème de ces groupes, et ce n'est pas
le seul, d'autres grosses banques et d'autres assurances, donc elles sont passées
au Cloud parce que c'est dans l'air du temps, on va dire, mais elles ne sont pas
prêtes, elles ne sont pas prêtes dans leur organisation à le faire.
Donc on se retrouve à avoir une organisation qui date des années 80, 90,
très silotté.
Donc les gens qui développent sont les études.
Et puis à côté, on a l'environnement, qui sont complètement séparés, qui ont
des missions différentes.
Donc les gens qui développent, ils sont là pour livrer un projet, livrer de nouvelles
fonctionnalités, etc.
Et leurs buts, c'est de faire en sorte que la prod ne tombe pas, et c'est leur seul
objectif.
Donc tant qu'il n'y a pas, comment dire, une concomitance des objectifs et de dire
bon, effectivement, la prod ne tombe pas, mais vous devez également aider les nouveaux
projets, on n'y arrivera pas parce que tout nouveau projet, évidemment, est vu comme
une menace.
Mais c'était pas ça la promesse de DevOps, il y a un décès dans les années ?
Exactement.
Et donc il y a une étanchéité totale entre les devs et les ops.
Donc du point de vue de la banque, il y a bien DevOps, mais en fait, il y a un gros
slash au milieu.
Et puis même s'ils sont un peu écartés, c'est encore mieux.
Et donc on se retrouve avec des gens en plus qui n'ont pas été acculturés à
acculturés à tous ces outils, qui ne comprennent pas du tout.
Donc on se retrouve.
Enfin, je vous donne un exemple.
On s'est retrouvé à devoir expliquer que non, on n'allait pas faire des potes qui
faisaient des rivers proxy pour permettre d'accéder à nos API.
Et si vraiment, il voulait, voilà, si vraiment, il voulait avoir des, comment dire,
des rivers proxy, des lignes, des lignes, des lignes, des lignes différents pour des raisons
de sécurité entre ce qui était exposé vers l'extérieur et ce qui était en interne,
il y a peut-être une grèce, c'était peut-être un truc.
Les mecs, ils ont découvert ça au passage.
Mais ça a mis du temps.
C'est un peu trop.
Je vous mets à Lyon sur un site merveilleux qui s'appelle DevOps Topology,
qui explique d'une façon très graphique, de différentes façons comme des grands
groupes incorporent la culture DevOps et de façon,
de différentes façons comme les DevOps s'est implementé dans des grands groupes.
Et je pense que vous trouverez plein de
la description de plein d'endroits, de plein de topologie comme celle-ci de
oui, ils sont des DevOps, mais en réalité, et voilà.
Mais et donc,
je finis juste parce que quand même un truc un peu rigolo.
Et donc, on se retrouve par exemple
avec un environnement soutubes, mais qui n'est pas du tout élastique parce que
ce n'est pas pour des raisons techniques.
Comme on ne sait pas facturer en interne l'utilisation des ressources CPU mémoire,
ce qu'on va faire, c'est qu'on va prendre la consommation maximum du projet
en termes de ressources et qu'on va tailler le cluster comme ça.
Et donc, du coup, tu te retrouves à un environnement
alors que chaque projet paye, c'est de ce qu'on interne.
Bon voilà, quand même ça coûte un budget.
Oui, c'est la réunion de poly interne qui imbête le monde en réalité.
Trouve en fait et donc de pas avoir de scalabilité.
Tu vas pas avoir de scalabilité facilement, en tout cas.
Et tu te retrouves donc à avoir le pire de tout.
Donc tu es dans un environnement qui serait comme du entreprise
dans du cloud et quand même, je suis désolé de vous dire ça,
mais Cube, c'est quand même pas le truc le plus simple de la Terre.
Mais cette complexité, tu les changes contre plein de trucs géniaux.
Mais tout ça, c'est des branchés.
Tu n'arrives pas que la couche chiante,
mais tu n'as rien de... Voilà, c'est un peu le concept.
Et je pense que ce n'est pas un cas isolé et c'est un gros problème.
Et l'enjeu, je pense, il est d'arriver...
Et c'est compliqué, d'arriver à créer du...
Parce que ça ne viendra pas du niveau...
Vous devez...
Ça viendra du management de créer du matériel pédagogique,
de la vulgarisation pour faire comprendre
pourquoi il ne faut pas faire ça et comment il faut faire.
Et évidemment, il ne faut pas faire un truc trop violent,
il faut trouver des steppes.
Et je pense que ça, il y a un vrai, vrai défi pour pouvoir
faire adopter des archives de type cloud,
le risque étant qu'au bout d'un moment...
Et moi, je le suis en train de le voir,
que des gens fassent machine arrière en ayant pas compris
qu'ils n'avaient pas du tout fait le truc comme il fallait.
En fait, ce n'est pas du tout bien, ça coûte plus cher.
Alors, c'est vrai que ce n'est pas toujours une source d'économie,
mais c'est une source quand même de qualité de service.
Et de résilience des plateformes.
Mais pour tout ça, pour que ce soit là,
il faut quand même mettre en place tous les trucs.
Et je finis avec ça, après je vous laisse parler.
Non, non, mais...
Le meilleur exemple, au moment où on a...
Alors, je vous passe des détails.
On a dû aller dans l'environnement de production,
non pas pour mettre en service, mais parce que c'était le seul endroit
où on pouvait avoir les vraies données qu'on devait manipuler.
C'était impossible de les avoir ailleurs.
Ça, c'est un autre sujet.
Donc, on débarque dans l'environnement de production
pour avoir un environnement de test.
On a fait du test en production quand même.
Ce genre de trucs, ça nous a fait un peu hurler,
mais on n'avait pas trop de choix.
Et on arrive dedans et on se rend compte que tout à coup,
nos pods, on a tout développé en Coircus,
on a optimisé et tout et on a gagné des 10 000 secondes par 6 000 secondes par là.
Et on découvre qu'en fait, nos pods sont incapables de communiquer
avant 5, 10, 50 minutes, 2 heures maximum.
Vous êtes allés jusqu'à 2 heures.
Et on n'arrive pas à comprendre.
En fait, il y a une couche de sécurité qui a été rajoutée au-dessus
de l'occurrence de la pub qui s'appelle de Goumour
et qui a été configurée pour faire un mécanisme,
alors je n'ai pas le détail,
qui opère un mécanisme de convergence de l'ouverture des flux.
On parle de flux en interne au sein d'une application de procédure
qui n'est pas ouverte sur l'extérieur.
Vous imaginez que la comptabilité d'une banque n'est pas ouverte sur l'extérieur.
Et donc, cette convergence qui peut mettre jusqu'à 2 heures
faisait qu'il était impossible de déployer un show
puisque quand on déployait un micro-service,
il pouvait mettre jusqu'à 2 heures pour...
Et on va voir la prod, on a dit que c'est vraiment un problème.
Et les mecs disaient, ben oui, mais la sécurité avant tout.
Donc en fait, voilà.
Donc, les missions d'exploitation étant pour eux leurs priorités absolues,
le fait qu'une plateforme devient quasiment inopérable,
c'est pas un problème.
Un peu l'olève.
C'est ça.
Parce qu'ils ne sont pas comptables de ça.
Et je pense que tout ça, ça doit être repensé, retravaillé
pour qu'on tombe dans quelque chose de beaucoup plus vertueux et homogène,
une vraie synergie pour utiliser des termes modernes.
Ou on a vraiment du DevOps.
Et donc, on a des ops qui sont embarqués côté DevOps
et des DevOps qui connaissent un peu ce que doivent faire les ops
et de pouvoir travailler ensemble sur plein d'aspects de configuration.
Et en charge.
Et c'est surtout aussi des objectifs que l'idée c'est que tous les monde
travaillent ensemble pour faire avancer,
plutôt que nous sommes les gardiens de la prod
en une façon qui développe.
Oui, la promesse était là.
Malérosman, je l'ai vu malimplementée aussi dans plein d'endroits.
Le meilleur exemple de ça, c'est quand j'ai commencé à développer
et que je suis arrivé du coup à OVH et on m'a dit,
tiens, l'éclat de la prod, ton soft, tu le prends, tu m'en prods.
Et j'ai switché de faire un dev pour la beauté du truc à faire un dev
qui ne réveille pas la nuit.
C'est quand même vraiment bien.
Et du coup, tout ce qu'on se disait sur le cloud et tout,
les gens qui reviennent à rien, ça me fait un peu penser au lien.
Je l'ai mis dans le...
Il y avait un cloud dans le...
Oui, dans le back-log de nos liens.
C'est We Are Living The Cloud de DHH.
C'est le créateur de RUNI qui explique que eux,
ils sont allés sur le cloud, justement à fond,
en se disant, du coup, on va construire notre produit micro-service et tout.
Parce qu'en fait, j'ai une vision à faire ça.
Et à le poser, du coup, ils en reviennent en disant,
c'était bien, mais pour gérer nos coûts,
le service, c'est bien, on a compris comment on voulait faire et tout.
Pour gérer nos coûts, on va créer notre propre data center,
on va poser nos infrastructures dessus,
plutôt qu'au passé par un cloud provider.
Et je trouvais le lien hyper intéressant à lire.
Ça donne tout un recul sur le fait que, ouais,
les cloud providers, c'est hyper intéressant, ça permet d'avancer.
Mais ce n'est pas forcément la seule solution qu'il y a.
Et surtout, ça permet aussi de se dire qu'en fait,
ce n'est pas uniquement un problème d'implémentation aujourd'hui.
C'est juste qu'il y avait les mainframes.
Aujourd'hui, on arrive sur des cloud providers avec du Kubernetes et autres.
Potéciément, demain, on va dire que les mainframes étaient vraiment très bien.
On va revenir, il y a un moment où ça boucle comme ça.
C'est un vrai site.
Moi, je le vois, parce que ça fait...
Vous pouvez voir que j'ai un certain âge.
Donc moi, quand j'ai commencé,
mon ration, il n'a pas de cheveux, donc on voit.
En fait, quand j'ai commencé à faire
vraiment du dev professionnel, donc c'était le début des serveurs d'application
qui finaient d'apparaître.
T'es t'être ou je ne sais pas les jeux de GbOS ?
Et les gros qui étaient utilisés dans les projets et l'entreprise,
c'était des webspheres serveurs.
C'était...
La première GbOS, pas encore.
Oui, il y avait GbOS, c'était un des plus légers.
Bref, il y avait tous ces serveurs qui, à cette époque-là,
étaient très, très lent.
Il est marré de très lentement tout ça.
On n'a pas non plus...
Et donc le travail, c'était de se dire, on va faire des trucs qui vont
démarrer plus rapidement, donc ils ont tous plus ou moins réussi à le faire.
Et puis le clave d'être arrivé.
Et donc on s'est dit, putain, c'est génial.
On va déployer des petits bouts de code qui vont dialoguer entre
ce qui s'est imposé principalement, c'est les APRS,
il y a d'autres choses, ou en tout cas des traitements à sacronnes avec un
broker ou un truc plus compliqué comme Kafka.
Et donc on dit, oui, génial, ça.
Et maintenant, comment je fais pour opérer ma plateforme,
pour regarder ce qui se passe et tout, pour avoir un truc ou un mec qui n'est pas
capable de besoin d'avoir une formation de trois mois, peut quand même regarder
un petit peu ce qui se passe.
Et là, on commence à se poser des questions sur,
oui, alors je vais mettre des trucs de telemetrie, je vais mettre une sur-couche.
Moi, je vais chez beaucoup de clients où il y a du dinatras qui est assez génial.
Mais là, on se remet au-dessus de cubes, on récupère d'un info, on la consomme, etc.
Et moi, j'ai une impression.
Et puis là, voilà, on les compose en carré, on a des trucs qui vont gérer
les secrets, on a Volt, on a Icos, les machins, etc.
En fait, moi, j'ai une impression qu'à un moment donné, on va recréer
avec une autre philosophie, d'un moment avec beaucoup de standard,
beaucoup de trucs comme ça, mais en fait, on va recréer un serveur
d'application énorme qui est un orchestrateur de service,
où on va avoir des outils qui vont être, j'espère, à un moment donné,
en tout cas, il va y avoir des offres comme ça.
Et on voit qu'une solution comme un peu une chiffre va un peu dans cette direction.
Et où en fait, on va retrouver ça dans une forme transformée,
mais on voit vraiment cette truc de cycle.
On est content d'en tout casser.
Une fois qu'on a tout cassé, on se dit, mais quand même,
c'était pas mal le truc avant, c'était pas ce qu'il nous fallait,
mais il nous faut qu'on a petit à petit, brick par brick recréer le même truc.
Et je pense que c'est une tendance là qu'on va avoir émerger dans les années
qui viennent avec des gens qui vont retourner vers des trucs plus
monolithiques.
Il y a beaucoup de discussions sur le sujet problématique des modulites, notamment.
Je sais pas si c'est un sujet que vous intéresse, mais on est...
J'étais en... Comment dire ?
On a dit que chez un client, ils n'étaient pas niqués parce qu'ils avaient
suivi tout le brévière de l'architecture micro-service.
En tout cas, en termes de développement, ils avaient fait vraiment des
développements très unitaires.
Vous avez fait tout un développement hyper bien foutu en Vietnam,
ils avaient des planètes, donc ils avaient leur petit truc.
Et c'était vraiment presque des fonctions inutaires.
Disait, on a un enfer, on n'arrive pas à administrer ça.
En plus, on a des temps de latence énorme et tout.
Et on a dit, mais pourquoi vous avez une fonction,
parce que vous avez même un petit problème de granularité quand même ?
Faudrait peut-être penser à votre truc.
Et puis, on a dit, un micro-service, une fonction,
donc en gros, pratiquement un point par micro-service.
Et à un moment donné, on discute, on discute.
Donc c'était un de l'avant, on entend.
Et je leur dis, mais vous savez quand même que pour...
Parce qu'ils parlaient de réutiliser le code.
Je suis dit, mais vous savez quand même la base de la réutilisation du code avant
d'aller partir dans les trucs comme ça, c'est vous, vous faites une libre.
Alors un nuggets ou de tenette.
Les mecs, ils étaient là, ils redécouvraient qu'ils pouvaient faire ça.
J'ai dit, ils pouvaient éventuellement visager d'avoir du code en commun,
mais ils en ont mis en commun parce que...
Je veux dire, plutôt qu'ils fassaient des livrées, ils fassaient des sapelles à notre service.
Ah ouais, ah ouais.
C'est stylé.
Ce truc là, il n'y a que ce service-là qui l'utilise,
peut-être qu'il pourrait l'embarquer.
Et on se rend compte que ça peut rendre les gens dingues et c'est paradigme.
Donc si on ne se pose pas et qu'on regarde le truc,
on va partir dans des délires.
Et en fait, ça joue contre le cloud,
parce qu'il faut faire une bonne utilisation, il faut des...
Je pense qu'aujourd'hui,
enfin, nous, c'est ce qu'on a fait sur mon projet,
c'est qu'on m'a donné, on n'avait pas trop d'idées parce qu'on était
en mode très, très agile, on va dire, pour rester poly.
On n'avait pas trop l'idée du découpage d'un certain nombre de services
exposés à nos clients,
enfin, aux browser, puisqu'il y a une partie fronte dans le truc.
Et on s'est dit, bon, au lieu d'anticiper un découpage,
on va faire un gros service qui fait tous les trucs.
Et à un moment donné, il va se dégager des fonctions,
et ça sera plus simple de les découper,
c'est ce qui s'est passé.
Et en fait, c'est plus simple de partir sur un truc un peu monolithique,
certes, et puis après,
s'il besoin, s'en fait sentir de le découper en plusieurs services,
plus que de partir avec une mariade de petits trucs qui n'ont pas de sens.
Et on se dit, en fait, celui-là et celui-là, ils iraient bien ensemble,
mais maintenant, ils sont à l'autre bout de la Terre et on pourra pas le faire.
Donc, je pense qu'il y a plein de choses qui sont de l'ordre de l'expérience
et qui ne sont pas trop évoquées.
Mais l'artitecture est quelque part,
et je pense que les rôles des architectes aient encore des beaux jours de vain.
C'est clair.
Après, il faut surtout qu'on arrive à culturer
toutes les couches décisionnaires qui prennent.
Moi, je sais que j'ai eu beaucoup de mal d'expliquer comment justement
passer du monolithique au microservice.
Ça a été mon cheval de bataille pendant un long moment.
J'avoue que ça va être un peu débile, ce que je vais dire.
Mais moi, ça a été les petites BD,
Kubernetes, qui ont été faites par la fondation.
Et ça, moi, je les ai donné à ma DG.
Ils les ont lues.
C'était adapté à leur niveau technique.
J'entends et ça m'a permis de commencer à casser pas mal de choses.
Parce que quand t'essayes de faire venir de l'agilité dans le monde de l'éducation nationale
et très silotté, très structuré,
ça a été très, très, très compliqué.
Donc, c'est vrai que ces petites touches d'acculturation par BD,
des petites vidéos simples à hauteur technique de tout le monde
tant qu'on comprend le principe.
Pardon.
Et ça, c'est vraiment très bien.
Par contre, s'il y a un downside,
enfin, il y a un l'autre versant de cet aspect-là,
c'est qu'à force qu'on se rajoute des couches d'abstraction,
de couches d'abstraction en couches d'abstraction,
on en oublie justement la technique d'avant,
les bonnes pratiques d'avant.
Et comme je le disais en toit,
on se remet à réinventer une roue,
même si en fait on est en train d'inventer une roue qui arrêt
parce qu'on a oublié qu'on savait déjà faire des roues rondes avant.
Ce caricature un peu le trait.
Mais je veux dire,
le Kubernetes n'est qu'une abstraction au final d'une orchestration de Docker
qui est lui-même une abstraction des LX.
Enfin, on voit bien qu'on est de couches en couches
comme ça de plus en plus éloignés au granulaire.
Je veux dire, maintenant,
plus personne ne code en assemblure,
sauf les tarés comme moi peut-être.
Mais voilà, on est encore dépoignés
parce qu'il y a un truc qui nous fait kiffer
parce qu'on a découvert ça quand c'était notre moment.
Maintenant, on en est à la mode du no-code
où les gens ne savent même pu coder,
ne savent pas forcément qu'est-ce que c'est qu'une boucle littérative.
Mais du fait du no-code,
d'un enchaînement de choses vont arriver à faire des choses.
Est-ce que le code va être de la meilleure qualité
et c'est le meilleur code qui aura été codé sûrement pas.
Par contre, ça permet quand même d'envisager un accès
à tout le monde d'un produit digital,
ce qui est quand même un peu l'objectif au final de cette technologie.
Enfin, selon moi, plus il y a de personnes qui code,
plus il y a d'outils, plus il y a d'outils,
plus il y a de réponses à des problèmes.
Je pense qu'il y a deux axes pour essayer de limiter la casse là-dessus,
de faire en sorte qu'il y ait des meilleurs usages.
L'axe dont je parlais et dont tu parlais aussi,
c'est d'acculturez le management.
Il faut que les grands décisionnaires
et le middle management, qui n'aient pas de technique,
mais qui aient de tout cas à y mettre en mesure de comprendre les enjeux techniques
et cette acculturation,
donc il y a une forme de vulgarisation qui a assez coûteuse à faire,
parce que c'est toujours casse gueule la vulgarisation.
Tu te retrouves à faire des analogies qui peuvent être un peu scapevroses.
D'une part, et d'autre part, je pense que l'Étec, il doit être meilleur.
Il pourrait être meilleur.
Il y a un truc qui est souvent négligé,
c'est l'historique des techniques qu'ils utilisent.
C'est pourquoi aujourd'hui, Kubernetes, c'est assez de gueule là.
Pourquoi ? Quel problème ça a voulu résoudre ?
Et en fait, de se mettre ça en perspective et de ne pas dire,
c'est pas important, je prends le truc, il est là, je l'utilise,
ça permet d'avoir une espèce de...
sans entrer dans les détails,
une espèce de perspective qui te permet de dire,
ah oui, en fait, on a voulu résoudre ça, etc.
Donc en fait, je tire bénéfices de la plateforme
parce qu'il y avait ce problème,
et maintenant, il y a peut-être d'autres problèmes à résoudre,
et je ne me rattaque pas à un truc qui existait déjà.
Si on prend l'exemple,
désolé, je suis très focalisé sur...
Le projet dont je parle,
la banque dont je parlais,
ils ont fait de la médimigration cloud à la sauvage,
donc ils avaient des applications qui tournaient sur
des serveurs d'applications T-ClockSphere,
je ne sais pas si il y a du goût biologique là-bas,
mais il faut que l'on ait des gros serveurs d'applications,
ils les ont portés tel quel dans le cloud,
donc ils ont fait un putain de...
de nœud pour foutre le truc.
Et alors après tout, pourquoi pas,
ils sont obligés d'aller dans le cloud, bon, méton.
Mais en fait ça, ça a dicté
toute l'architecture cloud pour le reste,
c'est-à-dire que voilà,
ça va d'applications, architecture 3 tiers,
pouf, pouf, pouf, donc je vais découper les trucs,
également quand je fais du microservice,
ça te dit, bon,
peut-être qu'on peut voir les choses différemment,
et en fait il n'y a aucune réflexion,
des choses sont...
Donc ça va dans les deux sens,
c'est-à-dire que j'ai un historique,
et je ne le fais pas évoluer en me mettant au bout du jour
avec les pratiques courantes,
et réciproquement,
j'ai débarque sur une techno
et je suis aménézique de tout ce qui s'est passé avant.
Et je pense que ça, c'est des choses
qui pour nous, tech, dev,
est assez délétère,
parce que ça nous fait perdre de vue
l'objectif de la techno qu'on est en train d'utiliser,
et à peu son...
sa direction,
c'est-à-dire que nous, on est censé aller,
alors il y a plusieurs directions possibles,
mais voilà, pourquoi on a fait ça et où ça doit aller.
Et donc ce n'est pas un truc qui permet de découper des trucs
en tout petit morceau,
ni de mettre des gros monolithes,
et en raison de ça, on résout ça, ça est ça.
Bon, ça reste très...
Donc je pense qu'il y a vraiment un travail
dans les deux sens,
il faut que le management...
Déprend du recul.
Et que les devs comprennent,
les devs et les abs comprennent
pourquoi c'est là.
Et qui s'apprennent à travailler ensemble
pour revocler avec les dernières choses que tu disais.
Ça fait un joli projet.
Je vous propose qu'on regarde,
et vite fait quelques petits liens,
et on finit ce premier épisode.
Donc alors, qu'est-ce qu'il y avait par là,
par les gens qui voient...
Flotin ou Samia liens sur HAPROXY 3 et Crouvo?
Ouais, exactement.
HAPROXY est passée en version 3,
a fait une release code de délai,
donc il y a deux liens plus exactement.
Il y a le lien de la release de l'annonce,
et puis il y a le lien des nouvelles features
qui sont dedans.
Et je trouve ça hyper intéressant,
parce qu'en fait, on a sorti la version 1 de Sozu,
et on est en train d'implementer HTTP2.
On a une première implantation
qui va être bientôt testée en production.
Et ce que je trouve hyper intéressant dedans,
alors il y a plein de choses qui considèrent
le certificat TLS, les choses comme ça et tout.
Et il y a d'autres choses qui m'ont fait beaucoup plus stické.
Et c'est pour ça que j'ai mis les liens
dans le backlog de ma glaive et autres.
En fait, dedans, il y a des améliorations
des sticky tables.
Alors ça peut paraître un peu d'un comme ça,
mais...
Je veux dire, je vais vous expliquer
une version un peu plus détaillée
ou que ça va faire de la moitié de notre diance
et peut-être bien certain de s'entraîner.
D'accord ?
Oui bien sûr.
Sticky table, en fait, les sticky tables.
L'idée, c'est de pouvoir partager entre les différents
instruments d'achat proxy sur des machines différentes
l'état des connexions qu'elles ont au local.
L'idée, c'est que si pour une raison X, Y,
l'achat proxy perd ses connexions,
par exemple, je sais pas,
on arrête d'annoncer son IP
parce qu'on a décidé que cette machine-là
allait rentrer en maintenance.
Et du coup, tout le trafic elle gère
disparaît votre pas.
Il faut qu'on soit capable de ne pas couper ces connexions-là
qui étaient en cours,
mais de pouvoir les faire toujours tourner.
Et en fait, ces sticky tables,
ça permet de faire ça.
C'est hyper intéressant et c'est très puissant.
Et pourquoi j'en viens à ma glaive ?
Parce qu'en fait, dans les premières implementations
dans les papiers de recherche de ma glaive,
qui est le lebanseur de Google par ailleurs,
ils expliquent en fait comment faire en sorte
de ne jamais perdre ces connexions-là
et quel design qui vient par la suite.
Et ça fait écho chez moi parce que du coup,
actuellement, côté Clever Cloud,
on est beaucoup en train de travailler
justement sur cette prochaine étape
à arriver à Clever,
de comment on va faire les lebanseurs de la génération
avec forcément quelque chose qui n'est pas si jeune que ça.
Et du coup, je pourrais ça hyper intéressant dans chaque proxie
d'arriver à avoir des petits détails comme ça.
Et pour en revenir à HTTP2,
qui était à la base ce que je voulais regarder,
c'est comme on en parlait avec Héloac,
qui est une personne qui travaille pas mal dessus,
la difficulté de ce protocole-là,
qui sur le papier est beaucoup plus structuré qu'HTTPA,
qui paraît beaucoup plus performant,
mais qui est beaucoup plus dur à mettre en place.
Et il y a beaucoup de talk,
de Claude Flair là-dessus sur YouTube,
je vous laisserai chercher,
je vais pas les liens là tout de suite,
qui expliquent la difficulté.
En fait, c'est pas d'implémenter le protocole en lui-même,
mais c'est de gérer tout ce qui est congestion.
Par exemple, qu'est-ce qui se passe
quand vous êtes en roaming dans un train en train de vous balader,
et que votre connexion, c'est du dit méga octet,
et encore par seconde, je suis gentil.
Et que vous, on essaie de vous envoyer,
je sais pas, une centaine de méga,
qu'est-ce qui se passe, comment on gère la priorisation et tout,
et c'est là où HTTPA est beaucoup plus intéressant,
beaucoup plus performant là-dessus.
Il y a justement cette gestion,
mais congestion est hyper intéressant.
Et on le retrouve chez Claude Flair comme problématique,
chez Google, on en a Chrome et Firefox,
qui en parlent aussi un peu de l'implémentation côté client,
sur notamment la priorisation des flux,
des streams au sein de ce connexion et des requins.
Et en fait, dans l'annonce de la chaproxy,
ils en parlent comme quoi, en fait,
ils ont refait des modifications sur le protocole,
parce qu'en fait, c'est quelque chose de pas simple,
même si maintenant, ça fait quelques années que ça existe,
et avoir vraiment quelque chose qui fonctionne bien,
est vraiment déjà pas mal.
Et du coup, je vous le reviendrai,
parce que si c'était vraiment cette côté très difficile,
où on se dit, on va faire du HTTPD, on va gagner en perf,
ça va être bien, pas forcément,
il y a des cas d'utilisation où ça marche juste pas,
vous vous allez pas gagner,
voire vous avez même dégradé vos performances.
Et je pense notamment à tout ce qui était les chargements,
par exemple, si vous avez voulu télécharger des images,
par exemple, depuis un S3 ou autre,
faire de l'HTTP2, ça réduit les pertes, par exemple.
C'est contraintuitif.
Ok, merci Flo.
C'était le petit passage à chaproxy du.
Allez, un dernier lien pour finir Flo, everyone.
Bah écoute, je sais pas si ça rentrait dans les catégories des liens que tu attendais,
et moi, il y avait un outil que j'ai découvert récemment,
que j'aime beaucoup, qui s'appelle Mini Fold,
qui est un digital asset management 3D,
parce que j'ai beaucoup de, je fais pas mal de jeux de rôle,
à l'ancienne.
Et le papa Noël m'a apporté une imprimante 3D,
et je suis super content,
sauf que je me retrouve à avoir un milliard plus douze de fichiers,
tous rangés dans des sous-dossiers,
rangés entre guillemets.
Tu vas me donner solution parce que là,
voilà.
Et c'est incroyable, c'est incroyable.
Vas-y, vas-y.
Et donc du coup, le truc est génial,
parce qu'un digital asset management,
c'est tout simplement une bibliothèque d'assets que tu veux,
mais là, c'est spécialisé 3D.
Object, STL,
Kitoo Box, enfin, il les prend tous.
L'avantage, c'est que tu as la possibilité de lui créer des règles,
parce que si tes dossiers sont organisés à peu près de la même façon,
il arrive à tautotaguer tes fichiers en fonction du nom du dossier,
de façon récursive.
Moi, ça tourne à la maison sur mon serveur,
parce que j'ai un serveur cube à la maison avec 70 services.
Donc ça fait partie d'un de mes services là,
et ça me permet comme ça d'avoir toute ma bibliothèque.
Quand j'ai besoin d'un personnage, d'un NPC, d'un monstre,
tu tapes Dragons, Ice Fire,
il va automatiquement te chercher dans toute ta collection.
Tu as le visualisateur qui te permet de passer
d'un mode à l'autre.
En plus, il y a ce côté un peu 80s que j'aime bien.
Vous savez, se dégrader si en mauve à l'ancienne.
Je me sens vieux d'un coup, mais c'est pas grand.
Il y a très cyberpunk.
Oui, voilà.
Et moi, je l'aime beaucoup pour vous donner un ordre d'idée.
La base, je l'ai fait évoluer sur du post-gré,
parce que ça avait besoin de cracher un peu plus.
J'ai un terrain 2 de fichiers 3D,
et la base, franchement, gère bien.
Je ne dis pas qu'il y a des moments,
il n'y a pas un peu de maintenance à faire.
Mais dans l'ensemble,
une fois que c'est rentré dans votre pipeline d'acquisition,
parce qu'en plus, tu as la possibilité de uploader directement
tes files 3D pour qu'il aille automatiquement les ranger,
et tu organizes après par collection.
Je suis abonné à des services Kickstarter
ou Patreon, tu sais, où tu donnes 5$ par mois,
et tu as accès à la collection.
Et puis, j'ai la collectionnité gut.
C'est-à-dire que même si le fichier,
je ne vais pas forcément en avoir besoin maintenant tout de suite,
c'est bien que je le stocke.
C'est franchement un très bon outil, je le recommande.
Moi, il tourne sous un pod cube
par rapport à l'image d'au coeur qui est proposée,
et 30 minutes étaient en production.
C'est vraiment easy.
Bah écoute,
moi, voilà, tu as au moins des autres rollistes ici,
Antoine et moi, et là, je suis prenait,
et voilà, il y a les petits flots.
Mais sérieusement, merci pour ce lien-là.
Et c'était nickel.
Je pense que là,
il va s'amoumouman pour dire
à l'épisode suivant, merci Erwan.
Merci.
Et merci Antoine qui a un souci de connexion,
mais juste à la fin,
j'adore que les plans se déroulent sans sacreau.
Nickel, on va rattraper.
Merci à tout le monde,
que je pense que vous avez apprécié cet épisode.
Et on se voit très bientôt pour les années.
Allez, à bientôt.
Merci pour l'améitation.
Bye.