C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
La virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant toute la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration.
On se retrouve face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contrêts.
DevOps.
L'objectif individuel, ça s'atteint.
Alors qu'une ambition, ça se partage.
Bonjour à tous et à toutes.
Bienvenue dans cette deuxième journée de table ronde au SLR Summer Camp.
On vient de passer toute la matinée avec des super conférences.
Et là, on est tous ensemble, donc aussi bien speaker que spectateur, pour parler ensemble.
Et alors là, pour entamer la discussion, on a Rhyne qui nous a proposé un sujet qui va nous présenter.
Puis après, on pourra commencer la discussion.
Puis après, on dérivera, soit en revenant sur les conférences, en posant des questions, etc.
Donc, on va y partir.
Merci, Yvan. Du coup, le souci de proposer, c'est les monoripaux versus multi-nepos sur Terraform.
J'ai un petit peu ma petite idée, ma pratique que je fais.
Je suis plutôt partidane d'avoir un monoripaux et puis avoir plusieurs hippos pour les modules Terraform.
Et je voulais savoir ce que vous mettez en pratique de vos côtés
et le retour d'espérance que vous pouvez faire.
Du coup, peut-être que tu peux commencer un peu dans quel contexte tu vas avoir besoin de cinder comme ça
pour voir qu'est-ce que tu mets dans ces hippos.
Est-ce que c'est des composants ?
Pour les différents hippos, moi, l'idée, c'est que je crée un module par application.
Si j'ai besoin de redéployer une application, je vais lui créer un module dédié.
Et si j'ai besoin, par exemple, de déployer une ressource toute simple, admettant un record DNS,
là, je vais le mettre dans un hippo centralisé.
Donc, ça veut dire que chaque module, c'est le concept du module réutilisé,
puis tu vas avoir réutilisé d'un projet.
Ce n'est pas dédié à un client dédié à un machin, c'est vraiment propre à une instance, par exemple.
C'est ça, oui, exactement.
Et ça, en materne chez vous, vous avez ce déballat de savoir mono vers ce...
On n'est pas tous forcément d'accord là-dessus.
Il y a des personnes qui sont partisanes d'un hippo dédié.
Chaque fois qu'on crée une application, on crée un nouveau hippo.
Et deux personnes, c'est un hippo centralisé où on déploie tout le monde.
Si je me suis donné une expérience, on a eu un peu ce problème-là au Hdh, donc, au Els Data Hub,
où en fait, déploiement est extrêmement compliqué, on va être beaucoup de composants.
Et surtout, on s'est mis à devoir déployer des choses sans savoir à l'avance qu'on allait y faire.
On avait quelque chose de très mouvant, c'est-à-dire qu'en même temps qu'on avançait,
on apprenait et on revenait sur ce qu'il y avait.
Et la chose qui avait été faite au début, c'est, oui, tout en module, de manière réutilisable, le plus possible.
Et en fait, on s'était aperçu que c'était...
Enfin, vraiment, on avait une...
Une vélocité qui était vraiment nul.
Et la première chose qu'on a fait, c'est qu'on a pris toutes les ressources
et on les a mis à plat, mais genre le plus plat possible l'un d'entre nous.
C'est-à-dire en utilisant aucune abstraction, aucune abstraction.
Et on est partis là-dessus en se disant,
grâce à ça, on peut tout modifier rapidement.
En fait, ce qu'on faisait, c'est qu'on...
En fait, ça n'a jamais été un problème...
Enfin, par l'expérience, on ne savait pas à l'avance,
mais par l'expérience, ça n'a pas été un problème de tout...
Quand on faisait des énormes réféctots,
parce qu'on les faisait en pire programmings avec du VS Code Live Share dessus,
on faisait des Controls Shift F de malades,
où on modifiait la moitié du code en une ressource.
Donc en fait, le fait de décentraliser ça n'a jamais été un problème pour évoluer.
Et le fait qu'en plus, on avait gagné une meilleure lisibilité,
dans le sens qu'on n'avait pas de module magique qui faisait des choses qu'on ne savait pas.
Et un problème également, c'est qu'on avait moins d'interdépendance entre les équipes,
qui faisait qu'on n'avait pas besoin de modifier un module
pour pouvoir ajouter une fonctionnalité ou quelque chose comme ça.
Et donc en fait, on avait décidé d'être le plus flat possible.
Et pour nous, ça a bien marché.
Alors après, et des fois, on commençait à remerger un peu des choses,
mais vraiment de manière très basique,
pour pas avoir ces problèmes de couplage très rapides,
qui font qu'il y ait besoin de synchronisation ou quelque chose comme ça.
Et même de fait que l'innovation devenait plus difficile,
parce que je savais qu'on avait une nouvelle idée.
Si on le rajoutait dans un module utilisé partout,
instantanément, notre erreur avait un impact extrêmement fort sur tout le reste.
Dans le taux que je viens de présenter tout à l'heure sur l'erreur,
on essayait de limiter la gravité d'une erreur sur un changement
et de faire en sorte d'apprendre en limiter le couplage
et en faisant en sorte d'avoir quelque chose de flat.
Et puis en plus, on essayait de se dire que Terraform,
ça doit être du descriptif et donc pas du tout de l'impératif.
On essayait de n'utiliser aucune notion de boucle ou de choses comme ça
pour faire en sorte de...
En fait, en gros, on avait juste un langage déclaratif, un DSL,
pour déclarer notre affra, mais pas pour faire des opérations compliquées.
Si jamais on devait faire des opérations compliquées,
on faisait en amont, on devait faire des restructurations,
des choses comme ça, mais on essayait d'avoir ce rôle.
Et dans ce cas, comment tu gères cette petite frustration
de réécrire à chaque fois du code, en fait ?
Ben moi, je l'ai pas.
J'adore faire du gammel copié-coller.
Enfin, genre le copié-coller, c'est gratuit.
Enfin, je préfère dupliquer plutôt qu'associer.
Et en effet, oui, c'est peut-être quelque chose qu'on a en France.
J'en ai parlé il y a très longtemps de ça,
sur le fait que peut-être en France, on a cette volonté de...
Enfin, on est des séries, des séries factoriseurs,
je pense qu'on a peut-être trop appris à factoriser des équations.
Et on oublie que quand on a des additions et qu'on factorise,
on a des multiplications et des multiplications,
c'est aussi une gravité qui part à l'échelle, qui part extrêmement vite.
Et moi, j'ai vu un prof de maths une fois dans ma vie,
qui nous a fait un piège comme ça,
en nous présentant une identité remarquable au début de l'exercice.
Et en fait, instantanément, tout le monde avait factorisé.
On disait, j'ai vu l'identité remarquable, ça y est, je peux factoriser,
j'ai vu moins de termes, c'est cool.
Et en fait, après dans le reste de l'exercice,
ça a devenu ultra pénible parce que manipuler des multiplications,
ça a devenu pénible.
Et en fait, il nous avait tous traité de...
C'est là où on avait développé, enfin,
il nous avait été de chien de Pavlov de la factorisation,
où on voit une vidéo remarquable, on dit,
ça y est, on a besoin de ça.
Alors qu'en fait, avoir des termes simples, décorrelés,
c'est des fois mieux et plus simple.
Et en effet, c'est peut-être une frustration qu'il faut qu'on...
Moi, je me souviens de ce prof de maths.
Merci, Monsieur Bouch, en première.
Je ressors assez souvent ça.
Je suis d'accord avec ce que tu dis,
que... Enfin, attention à la factorisation privaturelle.
Mais cela dit, parfois, d'un point de vue...
Enfin, pour moi, c'est important que notre code soit aligné
avec le modèle mental qu'on a dans notre infra.
Et parfois, en fait, je pense pas que j'ai un notepool
puis un autre puis un autre.
Je pense que j'ai trois notepools.
Et du coup, j'aime bien pouvoir écrire dans mon code,
j'ai trois notepools.
Et du coup, dans ce genre de situation,
je trouve que c'est quand même pratique de faire une boucle équivalente.
Un petit forish, il y aura rien de grand chose.
Ou alors, d'utiliser un module qui crée un notepool
et juste, je l'appelle, certes, trois fois, tu vois.
Mais du coup, factoriser un peu, ça aide vachement.
Mais à un gros intérêt de module,
nous, on voit surtout sur les...
des grosses organisations,
c'est le fait que des équipes peuvent fournir un catalogue de modules
à utiliser par d'autres équipes,
en implémentant des standards de sécurité,
de paramétrage, etc.
En fait, ça permet aux autres équipes,
de se dire, ok, j'ai besoin d'un bouquet,
mais j'ai besoin d'aller lire la doc de la boîte
sur toutes les bonnes pratiques de paramétrage des bouquettes.
Et j'ai un module où je lui passe juste un aim et j'ai fini.
Et c'est le genre de truc,
enfin, ce genre de pratique, en fait,
c'est le genre de factorisation qui arrive juste avant de cacher de la complexité,
que parfois, on a envie de cacher,
ou tout simplement de la complexité qu'on n'a pas dans notre tête
et du coup, c'est dommage de l'avoir dans notre code.
Et ça, t'as déjà vu quelque chose qui marche comme ça ?
Parce que moi, chaque fois qu'on a vu ça, au bout de deux ans,
ça devient un enfer pas possible, parce que personne ne maintient ce genre de choses-là,
ou alors il y a des changements faits par l'équipe-coeur,
justement, dessus, qui cassent tout le reste des applicatifs,
parce qu'ils ont décidé que,
non, la sécurité, maintenant, elle doit activer tels paramètres,
donc en fait, c'était pas dans le contrat initial,
ça peut être tout le reste, etc.
Moi, justement, je suis contre ça.
Je veux bien avoir des modules comme ça,
mais il doit être copié et pas maintenu.
Et tu vois, je suis,
100% contre ça,
à l'émice que je veux, par contre, c'est une équipe de sécurité
qui m'odite mes bouquettes. Et nous, c'était comme ça,
en fait, qu'on peut être plutôt pas que j'essayais de pousser chez ta laisse et au HDH.
C'est d'avoir quelque chose où au cas, je peux te dire, voilà, le modèle de ce qu'il faut.
Par contre, tu utilises, tu utilises pas,
c'est pas mon problème, et d'ailleurs, tu vas pouvoir...
Moi, la standardisation,
j'ai beaucoup de mal avec ça dans la formatique,
quand on sait qu'on est dans un milieu qui bouge à une vitesse pas possible,
c'est qu'aujourd'hui, je utilise ta réforme,
demain, une équipe va vouloir mettre du poulemy,
demain, une autre équipe va vouloir mettre du crossplane,
mais en fait, au final, elles manipuleront la même ressource.
Donc, ce que je veux, c'est qu'une équipe de sécurité, par contre,
elle l'odite les bouquettes, et qu'elle l'odite
qu'il y a bien les options de sécurité qui vont bien dedans.
Et que si c'est pas le cas, elle m'envoie des...
Enfin, si ça n'en va pas, elle m'envoie des alertes, et qu'on discute ensemble,
tu vois, genre, se baser sur le code,
comme étant une source de vérité absolue, et terraforme,
comme une source de vérité absolue, dans un contexte où,
justement, aujourd'hui, les noms d'outils explosent,
mais pareil, personnellement, en fait, on va revenir
à un cas où, non, dans la boîte, c'est que du Java,
et c'est que Java, à telle version,
et c'est que du Tomcat, parce qu'on ne sait que faire
du Tomcat avec telles options de sécurité, etc.
J'ai peur que le DevOps retombe dans l'imitravert qu'on avait avant,
qui était en fait, on a eu une explosion
de nouveaux outils qui nous ont permis de faire plein de choses,
et qu'en fait, aujourd'hui, on essaye de re-restraindre un temps.
Voilà, c'est moi, c'est...
Il y a un équilibre à trouver, et je pense, du coup,
c'est pas... Tout blanc ou tout noir,
ça dépend de la situation, il y a des cas où ça se...
On explique, on les module. Moi, j'aime bien l'utiliser,
parce que je suis dans des situations où on a plusieurs clients,
on a plusieurs fois, on refait la même chose.
Donc, c'est plus simple de faire un module et de se dire,
« Bah tiens, on a changé...
Ben, non, je ne sais pas, OVH a changé
une option, et maintenant, il faut activer
quelque chose pour avoir de la sécurité en plus.
On l'active par défaut à un endroit, et après,
on peut le mettre à jour directement chez les autres.
Donc, il y a quand même des avantages à faire ça.
Après, pour l'histoire des breaking changes,
ce qui est bien, c'est qu'on peut quand même taguer
des modules sur Git, du coup, pour éviter quand même de tout péter.
Mais, sur le côté de sécurité, je suis d'accord,
il faut auditer au niveau de la pays, et c'est des autres outils.
Il y a d'ailleurs des outils qui font de l'audit,
d'en continu, avec des règles, je ne sais plus comment
ça s'appelle, mais il y a un outil qui fait ça,
notamment sur AWS, où ça fait de l'audit en continu,
en parçant les ressources.
Mais, c'est encore une autre question.
Pour le découpage, en tout cas, il faut quand même
un minimum, on va dire, de propreté,
il ne faut pas se le fermer,
même s'il faut éviter de surdécouper.
Comme je dis, c'est un équilibre à trouver pour la maintenance,
pour ce qui est après, qui sont des outils.
C'est pareil, il ne faut pas se fermer à des outils,
mais il faut quand même un moment être raisonnable,
avoir une liste d'outils qui est un peu près cohérente.
Il ne faut pas partir dans l'idée de m'en changer d'outils
tous les jours, ou tous les équipes en des outils différents,
à surtout avoir à réinventer la roue.
Si demain, ils ont besoin d'aide sur quelque chose,
personne ne comprend rien.
Moi, typiquement, plus le mi, je n'aime pas trop,
parce que c'est trop ouvert pour moi au niveau des langages.
Ça fait qu'ils imaginent dans une boîte,
je ne suis pas avec quelqu'un qui préfère go,
l'autre qui préfère piton, l'autre qui préfère encore un autre langage,
on entre trouve avec trois personnes qui ont eu des hangers
et des langages potentiellement différents pour des autres trucs.
Et si jamais il y a besoin d'intervenir sur le code de quelqu'un d'autre,
c'est tout de suite un peu plus compliqué,
ça met de la frustration.
Pour moi, il y a une limite qu'il faut se mettre quand même.
Je peux expliquer comment je suis dans ma boîte.
On est des très gros utilisateurs de terrainforme,
une affra assez conséquente.
On utilise les modules pas mal,
et on aime bien ça.
Et c'est des modules pas trop compliqués,
c'est-à-dire qu'ils sont souvent assez simples,
par exemple un contrôle plane cube,
un note pool cube, une base RDS, etc.
Donc c'est assez carré.
Et c'est utilisé ensuite par d'autres projets.
Et comme ça a été dit,
ce qui est intéressant, c'est qu'ensuite ces modules sont utilisés
par des gens qui n'ont pas forcément l'expertise
sur terrainform, etc.
Donc notamment les devs, ils veulent créer une base de données,
ils ont le module RDS, ils passent le nom, etc.
Il y a tous les défauts qui sont là,
l'utilisateur est nommé d'une certaine façon, etc.
Et je parlais hier dans mon taux de l'expertise à son service,
c'est ça, finalement, des gens fournissent des modules de qualité
qui sont prêts à être utilisables par des gens
qui n'ont pas forcément, et comme ça, on interre très vite.
Et donc voilà, on utilise les modules,
et juste, tu parles aussi de monorépaux, je pense,
bah nous ce qu'on fait, c'est qu'on a les modules,
on a ensuite pas mal de...
on a beaucoup, beaucoup de dépôts terrainform,
là, beaucoup avec des plans, qu'on appelle plateformes,
donc là, ça va être plus le corps de nos environnements,
donc le réseau, des choses comme ça.
Et ensuite, on a des stacks, et là, ça va être, par exemple,
le Log, le KS, je sais pas, RDS, je sais pas,
on destaque vraiment par catégorie de produits,
et on utilise beaucoup les remotes states
pour, on va dire, faire le lien entre tout ça.
Donc, par exemple, le plateformes réseau,
peut-être utiliser un module, très bien,
elle va exposer un output, par exemple, un VPC,
qui va être utilisé par la stack KS,
qui va utiliser un module, par exemple, NodePool,
et là, on va référencer le VPC,
via un Rémotes 7, le VPC de la plateforme
dans laquelle on déploie.
C'est comme ça qu'on fait, donc on fait pas du mono-répôt,
on fait vraiment du beaucoup multi-répôt,
on a beaucoup pas de module là, mais sur la partie répôt,
on a beaucoup, beaucoup, beaucoup de répôt,
et ça a beaucoup d'avantage de temps en terrainform,
c'est les plans qui sont très, très rapides,
parce que le mono-répôt en terrainform,
moi je l'ai connu dans le passé,
et un plan qui dure une demi-heure,
mais en fait, c'est un peu problématique aussi.
Bah, pour revenir là-dessus,
ce qu'on fait chez Padoch, du coup,
oui, nous modules, ils sont sur des répôts,
et je pense que, enfin, on a commencé à l'évoquer,
mais, je m'entends, genre, que tes modules
dans des répôts séparés, c'est pour le versioning,
et du coup, quand tu vas passer des modules,
d'un an, vingt-un autre,
bah, tu as une certaine forme de cohérence,
c'est quand même assez pratique.
Après, pour le côté mono-répôt versus multi-répôt,
je pense qu'on est pas à la taille de contos,
donc on n'est peut-être pas arrivé à ce truc-là,
mais nous, on commence sur les grosses orques
qu'on commence à utiliser, c'est plutôt du coup Terragrond,
qui te permet, justement, au niveau de tes appels,
de séparer les stages pour éviter, justement,
comme tu dis, les plans de 30 minutes et quelques.
Et après, en fait, c'est effectivement
comment tu vas séparer, en fait,
ce que vous faites entre vos répôts,
c'est, en fait, qu'est-ce que tu décides
de mettre dans un répôt ou dans un autre ?
Bah, c'est un peu la même chose après, en Terragrond,
c'est du coup, qu'est-ce que tu décides
de mettre dans une lailleur ou dans une autre ?
Et ce qu'on fait, en tout cas, c'est que nous,
on essaye beaucoup de s'inspirer de tout ce qui est
de men-driven-development.
Ça a été testé sur un premier projet, là,
et c'est ce qu'on essaie de pousser à prendre un terme
du paddock, c'est vraiment de séparer
les blocs qu'on besoin d'être cohérents entre eux
et les blocs qu'on pas vraiment besoin
d'avoir de notions de...
faut que ça, ça arrive avant ça,
ou ça, ça arrive après ça, donc on a souvent,
effectivement, ce bloc un peu corps
où on est obligé de poser le réseau,
plein de trucs, machin et tout, et après,
par exemple, sur une équipe qui va avoir,
dans une boîte qui va avoir cette équipe,
tu vas avoir la lailleur d'ATA,
ou effectivement les data-enges,
si ils ont besoin d'un memory store sur GCP,
ils appellent le module memorystore
avec leur nouveau nom, et en fait,
chacun fait son applai de son domaine
quand il en a besoin.
Pour vous remercier sur ce que tu disais,
sur les breaking changes, pour moi,
à ce moment, une équipe a ce rôle
des naibleurs et fournis des modules terraformes.
Bon, déjà, je suis d'accord avec toi,
c'est pas devof si cette équipe, tout d'un coup,
elle pose son point sur la table,
elle a dit, c'est terraform ou rien,
et c'est nos modules ou rien, tout.
Je connais aucune organisation...
Stage 0 du devos, quoi.
Mais du coup, tu peux quand même...
On peut pas le prouvoir comme une solution d'avenir, quoi.
Non, je suis d'accord, mais je suis d'accord que c'est pas bon,
mais cela dit, tu peux quand même être en stage 1,
ou 2, ou 3, sans...
tout en maintenant, des bibliothèques partagées.
Et en fait, c'est ça,
un module terraformes pour une équipe.
Moi, je suis pas en train de prétendre que le module RDS
que j'ai écrit, il est parfait,
il répond à tous les besoins. Non, il répondait à mon
besoin à la base. Je me suis fait challenging
par Arsikovs, qui, du coup, m'a dit,
vaut mieux activer telle paramètre, telle paramètre.
Moi, j'ai été réçue.
Et peut-être que j'ai rajouté des paramètres,
etc. Je l'ai fait évoluer aux firmes de mes besoins.
Et s'il y a une autre équipe
qui peut profiter du travail que j'ai fait
pour gagner du temps,
bancaux, si eux, ils ont un besoin tellement
spécifique qu'en fait, ils ont besoin d'écrire
un autre module, pas de problème.
Moi, je n'ai pas d'objectif en ça. Et d'ailleurs,
on a, je ne sais pas, du coup, un gros catalogue
de modules terraformes. Et ce qu'on constate, c'est qu'il y a
un peu une sorte de sélection naturelle qui est en train de se faire,
où, en fait, il y a quelqu'un qui a écrit un module
pour gérer la YAM sur GCP.
Et en fait, il y a des gens qui sont sans service,
on a trouvé ça super painful. On a du coup
pas utilisé ce module-là sur leur projet,
on a juste commencé à gérer la YAM
d'une leur propre code terraformes.
Et derrière, en fait, ils sont proposés un nouveau modèle.
Et là, en fait, on est en train de voir
quels sont les avantages que j'ai mis en train de le chacquer
et on est en train de sortir un troisième.
Je pense que...
Et ça a rejoint un peu la diffusion qu'on avait hier et tout,
mais l'avantage d'avoir un catalogue
de modules et tout, c'est de
aussi promouvoir l'inner source, en fait,
dont on ne parle pas. Mais en fait,
c'est ça, avoir eu des équipes qui proposent
en fait... Voilà,
tu proposes ton module RDS,
puis en fait, dans ta boîte, c'est quelqu'un
qui a besoin de RDS et qui a besoin
de changer des paramètres, etc.,
à lui, en fait, d'ouvrir
une PR. Et effectivement, ça sera peut-être
Arthur, le maintainer, à
dire, ok, ça, effectivement, c'est une feature
qui est logique dans mon module, ou ça, non, en fait,
tu veux faire un usage complètement différent de RDS.
Alors, je ne vois pas trop dans quelle mesure, mais pourquoi pas.
Donc, faire un autre module
dédié pour ce truc-là, tu vois. Et en fait,
il...
Ouais, il faut laisser la liberté, mais il ne faut pas se dire,
en fait, toujours reprendre from scratch les trucs,
parce que, en fait, le module
RDS qui a deux ans de ta boîte,
deux ans d'expérience, qui est en version
2.18,
où il y a 350 comites dessus,
en fait, tu as quand même eu de l'expérience dedans
sur laquelle tu as peut-être envie de capitaliser le jour où
tu as envie de reprendre une RDS.
C'est marrant, moi, je me dirais que c'est du legacy et que j'ai envie, justement,
un module comme ça, dans un cloc
qui bouge beaucoup, je me dirais...
Mais vas-y, tu voulais...
Oui, pour revenir à la question initiale,
sur Multi-Repo vs. Mono-Repo, si vous commencez
à voir les modules de chacun dans un repo,
comment vous faites, quand vous parlez
de catalogue de modules,
comment vous faites, pour cartographier un petit peu
tous les modules que vous avez, s'ils ne sont pas au même endroit,
est-ce que vous avez un outil au-dessus, comment vous faites aussi
pour l'aspect documentation, avec Airform,
tu peux générer une documentation automatique,
si chacun est dans son module, en fait,
tu n'arrives pas à avoir ta page avec tout tes modules,
donc comment tu la tasse ce point ?
Justement, c'est un problème qu'on a commencé
à adresser il y a deux mois, trois mois,
un truc comme ça, parce que...
Tous nos modules d'Airform, ils sont sur notre ordite,
donc pour le coup,
il y a un appareil qui sont publics, c'est ceux qui sont prêts à être utilisés,
il y a quelques-uns qui sont en cours de développement, qui restent privés,
ils sont publics purement pour qu'on s'en s'en sers
sur les projets en fait.
C'est pas du tout...
Enfin, on n'est pas du tout là, en tant que dire,
sérieux ou non, mon conseil, c'est,
ne les utilisez pas, on fait des barricades change
régulièrement, du coup,
et surtout, parfois, on va créer une V2,
on n'a plus du tout maintenant la V1, voilà.
Mais, du coup,
tout ce qu'on a mis par-dessus, c'est Backstage,
du coup, qui a un outil
de... une sorte de portail pour les devs
qui a été créé chez Spotify,
et en fait,
Backstage, lui, il se connecte dans notre laptop,
il trouve tous les repos qui ont un tag
d'Airform,
et en fait, il propose un catalogue,
ou vraiment, c'est un portail,
en fait, tu as tous tes trucs, tu peux chercher,
tu as une barre de recherche, tu peux lire la doc,
et en fait, voilà.
Et on utilise aussi d'Airform Docs, etc,
pour définir, enfin, générer les specs,
mais du coup, en plus de ça, on a joué des exemples,
etc. et on est en train de travailler
sur la joueté des tests, parce que, en effet,
parfois,
enfin, puisque de l'une part, c'est bien
de formaliser, en fait, la promesse du modu,
genre exactement qu'est-ce qu'il promet,
et quels sont tous les paramètres qu'on s'autorise
à rechanger, et après tout le monde, ça casse pas les tests.
Et typiquement, je ne sais pas, on parle
d'un bucket,
bah peut-être, en fait, ok, le versioning
il est activé par défaut,
mais est-ce que ça fait vraiment partie du contrat du modu ?
Est-ce que vraiment, on parle d'un modu
ou fait un bucket de versioner ?
Et en fait, il faut que ce soit formalisé
dans un test, ça, c'est avec le prochain chantier,
une fois qu'on a fini le chantier en cours.
Et, Rémy, peut-être la question que tu posais
à la base, est-ce que tu peux,
t'as dit qu'il y avait des conflits, enfin,
que vous n'étiez pas sûrs en interne, qu'il y avait des pros et des contres
de chaque côté, si jamais tu devais un peu résumer,
genre les arguments de chacun des côtés,
ou les volontés de chacun, même quitte à faire
un peu d'homme de paille, c'est à grave, mais
pourquoi cette question, et pourquoi
parce que là, on a l'air
à peu près d'avoir des avis
convergents, en tout cas, dans ceux qui en font beaucoup.
Enfin, vous, c'est quoi les...
Enfin, pourquoi la question, et qu'est-ce qu'il y a,
qu'est-ce qui a motivé ça dans les argumentaires des deux,
si on tuve résumé ?
Il y a le fait de maintenir, je sens,
quand tu disais, les différents répos
et aussi le fait
enfin, et aussi le fait de se dire
comme tu disais, l'impact
que ça peut avoir d'appeler
plusieurs modules et de réutiliser
ces différents modules.
Et il y a aussi,
comme tu disais, pareil,
le fait d'introduire un breaking challenge.
Mais si moi, pour moi, je ne le vois pas comme ça, parce que
tu peux réaliser tes modules et tu tag
tes modules sur une certaine version.
Et l'autre
sujet qui nous a
poussé à la réflexion,
c'est notre modèle de déploiement
et aussi comment on pouvait s'aligner
avec du Github.
C'est une séance.
Après, tu as parlé breaking change.
Moi, je suis arrivé dans des boîtes, déjà,
où ce qui s'est passé, c'est que, oui,
au début, vous êtes du versioning.
Et en fait,
par exemple, il y a une feature que tu veux récupérer.
Mais sauf que, entre-temps, tu as eu
14 breaking changes, ou oui, il y a certains projets
qui les ont pris en compte, certains
modèles qui l'ont fait. Sauf que toi, tu veux
juste une partie du dernier changement.
Et en fait, en vrai, dans les boîtes,
c'est OK, on dit qu'il y a un breaking challenge, OK,
on me perd, il y a un breaking challenge, on le dit.
Ce qu'on maintient jamais ce qu'il y avait avant.
Et donc, en gros, on se retrouve à avoir quelque chose,
et en fait, c'est tout le temps une course à la chaleur.
Je connais rarement dans une boîte en interne,
où il y a un maintien de plusieurs branches mineures
et de plusieurs branches master en même temps, etc.
Donc, en vrai, c'est une course en avant.
Oui, on dit qu'il y a un breaking change,
oui, on peut faire attention à ça. Donc, en fait,
le same verre, c'est plus un module d'information,
plus qu'un module vraiment, de une façon
d'informer plus qu'une façon de vraiment réaliser.
Enfin, ça serait possible, mais je l'ai vu rarement.
Et en plus, après, il y a le coup de communication
entre les équipes, en fait. Ça veut dire que là,
ça marche s'il y a une équipe dédiée,
une équipe centralisée qui fait ces choix-là.
Mais dès qu'on commence à avoir des SRE dans plusieurs équipes,
dès qu'on commence à avoir une équipe qui est à l'étranger,
dès qu'on commence à avoir des choses comme ça,
dès qu'on commence à avoir même des entreprises
qu'on achète et qui ont leur propre pratique,
qui ont leur propre module Terraform, etc.
Et moi, j'ai déjà vu des boîtes qui en fait,
se sont pris la tête parce que, quand on fait ces modules Terraforms,
moi, c'est ce que j'ai vu même dans les playbookers de Sybol,
dans les cookbook chefs.
C'est quelque chose qui est revenu, répété, etc.
En fait, c'est une erreur des ops
qui est répétée dans l'histoire des ops.
C'est qu'en fait, chaque boîte devient autonome par rapport aux autres.
Vos modules, ils gèrent la yam à Google.
En fait, tout le monde fait de la yam Google,
de ceux qui font de la yam Google,
faire un note pool, faire un contre-bank,
tout ceux qui font du cul-à-dix, ils font ça.
Et en fait, tout le monde s'invente, son petit monde,
s'invente ces petits standards, s'invente ces choses
qui font que quand quelqu'un de nouveau arrive,
il ne peut plus comprendre, parce qu'en fait,
il y a un module qui est différent avec une autre philosophie,
alors que lui, il avait avant un module qui marchait très bien,
mais peut-être une philosophie différente, etc.
En fait, ça fait en sorte que chaque ops,
je ne sais pas pourquoi, a toujours envie de s'autonomiser
par rapport au reste du monde,
et en fait, s'autonomiser par rapport à un provider
qui est peut-être un peu trop générique, mais qui marche très bien,
que tout le monde connaît, mais non, non, je vais créer le module
qui est par contre là, et dans ma boîte, et uniquement dans ma boîte,
qui fait que quand ça tient un nouveau qui arrive,
il va ramer pour comprendre le module,
il ne pourra pas réutiliser son code d'avant,
il ne pourra pas copier-coller tout ce qu'il avait.
Ça, c'est juste une mauvaise libre.
Ouais, c'est juste en fait, si un module Terraform,
c'est exactement comme une libre de code,
si ton interface n'est pas claire et que tu n'es pas capable
de comprendre ce que fait le truc avec le nom
et les arguments que ça te propose,
c'est que ton module est congri.
Mais t'as déjà une libre, ça s'appelle le provider qui, lui, est standard,
utilisé par toutes les boîtes, etc.
Mais ça, c'est comme dire que tu ne vas jamais utiliser une libre externe,
et que tu vas cuiser la libre externe.
Mais si je tise le provider l'un dedans, mais pas...
Non mais, c'est comme dire, je fais du go,
et je vais y faire de la libre externe, je ne vais jamais utiliser une libre externe.
Mais sa libre externe, elle est réusable.
Elle est publiée, etc.
Mais par contre, je n'essaie pas de lire interne,
uniquement pour mon propos, qui va aller moquer...
Enfin, qui va aller abstraire d'autres livres qui existent déjà.
En fait, c'est ça que...
Est-ce qu'au final, la solution, ce serait pas
d'essayer de réutiliser au maximum les modules proposés par les providers,
même, comme AWS qui en propose plusieurs...
Nous, on essaie de le faire.
Mais parfois, il y a des modules qui sont complexes.
Alors, en fait, pour moi, les modules terraformes de la communauté,
ils ont exactement le même problème que les M-sharp de la communauté.
C'est qu'en fait, comme ils veulent répondre à tous les use-cases du monde,
bah c'est juste, en fait, des gros passe-places sur les ressources, finalement.
Mais en général, ce qui gêne aussi, c'est que c'est tellement complexe pour répondre à tout le monde,
qu'au final, quand tu as besoin de faire un changement ou un debug,
ça tu perds un moment de temps en complexité,
que traditionnellement, historiquement,
je prends un exemple avec Ansible,
ou ça marche avec tous les systèmes un peu de gestion d'infrastructure.
C'est qu'il y a eu la grande histoire de tout le monde d'acquander ça en public plein de trucs.
Il faut que tu fasses gérer les OS de tout le monde,
il faut que tu fasses gérer les passes de tout le monde.
Et au final, ça a donné des modules publics tellement complexes
que quand tu devais debuguer en interne,
quand tu devais faire une évolution pour la communauté,
tu fais putain, nous, on n'est que sur du débian,
il faut que je preuve un red-hat, il faut que je preuve un machin et tout ça,
que la plupart du temps, en fait, les gens finissent par forquer,
ils disent que c'est plus simple comme ça,
je maintiens en interne juste mes conditions,
et ça fonctionne très bien.
Mais là, c'est un peu le cas.
Mais là, tu as le problème, toi, ce que je disais hier, c'est qu'en gros,
tu vois dans le fact-o que j'ai fait,
c'est qu'en fait là, tu as créé une convention.
Tu as créé une convention que ma boîte, elle tournait sur débian,
où elle tournait sur SENTOS.
Et on a eu ce problème-là, c'est que le jour où quelqu'un arrivait,
on disait, non, mais là, vraiment, on a un problème.
Et bien, en fait, le coût de changement a été devenu gigantesque,
justement, tous les modules, tous nos cookbook chefs
étaient tellement spécialisés pour un OS
qu'en fait, le coût de changement pour passer à un autre œc
qui a été devenu démentiel.
Et en fait, tu vois, c'est ça aussi le problème, c'est qu'en fait,
là, tu as fait un couplage sans le savoir,
qui a un couplage par définition que dans ma boîte,
à vitam-éternam, et ça encore, c'est une réflexion,
donc un système nominal, à vitam-éternam,
je serais toujours un seul OS.
Non, mais en fait, tu as toujours une dépendance,
tu as toujours une dépendance sur la technologie que tu fais.
Aujourd'hui, on utilise tout ce cube.
Le jour où on va plus devoir déployer sur cube,
mais sur la prochaine techno,
il va y avoir un petit coup de sortie en réalité.
Je me dis que...
Tu as pas dit que ça, parce qu'en fait, on est ultra déclaratif.
Moi, justement, je ne tise pas du Elm,
parce que justement, je ne peux pas.
Tout le temps, tu t'es magnifique,
tu n'as pas de l'air de récréer.
Oui, bien sûr, je veux pas en récréer, mais parce que justement,
ils sont ultra déclaratifs, c'est-à-dire que migrer de l'un à l'autre,
je n'ai pas de conditionnel.
C'est du pur déclaratif, c'est-à-dire prendre une image,
la mecoupe dans le nouveau.
On parle pas de conditionnel, ici, on parle de modulance.
Mais c'est parce que ton modèle, il est...
Non, mais là, si ton cube, il se bat sur le fait que tu utilises des conteneurs,
dans 10 ans, ça ne sera plus de conteneurs, il faudra tout refaire.
Mais ça, c'est le même coup que de passer sur les trucs installés en service unique
sur une VM des biens à passer dans le cube.
Mais non, c'est ce que j'ai dit, justement,
gérer le legacy pour pouvoir imaginer le futur,
c'est qu'il faut être purement déclaratif.
Basé sur des conventions, ça fait en sorte que le legacy devient compliqué.
C'est exactement ça que j'ai essayé de montrer là-dedans,
c'est que vraiment, du moment que tu restes purement déclaratif,
tu sais que ton avenir est à peu près bien tracé.
Je ne sais pas, mais je suis d'accord qu'il faut rester sur le niveau.
Mais le module, il perd cette déclarativité là
parce que tu as créé quelque chose à toi, une convention interne ou non ?
Tu as juste créé une abstraction plus haut niveau.
Par exemple, pour l'exemple de GKE,
tu veux créer un cluster GKE,
aujourd'hui tu vas devoir créer,
utiliser une ressource Google Container Cluster,
qui va te placer ton contrôle plane, avec un node pool par défaut.
En pratique, on envie de virer ce node pool par défaut,
donc il y a un paramètre à l'intérieur jusqu'on passe à faute.
Et derrière, on va avoir une ressource Google Container Node Pool
par node pool qu'on veut.
Et il y a des projets où je ne sais pas,
tu en veux 24, 5, ça dépend de ce que tu fais.
Et en fait, tu te dis,
tu peux encapsuler tout ça ?
D'accord, ça j'en veux donc container cluster
et le node pool extra, tu as des paramètres que tu changes.
Jamais tu vois, genre le choix de Serenis, etc.
Tu te dis, oui, je peux aussi lire pour le combat.
Et en fait, c'est le genre de truc que tu l'encapsules dans un module,
où tu dis, donne-moi le nom de ton cluster.
Et juste, dis-moi, combien tu veux node pool,
la taille de machine pour chaque node pool,
et le nombre de nodes que tu veux.
Et en fait, tu te trouves avec,
tu es passé de 100 lignes de code terraform à 15,
et en fait, ça, l'intérêt,
c'est la charge mentale quand tu lis ton code.
Parce que quand tu revois ton archi,
tu ne penses pas à,
ah oui, j'ai un contrôle plane de node pool node pool,
non, tu dis, j'ai un cluster.
Mais c'est faux, non, justement,
moi je veux exactement avoir les paramètres,
parce que justement, tiens, tu donnes l'exemple l'un de l'autre.
Mais tu les accroles, c'est que...
Quand on n'a pas besoin, tu n'es pas obligé de les voir.
Mais en fait, c'est comme utiliser une fonction dans ton code.
Tu vas pas poper un serveur web en faisant juste,
enfin, tu vas utiliser des fonctions
que tu vas appeler à un moment donné dans un main.
C'est le même principe.
Là, on utilise, il faut juste voir ça comme une fonction
pour dire, bah oui, en fait, j'ai une fonction magique.
Je sais pas, c'est pas une fonction,
mais je pense pour ça que vous allez pas dire,
ce n'est pas de l'empraque code, ce n'est pas une fonction.
C'est une déclaration.
Par exemple, t'as Sylvain,
demain, GKE, ils vont avoir un nouveau système,
parce que forcément, il y en aura un autre.
Si tu changes ce paramètre là-dedans,
que ton plan change, que les gens n'ont pas fait attention,
que genre, on CNI change et qu'ils se mettent à recréer
le cluster en entier, c'est...
Si tu fais un ReckinChange dans Lib,
bah signe-le, quoi.
Non, mais signe-le, oui.
C'est...
Oui, c'est un autre module.
Oui, tu peux faire notre module.
Oui, tu fais notre module.
Oui, tu fais notre module.
Mais tu n'as rien gagné.
Je vais donner un exemple à ce que...
Si, je suis là, je suis là, je suis là.
La maîtrise, c'est...
Enfin, l'objectif, c'est de maîtriser la complexité
de notre code base.
Genre, nous, on s'est déjà retrouvé avec des codes base terraformes
où il y a littéralement 2 000 ressources,
genre, d'énormes affraies, d'accord ?
Bah, je peux te dire que je n'ai pas envie d'avoir
un main.tf, d'accord ?
De 40 000 lignes.
En fait, et du coup, tu commences à découper ton infrap
parce qu'en fait, tu ne peux pas tout avoir en tête
à un instant T.
Et tu commences à dire, OK, alors comment j'y réfléchis ?
Bon, bah déjà, il y a une partie base de données,
il y a une partie web,
il y a une partie data pipelines.
Pool, 3 modules d'enblu.
Et après, je suis pour chacun de nos modules
et je commence à redécouper, d'accord ?
Et me dire, OK, comment est-ce que j'y réfléchis ?
Faut pas aller trop loin parce que, genre, en effet,
je n'ai pas envie d'avoir un navigué dans 14 fichiers
quand j'ai besoin de comprendre un truc.
Mais l'objectif, c'est de maîtriser la complexité
de notre code.
Non mais là, surtout, là, surtout, c'est le partage,
en fait, c'est le partage de ce genre de ressources-là.
C'est en fait, enfin, vraiment, on est dans un autre cycle
que des librairies, la plupart du temps,
quand on parle de l'infra,
typiquement, quand je spawn un cluster.
J'ai pas envie de le modifier à posteriori.
C'est du Fire Unforget.
Ça dépend du projet.
La plupart du temps, sachant que les modifications
faites par un du code comme ça,
je ne maîtrise pas leurs impacts.
Ça veut dire, je ne sais pas s'ils vont recréer entièrement
leur ressources, je ne sais pas s'ils vont se passer comme ça.
Non mais il y a eu une provider, je ne sais pas lui ce qu'ils vont faire.
Il va dire, oui, je vais appeler tel API dans mon provider,
mais en vrai, ce que va faire après le provider,
est-ce qu'ils vont faire couper les API,
est-ce qu'ils vont faire couper ceci, etc.
J'en ai aucune idée.
Ça, c'est vous connaître ton cloud provider.
Oui, mais voilà.
Mais en fait, si jamais ce module-là,
j'ai besoin en fait la plupart de temps
quand je fais une affra d'avoir quelque chose,
c'est du Fire Unforget.
Je déclare ce que je veux.
Fini.
Genre, finito, je veux en fait avoir quelque chose
qui soit reproductible dans le temps.
Je réplie de telle façon,
je veux exactement avoir le même résultat.
Et rien ne m'empêche de faire de la fin structure immutable,
tu vois comme je dis, et du tout à fait,
rien ne m'empêche de dire, ok,
je vais besoin de modifier mon cluster-cube.
En fait, je ne peux pas nous aimer à côté.
Oui mais là, dès qu'on commence à avoir des modules,
en fait, on rajoute des modules partagés entre des équipes.
Moi, je suis…
Il n'est partagé pas entre les équipes.
Nous, on a choisi de faire ça, mais après, tu sais pas…
Nous, partage, on est 40 extra-hours.
Oui, et ils savent et en fait,
on a plein de débats encore en interne
sur telle module et s'il faut le faire comme ça et tout.
Mais en fait, en réalité,
moi, je pense qu'il y a un truc qu'on oublie,
c'est qu'en fait, du code,
tu passes plus de temps à le lire
qu'à l'écrire.
Donc en fait, moi, la question,
c'est quand je veux comprendre un truc,
quand je vais arriver sur une affra,
quand je veux changer un truc,
quand je veux comprendre un bug,
quand je veux comprendre le fonctionnement d'un truc,
je ne veux pas genre galérer à lire avec,
genre, effectivement, comme dit Arthur,
des 40 000 lignes de fichiers de ressources à plat.
Oui, je veux lire module cluster cube.
Ok, bon, bah je sais que le problème,
il n'y a pas du cluster cube.
Je passe à autre chose, module RDS.
Ah bah oui, mon problème, il est sur la DB.
Ok, le module, il est là.
Bah je vais voir dans le collège de test.
Mais tu as baissé ta détectabilité.
Enfin, tu vois, je vais encore pour reprendre mon taux classique.
Tu as baissé ta détectabilité.
C'est-à-dire que en fait,
le but d'avoir des choses à plat
sont plus vite parce que toute l'information
est lisible au premier coup d'heure.
Et en fait, on n'est pas dans du...
Quand tu as 40 000 lignes de fichiers de ressources à plat,
je suis pas sûr que tu aies pas de...
Non mais tu as un contrôlef.
Non mais tu n'as pas de sérieux.
Un cerveau, il est capable d'interpréter ce genre de choses-là.
Enfin, si votre cerveau est limité
en passant de 5 lignes à 15,
je pense que le problème,
il n'est pas dans le code.
Il n'y a pas de...
Ok, imaginons, tu as un problème de permission.
Tu as le laya, genre,
tu ne peux trop trouver dans des enfrins comme ça,
tu as 40 microservice,
ils ont tous un compte de service,
ils ont tous des role binding, etc.
Je peux pas le contrôler pour role binding, en fait.
Je te promets que nous, ce sont...
Je suis super content.
Et nous, pour le coup,
nous, pour le coup,
on avait un truc qui a pu être audité par Nancy
et donc justement, ils nous ont dit que c'était cool
parce que justement, tout était à plat
et que c'était beaucoup plus simple à lire.
Et qu'il n'y avait pas des choses
où en fait, dès qu'on commence
à avoir des appels de modules, etc.,
il peut y avoir des effets de bord non prévisibles,
en tout cas, au premier abord,
qui sont extrêmement mauvais.
Donc non, on avait des patterns,
on avait des choses comme ça,
mais franchement,
des refactos de code avec du SED,
avec des choses comme ça,
ça fait en plus que quand tu fais une PR,
instantanément, tu vois les changements.
C'est-à-dire, tu sais exactement
à quel endroit elle est.
Alors quand tu changes un module,
putain, le gars qui review la PR
d'un module réussira à comprendre
ce que ça change exactement
en tout le reste des gens qui l'appellent.
Enfin, génie.
Bravo le gars, quoi.
Bravo le gars.
C'est pareil que pour une rivière libre.
En fait, c'est pour moi, c'est pareil.
Mais exactement.
Mais c'est exactement ça.
Surtout qu'en fait, on a des cycles de vie
et des boulots.
Enfin, on a un travail qui est assez différent
là-dedans.
C'est qu'en fait, on déclare des choses
qui ne doivent pas forcément bouger.
Mon applicatif, je peux la tester facilement
avant de la déployer.
Mais il y a quand même une valeur.
Ton terraform, moi, je connais personne.
Je connais personne qui teste son module
en déployant entièrement son infracle.
On change un bout d'un module.
Mais justement, c'est ma proche en changer.
Mais juste un truc, c'est ma standardisation.
On peut faire pleinement tester.
Nous, on veut de la standardisation.
Une base RDS à conto, c'est
tel rôle, tel nom, telle configuration
de chiffrement et tout.
C'est pas la foire à la saucisse.
Un dev, non mais je veux dire un dev,
il utilise le module en fait.
Et ça, je sais peut-être une populaire
opinion.
Mais en fait, ça va être comme ça.
Il n'y a pas de...
Surtout dans le domaine bancaire,
ça peut être, moi, j'enlève le chiffrement
et puis je me crée un rôle custom,
route, machin.
Non, en fait, c'est pas comme ça.
Et en fait, c'est ça qui est bien
avec le module.
Et comme on disait,
il ne sera pas un micro-service.
Il y a la doc.
Il y a une doc qu'on produit.
Tu veux me baser le nez?
Tu mets module RDS,
nom de la base.
Bam!
T'as tout ce qu'il faut.
Personne ne sait jamais de quoi faire.
Il a fait un nom de pas.
Il sait que moi, je n'étais jamais dit
que ça devait être la force à la saucisse
puisque je t'ai dit que je vais bosser
dans un domaine.
Tu veux toi plat?
Bien sûr que je vois plat.
C'est pas d'équipe qui font
n'importe quoi.
Non, mais j'étais dans un domaine
de la sécurité des données santé
qui sont presque, même, encore plus critiques
que de la sécurité bancaire.
Donc, ce que tu es en train de dire,
c'est que tu vas laisser le dev prendre
ton corps de terraform à plat
et pop une RDS sans jour checker
ce qu'il fait.
Parce qu'on check, justement,
en fait, on avait eu...
Et tu check la post-sérieurie envers un autre.
On avait du test de sécurité.
Tu vas passer, tu vas faire du torse.
Mais non.
Mais non, justement, je te dis
que je te dis pour gagner.
Je ne vais pas bosser pour rien.
Alors pour le coup,
pour le coup, nous, on a testé les deux.
Tu vois, on est passé de l'un à l'autre.
On a vu la différence entre les deux.
Et la vélocité,
on l'a gagné quand on a réussi
à faire ça.
Donc, en fait,
on a testé les deux.
Donc après, je veux bien,
mais là, là-dessus,
il faut la tester,
il faut de la maitrisque, etc.
Et non, on n'était pas
dans le yolo, etc.
Et tu vois, ça,
c'est vraiment un procès d'intention.
C'est de penser que la standardisation
amène un contrôle.
C'est faux dans l'histoire de la
sympathique.
C'est purement faux.
Mais c'est pas ça qu'on dit.
On ne dit pas qu'il ne faut pas
auditer automatiquement et tout,
tout sous l'infra.
Au contraire, tu vois.
D'accord.
Et je suis sûr que chez Conto,
vous avez des audites automatiques
de l'infra.
Ah ouais.
D'accord.
Ce que tu proposes au DEV,
c'est un module qui est déjà conforme.
C'est ça?
Tu proposes des câbles de sang.
Et ça, c'est tout.

Je suis d'accord que le DEV, c'est tout.
Il ne faut pas séparer, genre le DEV,
ne touche pas la terraforme et tout.
Mais en fait, ce n'est pas le métier
du DEV, de savoir pondre du code terraforme.
Donc, en fait, ça fait partie aussi
de cette terreuse.
Mais c'est pas dans le DEV.
Le SRE, c'est lui qui sait.
C'est le SRE dans telle équipe
qui sait qu'il a tel besoin
et qui va donc utiliser
ou pas en copiant colore le code
dans un autre projet.
Et que l'aventure a exclu le SRE
de la boîte.
Sûr, des besoins comment?
Moi, je n'ai pas envie d'être pinc par un DEV
et de créer un RDS.
Tiens, ton module,
en fait, tu as juste à appliquer
ce truc-là et qu'on aura.
Il n'y a pas de passérou.
Tu parlais tout à l'heure
de la complexité.
En fait, si tu as ajouté
une fonctionnalité
et que tu n'apportes pas une chance,
quand tu as une fonctionnalité
que tu dois implémenter
aux légalement plusieurs modifs
demandés par la CQ,
tu dois implémenter partout.
C'est pénible de devoir
aller remettre ce code-là partout.
Mais ça, je suis d'accord.
Mais en fait, le truc du partout,
ça n'existe pas en théorie.
Parce qu'on a un SRE par feature.
Normalement, le gars de la CQ arrive
et dit au SRE de chacune des équipes
dans ton équipe,
« voici les problèmes que j'ai détectés,
tu dois les changer à l'échelle de ton équipe ».
En fait, le problème,
c'est qu'on a la vision de « je suis un SRE ».
En fait, en gros,
les SRE, c'est des équipes
où ils sont 6.
Et en fait, ils girent tout en même temps
et les 6 pensent avoir l'accès
à toute la code base.
Si jamais tu divises tes 6 SRE
dans des périmètres petits,
un certainement,
un charge mental,
elles changent beaucoup.
Et en fait,
faire un changement sur,
si jamais tu as 10 équipes
avec 10 rôles à changer,
oui, si jamais tu es dans une équipe globale,
tu te dis « merde, tu fais avoir
100 changements à faire, c'est géant,
je n'aurais pas besoin ».
Alors, si les SREs, ils sont petits,
en fait, normalement,
le rôle de l'informatique,
c'est de découper un problème complexe,
un problème plus petit
qu'on va pouvoir gérer.
C'est que la mode large.
Oui.
Mais la mode large,
elle est au niveau des équipes,
enfin, au niveau des équipes pas,
au niveau de ta code base.
Et surtout,
en décal d'interrompre.
Il y a un truc que tu as dit
dans la team, je l'ai fait,
ça ne marche pas.
Pourquoi ?
Parce que la team se dit
« C'est cool, j'ai plus à gérer à Prod,
les SREs, c'est le SRE qui va le faire.
En fait, le SRE devient la…
En fait, on a refait un silo
parce que c'est le SRE de la team
qui va faire tout le terrain,
tous les déploiements machins.
Et pour moi,
le SRE dans la team de Dev,
c'est un pattern que je lui ai appris à plein de roi,
ça finit tout à la même manière,
c'est les Dev sont pas plus autonomes
qu'avant sur la Prod,
parce qu'en fait,
il y a un SRE qui fait tout pour eux.
Donc tous les trucs taguer Prod, les alertes,
le SRE, le déploiement, le SRE,
les terraformes, le SRE.
Si tu as écouté tout à l'heure mes pieds,
c'est parce que justement,
il n'y a pas eu le dernier changement
qui a été fait, par exemple,
le partage de revenus entre les deux.
C'est-à-dire que quand il y a un problème
de Prod et que ça impacte
le revenu du Dev,
t'inquiète pas qu'ils s'en occupent,
et j'ai vu des cas où ça marche.
Alors en effet, quand tu as créé
une micro-équipe de SRE
au sein d'une autre équipe
qu'ils n'ont pas les mêmes tickets,
ils sont pas les mêmes machins,
normalement, SRE dans une équipe,
il peut toucher à n'importe quel ticket.
Mais tu sais,
il est partagé au sein de toute l'équipe.
Il peut aussi bien faire du Dev
que toucher à de la Prod.
Et c'est pas juste,
ah bah tu sais, on l'envoie à ce gars-là.
Parce que c'est...
Alors, je suis d'accord...
Ça, c'est un peu apaisi, tu peux pas demander.
Mais non, si ça existe,
ça existe, ça existe,
ça existe, c'est possible.
Ça existe.
Et je suis d'accord avec toi
que c'est le fonctionnement nominal.
Cela dit, imaginons,
tu as un TACIFI TREM, tu vois,
d'accord.
Donc, tu as un SQ qui allait voir
les six feature teams
qui leur a dit,
ok, du coup,
il y a des trucs à corriger
vous de notre infra, d'accord.
Les SRE,
ils se connaissent, d'accord.
Ils ont probablement un petit monthly,
d'accord,
pour parler de nouveautés technologiques,
etc.
D'accord.
Au bout d'un moment,
il y en a un, d'accord,
il a une semaine assez de chill, d'accord.
Il embarque tous les changements,
d'accord.
Il y a des trucs,
c'est 80% des changements
qu'il doit faire,
les autres équipes ont les mêmes.
Il écrit le code qui marche.
Il va pas le partager
avec les autres installs, bien sûr que si.
Mais le partager,
en fait, le partager,
ça peut se faire juste
par du copier-coller.
En fait, on a un besoin.
Tu fais un snippet,
tu dis, bon, voilà,
regardez les gars,
moi, j'ai fait changement là.
Tu le dis justement
dans un success story,
c'est ce que je disais.
Regardez, j'ai fait
tel changement,
j'ai fait comme ça.
Inspirez-vous, ou pas.
Parce qu'après,
il y a des gars qui diront,
bah ouais,
moi, dans mon cas,
en fait, c'est pas possible,
ça marche pas.
C'est cool, oui, mais donc,
comme ça,
j'ai pas imposé
un changement d'un module,
l'ajout de complexité
dans un module
qui potentiellement ne sert pas à tout.
Mais c'est pas ça,
donc je te parle.
Moi, ce que je te dis,
c'est, ok,
le gars, il a un fichier
toto.tf,
dans lequel
il y a
tous les changements
pour devenir confondres.
Tu fais ça dans un dossier,
fichier station,
c'est un module terraform.
C'est tout.
Mais il n'y a pas
de problème.
En fait,
tu peux le sortir
du module si tu as envie.
Mais c'est comme ça que tu fais.
Là, la question,
c'était de savoir
est-ce que tu vas partager
ou pas des choses
entre les équipes
de manière versionnée, etc.
Et ce serait extrêmement
peu pragmatique
de ne pas le faire.
Eh ben moi,
justement,
exactement.
Est-ce que tu vas ralentir
tout ton organisation ?
En fait,
tout le monde va m'en ralentir.
En fait, non, justement,
en fait, on s'aperçoit
et via l'agilité.
En fait,
c'est assez marrant.
J'ai l'impression vraiment
de revoir le débat de l'agilité
ou pas en se disant,
ah non,
mais avoir des petites équipes
qui ne vont pas vite
alors qu'on pourrait tout de suite
faire bien,
ça serait cool.
Mais on s'aperçoit
que ça, on s'enferlissait,
je te parle de collabours.
Et surtout,
tu fais des généralités
alors que tu dis que les organisation
qui font ça deviennent ça.
C'est pas vrai.
Globalement,
ah ben oui,
c'est ça, c'est un...
Ah non, non,
ça, c'est ton atter,
on est décompré,
mais non, mais il y a pas...
Ah, la preuve,
moi, il y a un peu d'autres
bâboires,
on se souvient.
Mais ça,
ça,
ça t'attendait plus que bien,
mais c'est pas si la pourrette
à retourner mieux.
Et ça,
ça, ça,
ça, on y travaille,
bien sûr, toujours.
J'étais très content d'avoir,
quand ils font
un nouveau service,
comme je l'ai dit,
ils appellent des modules terraformes,
ça a été audit par les SQ,
donc la SQ,
ce que moi,
je ne suis pas un expert IAM Amazon,
je sais que dans le module RDS,
ils ont fait tout ce qu'il faut
pour que ça soit carré niveau IAM,
etc.
Et moi,
je suis utilisateur de ce truc-là,
finalement.
Tout le monde est content
avec ce système,
il n'y a jamais eu de plainte.
C'est pas un argumentaire,
ça, c'est...
Non mais il y a jamais eu de problème,
on a jamais eu de problème,
ou SLO,
c'est toujours bon,
c'est pas bon.
On m'a dure,
on m'a dure.
La vélo-sqé est bonne,
je viens.
C'est combien de gens t'as mis
en face de ça,
c'est toujours une question de moyens,
pour y arriver,
pour avoir un truc qui fonctionne.
C'est un module,
c'est pas compliqué.
C'est un module,
c'est pas compliqué,
si tu sais déjà faire du terraforme.
Mais du coup,
si tu sais pas déjà faire du terraforme,
t'es vachement content d'avoir
des modules,
c'est ça le truc.
Parce que t'es pas obligé
d'aller lire
la spec de la pays
du ProHider,
pour comprendre ce que je veux faire.
Toi, tu te dis juste,
ouais, je veux une DB mahesquelle.

Et j'ai super content
qu'il y ait un mec
qui se dise, t'inquiète,
je suis expert à la dégâte.
Voici une DB mahesquelle.
Mais c'est pas un problème lindan,
tu peux avoir un exemple de code.
C'est la différence entre avoir
des exemples de code
et avoir des librairies.
Ça différence un exemple
et la prod, surtout.
C'est la forme,
qui dérange et plus.
En fait,
il y a pas de fous.
Je préfère un doc
où on dit,
là, une DB,
t'as ce bout de code là
qui marche,
je fais un copico.
C'est exactement ça.
C'est exactement ça.
C'est justement ça.
C'est justement ça.
C'est que la plupart des organisations,
c'est pas comme ça.
La plupart des organisations,
c'est non, non.
Il y a tel module,
la telle version,
vous devez l'utiliser de telle façon.
On te dit,
justement,
depuis le début,
qu'on est d'accord
que ça, c'est pas bien.
On te parle de tout le reste.
Si tu fais pas ça,
ça marche très bien.
Je pense pas
que tout le monde est d'accord
sur ce que tu viens de dire là.
Mais surtout,
moi,
j'ai jamais cru un exemple.
Le module,
l'infra de 2000 ressources,
elle utilisait plein de modules de merde
et qu'on a décidé de tous
arrêter de les utiliser.
Du coup, on a écrit nos propres modules
qui répondaient à nos propres besoins.
D'accord ?
Une fois qu'on les avait crées,
une fois qu'on avait un prod qui marchait,
une fois qu'on était conforme
avec toutes les normes de sécurité,
parce qu'il y avait
l'audit automatique de l'infra,
d'accord ?
On était conforme
avec toutes les normes de l'RSSI.
Et ben,
en fait,
on a dit,
ok, notre enfraile marche
et on a 3 autres équipes,
d'autres entités que j'ai jamais rencontrées
qui sont venus nous voir en disant,
ouais, nous aussi,
nous avons une question
migrant vers la même enfra
avec les mêmes constances.
Est-ce qu'on peut juste
avoir votre code,
en fait,
parce qu'on gagne du temps ?
Non, mais ça, mais ça, mais ça,
mais ça c'est...
Et qu'il s'adresse qu'ils utilisent
nos modules.
Voilà, mais en fait,
en fait, ils utilisent ces modules.
Ils utilisent,
ils utilisent une copie de tes ressources,
une copie de ton module.
Pour le coup, non.
Alors, en fait, il y a certaines,
alors justement,
nous on a distingué
deux types de modules.
On a décidé que les modules
qui sont génériques
du besoin métier,
d'accord ?

typiquement,
tu dis, je veux une ADS,
bah une ADS, c'est un peu pareil
pour tout.
Et par contre,
du coup, t'as d'autres modules
où c'est, par exemple,
spécifique à ton projet.
Je parlais d'un module
Data Pipeline, par exemple.
Ça, c'est spécifique à mon Archie.
Ce truc-là, il a aucun sens ailleurs.
Et du coup,
ces modules-là,
ils n'ont pas réutilisé.
Mais les briques
en dessous,
les plus petites briques,
en fait, elles sont
parfaitement réutilisables.
Et il y a des moments,
ils nous ont dit,
ouais, au fait,
il y a un nouveau truc
de la CQ
qui a été ajoutée,
et à un moment,
c'est une alerte de la CQ,
en disant, ouais,
on a acheté un paramètre
au niveau de l'auditabilité,
vous avez avoir mis.
On a reçu une PR
sur notre module
d'une autre équipe
qui patchait le truc.
C'est un paramètre ajouté,
zéro breaking change.
Moi, je t'ai refait,
d'accord.
J'ai gagné une heure
de lecture de Dove.
Donc moi,
je suis plutôt content.
Et en plus de ça,
derrière,
ces modules-là,
on ne dit pas
qu'on fait des gros changements.
Et je sais
qu'il y a d'autres équipes
qui les ont forquées,
d'accord, qui disaient,
ouais, la manière
dont vous gérer, par exemple,
les permissions,
c'est pas vraiment la manière
dont nous, on gère les permissions,
donc on le fait différemment.
Pareil pour le réseau d'ailleurs.
Ils n'ont pas eu de signe
au mode module de réseau.
Et si tu parles à des gens
qui sont capables d'utiliser
ton langage,
qui sont capables
d'écrire de terraformes,
ben rien,
mais on pêche le forquer
dans tout le monde.
Mais ça,
ce que tu viens de dire là,
c'est exactement ce que je dis
depuis le début.
Donc c'est de la carré-cit
à faire le forquer,
mais il y a plein de boîtes
que tout le monde utilise.
Là, je t'avoue, c'était chez Total,
c'est pas que des fois,
on la boite la plus chill,
mais il s'avère que je peux dire
qu'il n'y a pas un seul PO
qui se rend compte
qu'on t'a forqué un module par-avant.
Oui, mais ça, c'est un problème.
En fait, le problème,
l'un an,
c'est qu'il y a une courbe
d'apprentissage d'un an
où, au début,
les gens ont aucune idée
de ce qu'ils font,
donc en fait,
il y a la droite forquée.
Puis après,
il y a 3, 4 nazis
qui sont arrivés dans la boîte
qui disent,
non, non,
c'est moi qui sais
et vous allez utiliser ça.
Et après,
il y a les gens qui disent,
oui, on va commencer
à avoir un peu plus d'expérience
et se dire,
oui, j'en ai marre de galérer
à faire des trucs qui ne servent à rien
et à avoir des modules
qui deviennent extrêmement blagues.
Et tu vois,
il y a un espèce de courbe
comme ça d'apprentissage
qui arrive dans toutes les organisations.
Mais le truc qui ouvre,
c'est que tu vois,
on a même préméclé N-charts.
Il y a une équipe
qui se met à faire une N-charts,
donc en fait,
il y a un connard
qui veut rajouter une Toleration.
Hop, ça veut dire
R-H-C-A, etc.
Et en fait,
t'as une mode-chart
qui pensait être jolie.
En fait, à la fin,
t'as une value.yml
qui est exactement le mapping
1-1
de toutes les fonctionnalités
dans le truc normal.
Et ce qui se disait ça,
ce problème-là
avec les N-charts de la communauté
qui du coup veulent répondre
à littéralement 20 minutes
et en fait,
les modules terraformes
de la communauté,
ils ont exactement le même problème.
En fait,
ils cachent au plus de complexité
par rapport aux restaurants
sous.
Mais en fait,
ce que la communauté arrive,
ce que la communauté arrive,
c'est juste,
c'est ce que
tes modules internes
vont arriver.
Si jamais tu les laisse
assez longtemps.
En fait,
en gros, c'est un incubateur.
C'est genre,
tout ce qui est mauvais à l'échelle
communautaire, globalement,
il y a beaucoup de chance que ce soit
mauvais à l'échelle de ta boîte.
C'est juste...
R-H-C-A, etc.
C'est juste une question de temps,
mais ça va y arriver vers là.
Ça tente vers...
En fait, en gros,
en gros, c'est un système
asymptoting qui tente
vers ce bordel.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.



R-H-C-A, etc.


R-H-C-A, etc.






R-H-C-A, etc.

R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.



R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.







R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.

R-H-C-A, etc.

R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.


R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.





R-H-C-A, etc.
R-H-C-A, etc.
R-H-C-A, etc.

R-H-C-A, etc.