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, ça donne des résultats contrêts.
DevOps.
L'objectif individuel, ça s'atteint alors qu'une ambition, ça se partage.
Donc là, en fait, on a un peu moins de 2 heures, une heure 50.
On va avoir une table ronde avec 3 personnes qui sont globalement les champions du podcast DevOps francophone.
On a ici Guilem Lettron, qui est hyper expert du Bernet est,
et qui anime 2 podcasts qui sont dans ton cube, admirer le jeu de mot.
Et DevOps, l'observatoire du DevOps.
Et puis, on a ici Thomas Girardin, Damir pour les intimes.
Et Christophe Chaudier, Henri Maude, qui n'a pas pu se joindre à nous parce qu'il est dans le massif central
et que visiblement, les trains ne décollent pas aujourd'hui.
Et qui coigne tous les deux un podcast qui s'appelle Radio DevOps.
Donc voilà, ce sont des podcasts qui sont très réguliers, peut-être plus pour Radio DevOps que pour DevOps.
Mais voilà, donc en fait, je vous incite à écouter.
Et donc, cette session là aujourd'hui, avec une session qui sera publique.
C'est vraiment un podcast public.
Et qui est déjà arrivé parce que là, il est en live sur YouTube.
Comme vous le voyez, en fait, ce que vous voyez à l'écran, c'est pas ce qui passe en live YouTube.
Mais ici, il y a une caméra à 360°.
Donc moi, je suis dessus.
Merci, je suis sur le côté.
Et donc, en fait, la session, ça va être des questions-réquences.
Donc, j'ai sorti les post-it et je vais vous distribuer des post-it et des feutres.
Vous allez pouvoir référer à des questions qui vous viennent à l'esprit.
On va initier ça avec une question que je vais poser histoire de vous laisser réfléchir, cogiter à vos questions.
Et là, en fait, c'est feu pendant deux heures là.
Vous posez des questions que vous souhaitez.
Et je passerai la parole à ma petite camarade pour vous répondre.
Moi, j'en tiens bien pas.
Mais vous avez un retour de personnes qui sont vraiment à l'extérieur à la MGM sur ces sujets-là.
Et vous posez des questions qui nous viennent à l'estime.
Je sors les post-it.
Je sors les feutres.
Et on peut peut-être commencer avec une première question.
Alors, il y a déjà eu pour les gens de la MGM qui sont mis dans la salle.
Il y a déjà eu une première table ronde avec Avrien Blain, qui est un ancien de la société générale.
Et Laurent Grangeau qui est un Googler, qui est un personne qui est chez Google.
Sur DevOps, on avait abordé des questions qui étaient assez générale.
Il était qu'est-ce que le DevOps, quels sont les grands principes du DevOps, etc.
Vous pouvez évidemment poser des questions de ce genre si ça vous intéresse.
Là, je vais poser une question un peu plus orientée déjà,
pour éviter de faire de redondrance sur les questions généralistes.
Et évidemment, cet audio vidéo sera disponible sur la MGM.tv.
Une fois que j'aurai récupéré les rushs et que j'aurai fait le montage.
Tu as peut-être d'ailleurs, qu'on commence par notre expérience qu'on a eue avec le DevOps.
Ah ouais, on peut commencer par ça.
Je vais commencer comme ça.
J'ai déjà réfléchi en en proposant.
De quoi je travaille depuis 2009.
J'étais plutôt orienté aux ops à la base.
Donc, infrastructure, système, réseau, etc.
Et en fait, très vite, je me suis orienté.
J'ai commencé dans des ssdosies classiques,
avec des projets d'installation, lampes vraiment classiques en 2009.
Et en 2011, j'ai rejoint une startup.
Parce que voilà, je voulais essayer d'aller vers un monde un peu plus jeune, peut-être,
un peu plus dynamique, je sais pas.
Et ce que je faisais, c'est que je faisais de la CI pour même d'ailleurs, en ssdosie.
Je commençais à faire de la CI.
On a appelé ça des plateformes d'intégration continue à cette époque.
Donc, c'était du Jenkins, des choses comme ça.
Et c'est ce que j'ai commencé à faire dans une startup.
Et un jour, on s'était dit au bienvoir, c'était en 2012,
il y a un truc là, je l'ai entendu quelque chose dans un article,
enfin, j'ai vu quelque chose, ça s'appelle DevOps, regarde ce que c'est.
Et en fait, je commençais à regarder, je l'ai fait là, c'est marrant.
C'est exactement ce que je fais.
Ça ressemble en tout cas beaucoup, c'est-à-dire être en contact avec le développeur,
essayer de faire l'intégration continue, travailler sur l'architecture, etc.
Au conjoint, avec les devs.
Et en fait, ça a assez bien matché.
Donc, en fait, ce qu'il faut voir, c'est que le DevOps,
sa date de création, on estime à peu près 2009, en tout cas le terme.
Mais en fait, il y avait des gens qui faisaient déjà ce type d'infrastructure
et ce type de culture, on va dire, même avant 2009.
Et donc moi, c'est ma première introduction avec le DevOps.
Ça a été comme ça, ça a été vraiment mon CTO qui m'a envoyé un nom.
Et en fait, du jour au lendemain, j'ai changé mon poste,
j'ai été dans la DevOps washing, c'est-à-dire j'ai renommé architecte, système,
si jamais ça veut dire quelque chose, en DevOps, en 2012.
Oui, c'était mal de faire ça, mais peut-être on en reparlera.
Et voilà, et donc en fait, ça a été ça, ma première introduction avec le DevOps.
Et puis après ensuite, je suis allé dans pas mal de meetups DevOps
où on a essayé justement de travailler sur l'architecture,
sur la culture qu'on vient avec ça, donc on en discutera avec des camps, des acronymes comme ça.
Donc voilà, voilà, ma première introduction avec le DevOps, en tout cas, que j'ai pu avoir.
Et aujourd'hui, enfin moi, je suis consultant, indépendant,
et donc je travaille pour les entreprises, pour celles qui veulent passer à de l'agilité du DevOps,
et surtout autour de Kubernetes, là pour le moment.
D'où le podcast dans ton cube, Kubernetes.
Donc, Kubernetes.
Oui, alors moi, au début de ma classe, je suis développeur, et c'est vrai que j'ai un retour.
Et après, j'ai travaillé dans beaucoup de grandes boîtes,
notamment la plus grande, c'était Galbino, où je faisais la gestion d'applications,
je déployais les applications qui étaient fournies par les développeurs,
surtout les autres constructions, les HMS, on n'avait pas le code à l'époque.
Et en tête, ça ne faisait pas très bien l'adaptation avec les administrateurs systèmes TOPS
et les développeurs qui m'ont été impôts mieux.
Les tests sont rages, je vais commencer à poser des questions sur la futilité,
justement, des illustrations.
Après ça, j'ai devenu administrateur système, j'ai du Votre grand boîte,
avec l'idée de tout à la main, et je me suis dit que c'était quand même très fun
de faire une bonne place d'environnement,
puisqu'on mettait parfois plusieurs jours pour créer des fées,
et les mettre à l'histoire.
Et après, en tout cas, je suis lancé en main d'étendant,
j'ai fait un projet par startup pour ma première mission,
où j'ai fait des clouds et des devos, si je ne me présente pas comme ça.
En fait, j'ai fait une infrastructure à code,
on veut développer du code d'infrastructure
pour créer tout ce qui est environnemental,
je ne le fais pas avec administrateur cloud,
et je travaille beaucoup avec l'équipe tout à t'agréer,
et je ne le ferais pas super bien.
Donc après, je me suis spécialisé dans le déploiement des applications,
et aujourd'hui, je suis à Tipeee.io d'une libre unité,
qui s'appelle FromWit,
où on propose justement les barges en longs-guitres,
en fait, tout en main des vops, et je fais aussi du Montorat,
et évidemment, la vulgarisation des vops,
puisque j'ai le podcast et la chaîne YouTube.
Ok, je t'en prie.
Du coup, je vais fermer la marche là-dessus.
Moi, de mon côté, un peu comme Christophe,
j'ai commencé à entendre développeur,
donc j'aimais bien le développement,
mais j'étais un peu frustré,
c'était vraiment la caricature du développement à une époque,
on envoie le code, on ne savait pas ce qui allait se passer,
un jour, il allait venir en prod,
et j'étais un peu frustré,
il y a cette boîte noire où j'ai envoyé mon code
et il se passait des choses un peu magiques,
et un jour, ça arrivait en production.
Donc comme j'étais jeune,
et que je n'avais pas encore beaucoup d'experiences dans le dev,
je dis que je peux se switcher facilement,
je suis allé côté hops pour voir un peu comment ça se passait,
déjà, j'ai apprécié ça.
Donc je suis resté, j'adorerais automatiser les choses,
comprendre plus des problématiques,
on va dire, à une échelle différente,
une manière différente.
Et au final, je t'ai un peu frustré quand même,
parce que j'étais bien côté hops,
mais ça manquait, en fait, d'échanger avec des devs,
de comprendre leurs problématiques,
discuter avec eux et dire,
tiens, mais toi, qu'est-ce qu'il te manque,
comme élément de compréhension,
notre côté, etc.
Et cet élément-là, il me manquait,
c'est au moment où le dev hops
commençait un peu à apparaître
sur la scène publique en France,
il n'était plus un truc d'initié
entre une dizaine de personnes
qui en parlaient entre eux.
Et au début, j'ai eu un peu,
je ne confrais pas trop ce que c'était,
beaucoup de gens me disaient,
ouais, c'est un dev qui fait de l'ops,
c'est n'importe quoi,
il y a eu un peu ce washing
et ce blocage de beaucoup de personnes
qui ne voulaient pas en entendant parler.
Et du coup, au début,
j'étais un peu frustré de ça,
et puis je suis intérêt
chez un infogéreur
où j'ai rencontré Ludovic.
Infogéreur,
dans lequel j'ai vraiment un plus à prendre,
ce qui était le dev hops,
et j'ai pu découvrir
ce que c'était de retrailler des devs,
de travailler sur de l'intégration continue,
travailler avec des outils
dont on paraît sûrement un peu plus tard.
Donc c'était très sympa,
une fois que j'ai fait un peu
mes armes là-dessus sur le dev hops,
je suis parti dans une société de conseils
pour un peu voir pas mal de contexte,
j'ai bien changé,
rencontrer un peu des gens,
comprendre leurs problématiques,
leurs visions des choses,
pour les aider,
régler les choses,
régler leurs problématiques,
livrer plus vite, livrer mieux,
donc globalement faire du dev hops,
entre guillemets.
Et certains d'entre vous me connaissent peut-être
sur Twitter ou sur mon blog,
qui s'appelle damir.fr.
En tout cas, je publie régulièrement
des news ou des tests
de fonctionner de les cloud,
et plein d'outils sur le dev hops et autres.
Voilà, voilà.
Alors justement,
là, pendant qu'ils vont répondre,
je vais faire le tour des repotes
pour ramasser vos questions,
si vous en avez.
Donc si vous avez des questions,
vous avez déjà écrit dans le post-it,
une faite signe quand je passe,
de toute façon,
est-ce que je puisse les récupérer ?
D'accord ?
Alors, je vais poser une première question.
Ça roule pour moi.
Je vais poser une première question,
c'est qu'on parle beaucoup d'outils.
Moi, j'aimerais bien que vous nous expliquez un petit peu,
parce que ce matin,
par exemple, j'ai parlé pas mal de AsCode,
et j'aimerais bien que vous nous disiez un petit peu
pourquoi le côté dev,
enfin, infrascodes,
deployment AsCode, documentation AsCode,
pourquoi le AsCode,
c'est un truc qui est aussi présent
dans la culture et la mouvance des bords.
Peut-être Christophe d'abord,
parce qu'il est handicapé par le fait qu'il est en remonte,
et puis je vous laisse sa bonne diant suite.
Merci pour l'enricapé que je suis.
Alors, pour moi,
le AsCode a vraiment une importance,
parce qu'on est, en fait,
la partie d'importance pour l'humaine,
parce que c'est quand on a des numéras,
dans la telle ou finalement quand on a des erreurs,
et c'est comme ça,
mais sinon, on fait des erreurs.
Donc la partie AsCode,
dès qu'on provoque quelque chose,
en théorie, on va enlever ce côté humain,
et on va avoir un code qui est répétable à l'infini,
et qui va faire tout le temps la même chose.
On peut en plus,
recommandiner et lancer les événements
pendant le climat d'intervention humaine.
Ce qui permet aussi
aux développeurs, quand ils poussent leur code,
par exemple, sur Git,
d'avoir une intégration pour dire
qu'il va déployer AsCode
quelque chose sans intervention des hommes.
Les notes ont écrit avant
le process de déployement,
et puis tout le monde tournera,
et tout sera fluide.
Ben du coup,
c'est fini ou je...
Vas-y,
moi, de mon côté,
je pense que ce qui est important dans AsCode,
c'est comme Christophe le disait,
au final, on va surtout profiter du versioning qu'il y a derrière,
donc de pouvoir avoir un code,
on va pouvoir intérer, on va pouvoir revenir en arrière.
Très simple, et au cas qu'on a tous su,
moi j'ai eu beaucoup quand j'étais hopp,
c'est qu'on configurait des machines,
des choses à la main, on se retrouve à suivre des docs,
des fois de 3-4 pages,
et on se retrouve avec notre machine qui n'est pas d'état désiré,
et on est un peu...
Je recommence tout de zéro et je vois ce qu'elle loupait.
Là avec le AsCode, on va pouvoir
éviter ce type d'erreur,
éviter ce type de frustration,
et on va aussi pouvoir, par exemple, si on déploie
une nouvelle stack ou une nouvelle fonctionnalité,
revenir en arrière si il y a quelque chose qui n'était pas prévu,
ce qui avance faisait à l'aide de snapshot et de choses comme ça,
mais ce qui n'était pas toujours ultra pratique,
et pour moi il y a un vrai intérêt dans le contexte
de DevOps du AsCode, c'est tout simplement
en fait, du coup, derrière, du versioning,
pas avec Git et avec un serveur Git
et une usine logicielle adaptée,
mais ce qui est du coup d'avoir un langage commun
et un point commun avec les développeurs,
et d'avoir cette taxe de communication,
on va tous interagir avec les mêmes outils,
et pour moi c'est assez important,
parce qu'au final, quand on veut échanger à quelqu'un,
c'est de se comprendre, de connaître un peu les problématiques,
le fonctionnement, et ça pour moi, c'est un premier pas
parce que le versioning, au final, aujourd'hui,
c'est un peu le centre de tout, c'est le centre de votre
infrastructure, c'est le centre de vos développements,
donc c'est pour moi très important, dans ce langage
de base qui est partagé par les Ops, par les Dev,
par la sécurité ou par n'importe quel équipe.
Oui, je suis très d'accord avec ce qu'il a été dit,
puisque en fait, ce qui revient un peu en attendant,
donc on utilise le terme DevOps,
en fait, plus largement c'est l'agilité,
mais là, quand on le prend en termes de DevOps,
ce qu'il faut voir, c'est qu'il y a ce partage,
et même il y a un partage culturel qui va se faire,
c'est-à-dire que les Ops vont se mettre à utiliser
les outils des développeurs,
et même les pratiques des développeurs, donc on a parlé
de Git, on a parlé de tout ça, mais un point important,
c'est les tests, et c'est quelque chose,
c'est vrai, quand on a été Ops,
moi, je vais vraiment du monde de l'Ops,
vraiment à l'ancienne,
on n'avait pas cette
habitude de faire des tests, c'est pas quelque chose,
on est plus en mode pompier, ça veut dire,
on déploie, on fixe,
et ça recommence, et en fait,
c'est plus cette notion de pompier pyromane,
on met le feu et on s'allait teindre,
on met le feu et on s'allait teindre, on met le feu et on s'allait teindre.
Quand on arrive avec cette pratique
DevOps, c'est qu'on va se dire, on va utiliser
ce qui est bien dans le monde du développement,
les bonnes pratiques, les bons usages,
les bons patterns, et on va essayer
d'les appliquer au monde de l'opérationnel.
Et en fait, on arrive
quelque chose, enfin, un point où
la différence entre développeurs et Ops
est très faible, en fait, on va surtout avoir
des développeurs fronts, des développeurs
back et des développeurs d'infrastructure.
Et en fait, tout le monde est développeur.
Il n'y a pas cette division de métiers,
on est tous développeurs parce que développeurs,
ça veut juste dire qu'on apporte de la valeur
métier. Et là où avant,
l'Ops était vu comme un centre de support,
on était là pour régler les problèmes,
c'était un centre de coût, en fait, l'Ops.
En fait, on arrive à quelque chose grâce au DevOps,
où le l'Ops va être plutôt un centre de profit,
on va réussir à
déployer plus vite, amener de la valeur
plus rapidement en production. Et donc,
ce côté AsCode, en fait, ce qu'il valorise,
c'est le fait que les Ops
sont des devs comme les autres. C'est plutôt
ça là-dessus. Alors après moi, le côté
AsCode, c'est vrai que j'en reviens
un peu dans le sens où
je ne...
je n'aime pas trop cette notion d'infrastructure
AsCode maintenant. Je préfère
dire infrastructure déclarative, c'est-à-dire
que je vais déclarer l'état que je veux
dans mon infrastructure.
Et un code va se gérer de le déployer
et de converger vers l'état que je veux.
J'aime pas cette notion d'avoir des
du codes qui va s'exécuter en production,
parce que même si on l'a testé autant qu'on veut,
il y a toujours un cas où il y avait un petit
if dev, if staging, et quand on arrive
en production, il s'est passé quelque chose d'autre.
Et donc maintenant, moi, c'est vrai que je vais plus
faire de l'infrastructure déclarative.
Donc ça c'est encore un autre pattern de développement.
Mais...
Mais à la fin, il y a du code quand même qui s'afflique.
Il n'y a pas un humain qui va cliquer dessus.
Mais ça va être toute une autre façon de voir les prêts.
Mais voilà, ce que je veux dire surtout, c'est que
l'ops est un dev comme les autres,
d'où le code.
Ok, bien merci beaucoup.
Je vous ai écouté d'une oreille, il est bon, vous avez écouté quand même.
Alors on a pas mal de questions, déjà.
On va avoir un petit chapitre, on va dire
le devops est-il
l'immisible dans du legacy?
Donc je vous pose mes questions.
Déjà, le premier, c'est comment on fait le devops
avec des devs externalisés?
Et en particulier des devs en centre de service,
j'imagine que c'est déjà un...
C'est vrai que c'est ça.
Bah vas-y, Tanya, vas-y, je t'en brûle.

Bah du coup, c'est vrai que c'est quelque chose
qui peut paraître compliqué.
Moi j'avais connu le cas où, ben quand on est info gérard,
on n'a pas d'accès direct au dev.
C'est quelque chose qui est faisable mais qui demande
à s'adapter. Donc là, je n'ai pas de recettes
miracles. Ça dépend de la manière
dont fonctionnent les devs
externalisés des équipes.
Le mieux, c'est de pouvoir tout simplement les intégrer
dans le même cycle
de CI-CD, d'avoir accès
au même outil déjà, c'est important.
Et derrière ça,
de pouvoir aussi,
les intégrer potentiellement à des discussions
ou des échanges qui vont avoir un impact
sur, je pense notamment,
aux décisions structurelles de l'infrastructure.
C'est important de pouvoir
du coup directement travailler avec eux et éviter
en fait le défaut, donc en s'externaliser
d'avoir des cascades de mail
où vous allez avoir
des gens qui vont dire « ah, et après, ça va être
appris, mais après ça va être appris, me primes,
et au final, on ne s'est pas bien compris. »
Donc je pense que le mieux, c'est d'arriver à instaurer
vraiment une culture du direct
et éviter de se passer par des intermédiaires
souvent de management, tout de chose comme ça qui vont
un peu déformer les propos. Mais comme je disais, pour moi,
la deuxième chose, et ça, on en revient à ce qu'on disait juste avant,
c'est d'avoir des outils communs et un workflow
commun. Et ça, c'est pour des raisons
de compréhension. En fait, si chacun doit traduire
dans l'engagement, quelqu'un d'autre, on va avoir
une incompréhension et une frustration.
Je n'ai pas de recettes miracles.
Oui, il faut attendre bien
que tu te rends la vanne, parce que justement,
ça le fait pour ça, il faut en bien chauffer.
Alors, il faut aller encore plus loin.
Au moins, il faut définir
une culture commune
entre les devs extramédiaires, les devs
intermédiaires et les autres. Il faut vraiment
partager, même en calcul, la même culture
et les mêmes objectifs.
C'est quoi les objectifs de l'équipe,
plus largement de l'entreprise,
et en fait,
l'équipe de développement extralaisie
doit partager ses objectifs, parce que si
ce n'est pas partagé,
il va y avoir un problème de coopération
et du coup, on ne va pas pouvoir faire du délop
parce que la base du délop, c'est quand même
la coopération dans les équipes.
Évidemment, parce que la culture
commune, elle va passer aussi
au travers des équipes communes
et les productifs en favorisent
d'épreuves.
En fait, c'est assez drôle
comme question, dans le sens
où DevOps, à la base,
ça veut dire aji for infrastructure.
Et en fait, c'était trop long.
La personne qui inventait le terme, la résumé en DevOps.
Mais à la base, c'est l'agilité appliquée
à l'infrastructure. Et en fait, l'agilité
à la base a été faite par des externes.
En fait, c'était des gens qui étaient dans des sociétés de services
qui se sont dit, comment je fais en sorte de pouvoir livrer
de la valeur à mon client plus rapidement, plus simplement
sans avoir besoin de faire des alertures en permanence.
L'agilité a dans son coeur
même la notion d'avoir
des développeurs externes.
Et je suis entièrement d'accord, en fait,
avec ce qui a été dit avant, c'est qu'il faut avoir
des outillages communs, il faut avoir du partage
et surtout du partage, même en termes
de communication.
Ce qui est le plus problématique, la plupart du temps,
d'expérience
dans des projets,
pour passer à du DevOps, ça va plutôt
être le budgetaire. La façon
dont est conçue le projet.
Est-ce que mon projet, je l'ai conçu
avec une phase de build et une phase de run après,
avec un TMA.
Et dans ces cas, on ne peut pas faire du DevOps.
Dans ces cas, le DevOps, ça va être
une amélioration continue, on va se dire
qu'on va faire une première intération, on va revenir,
on va s'améliorer, on va améliorer
les process de qualité, de build, de sécurité, etc.
Mais si on a cette volonté
dans une entreprise de se dire
non, j'embauche quelqu'un pour
un an pour qu'il me fasse le projet
et après, ce sera mes équipes internes qui feront
de la TMA, clairement
il y aura un problème. Parce que d'un seul coup,
ça veut dire qu'il y aura un passage de connaissance
qui sera extrêmement compliqué, avec des gens
qui sont vraiment de deux métiers différents.
Là où dans le DevOps, on va essayer justement
de mixer ces choses-là, t'es en sorte que les gens communiquent
dès le début du projet, puis travailler
sur l'architecture que tout le monde sache
de ne pas avoir se jeter en production, donc
le Waterfall qui est cette cascade
ou quelqu'un fait, puis balance en dessous à celui
qui est après dans la chaîne.
Mais ça peut être du dé... Alors en fait, entre le Dev et l'Ops,
on va avoir, par exemple, l'équipe de QA, on va avoir
plein d'équipes en fait entre les deux. On peut même
rajouter dans le DevOps, les gens qui sont le business
et le support après l'Ops. Parce qu'en fait,
toutes ces chaînes-là font partie de cette chaîne
de production de valeur. Si jamais les développeurs
ont fait quelque chose de mauvais, que les Ops
ont réussi à mettre en production, mais derrière
c'est le support qui se retrouve à être écroulé,
il y a un problème. Donc en fait, c'est pour ça
que c'est toute cette chaîne-là qu'il faut prendre en compte.
Et donc des fois, c'est la manière même dont on pense
un projet, qu'il faut des fois revoir
et se dire bah non, en fait, le projet, il n'a pas
de date de fin. Et c'est problématique parce que
historiquement, enfin, quand je faisais de la gestion
de projet à l'école, on nous apprenait bien
qu'un projet, ça se définissait par une équipe
et une date de fin. Et ça c'est un projet.
La projet, c'est toujours défini comme ça. Et quand on arrive
à être du DevOps ou à de l'agilité,
bah il n'y a pas de date de fin prévue à l'avant.
Ça sera fini quand ça sera fini, on décidera.
Enceinte de la date de fin.
Et ça c'est un problème souvent en budgetairement
quand on a besoin de faire des
des... des...
des... de manière comptable, de dire non,
mais là je fais de l'amortissement comptable
et donc je dis ça c'est la phase de run et ça
c'est la phase de build. Et voilà,
et je la mortirais sur le temps du projet.

Je vais compter la réponse
pour elle, avec un chelmets plug.
Vous pouvez aller voir la magnifique
intervention du DevOps Rex 2018
qui s'appelle
Comment faire du DevOps dans une relation
compratuelle entre les défis niaans et les
DevOps-for-unisseurs. Je ne sais pas qui a
présenté ça.
Alors, on a des questions
toujours sur le chapitre Légation,
on va essayer de plaire ça par
le thème à dire que deviennent les
OVS traditionnels quand on fait du DevOps ?
Christophe
Ils sont toujours là, ils ont juste changé de
pratique en fait.
C'est la version courte.
La pratique c'est quoi, ils ont changé de
pratique ? Vers quoi en fait ?
En fait, voilà, quand on fait
l'OVS traditionnel on ne le
m'a dit pas, on ne l'opère pas,
mais les compétences
de gestion d'infrastructures sont toujours là.
Et en fait quand on va faire du DevOps
on va juste changer
le meilleur de la chose, c'est-à-dire que
plutôt de les se connecter sur les machines
et puis les installer, on va faire du Haskell
plutôt de passer par des tickets
on va plutôt discuter
avec les gens, les tickets et les
toujours, mais on va plutôt aller
discuter et faire avec les devs.
Mais par contre, la connaissance
métier elle est toujours là. C'est-à-dire
que c'est une nouvelle manière pour moi de
faire son métier. Moi je me défilisais
comme un administrateur cloud des Vostres
et je lui donne un administrateur cloud
et un administrateur système, je faisais
au début de ma carrière de frérence.
Vas-y je t'en prie.
Ouais, c'est exactement ça.
C'est souvent un terme, maintenant on emploie
le terme SRE des fois pour
signifier ça, qui est Site-Alability Engineer
qui est forme de DevOps fait par Google.
Donc ils ont 3 livres maintenant
qui parlent de ça, de comment ils font
un terme. Ne répétez pas, je vais juste
prendre des idées ou des exemples.
Il y a aussi un autre point qui est important
c'est que des fois ces obsoles-là vont juste être
intégrés dans un produit d'infrastructure.
C'est-à-dire qu'ils vont continuer de faire leur métier, peut-être même d'installer
des machines, il y aura souvent besoin
de continuer d'installer des machines, de continuer
de faire ce travail-là. Mais en fait ils vont être intégrés
dans un produit et au lieu d'être
la dernière roue du carrosse, pour le coup
dans la chaîne, et pour le coup ils vont être
un produit, ils vont avoir
des clients, ils vont donc
répondre à des besoins clients. Et donc en fait
c'est même quasiment plus valorisant parce qu'on est vraiment
avec des développeurs peut-être qui vont faire
un portail pour ces obsoles-là, pour avoir
des machinasses de services, des choses comme ça.
Et donc en fait les obsoles sont toujours là, mais ils sont
euh... enfin moi j'essaye en tout cas
de dire ça, ça devient un centre de profit.
Ça devient vraiment inéquipe, qui a une valeur ajoutée
et qui peut la montrer, même d'un point de vue
euh... enfin souvent
enfin moi dans les entreprises où j'ai été, c'était dur
de valoriser les obsoles, de valoriser
même leurs augmentations des fois, parce que
personne ne sait trop
combien ils font gagner à l'entreprise. On sait que
sans eux tout tombe, mais on sait pas
exactement combien ça apporte à l'entreprise.
Bah là avec un... avec un portail
avec donc du cell service, avec des
API, des choses comme ça, on peut directement
dire bah regardez, les obs, le produit
des obs euh... est utilisé
par tant d'équipes, il y a eu une progression
en termes d'usage, etc. Et donc les obs
sont directement partis intégrants du produit
et travaillent des fois avec quelques devs. Donc en fait
souvent on va avoir des équipes avec plein devs
et quelques obs, qui vont les aider
à faire les C.I. Et certains produits
avec quelques devs et plein d'obs. Et on va
avoir comme ça des produits assez différents en fonction
de l'usage.
Bah du coup je suis assez d'accord
avec ce qui a été dit.
Même si je suis pas d'accord sur la partie
automatisation, parce qu'on n'a pas... à mon sens on n'a pas
attendu de la vote pour en faire, même ça se faisait
avec d'autres outils un peu plus primitifs et un peu
différemment. Mais c'est vrai que
sur la vie... bah ce que vont devenir les obs
bah ils vont évoluer en fait. Un peu comme les
Pokémon ou comme les développeurs quand la agilité
a paru. On n'a pas... on n'a pas dit
bah y a de l'agilité, on ne met plus de développeurs.
C'est juste le métier, la manière de travailler
qu'il a évolué. Bah là c'est un peu pareil pour
les obs. Comme... comme Guillem le disait
bah ça va devenir effectivement
une vision plus produite. Et ce qui va apporter
plus de choses que c'est vrai qu'on a du mal
à quantifier un obs. Ce qui fait gagner. Par contre
généralement l'entreprise c'est ce qui fait perdre,
ça marche mal. C'est souvent du pris
là que c'est vu. Et là on va pouvoir
notamment plus défendre en fait cette position
et ce que ça apporte à l'entreprise. Notamment
partout le billet aussi de prendre...
prendre l'initiative de mesurer les choses.
Donc ça c'est quelque chose qu'on a étend. Ça ne pas
faire avant. Mais aujourd'hui c'est devenu
un classique de mesurer
le nombre de machines qu'on va
lancer, on va dire, dynamiquement, ou de services.
Le nombre de requêtes qu'on va avoir
au niveau des API qui vont exploser
les opérationnels pour d'ailleurs exploser
des ressources. Et ces métriques là sont intéressantes
parce qu'elles vont pouvoir réellement permettre
en fait de déterminer ce qu'on rapporte en valeur
en tant qu'opérationnel. Et au-delà
de ça, les opérationnels existeront
toujours. Ce qu'il faudra toujours
gérer des machines, ce que même si on dit
serverless aujourd'hui et tout ça, derrière
il y a bien des machines à un moment. C'est pas
totalement magique. Donc du coup, c'est juste
qu'ils vont travailler un peu autrement, qui vont
plus... En fait c'est juste que le métier ça va
pu être. Je reçois un ticket. Moi je me rappelle
au début on se faisait des tickets en disant
il faut installer une machine débian avec PHP
en merciant tel, avec tel module. On installait
ça et après on faisait un screen
du PHP info. Je pense qu'on a tous un peu
connu et on envoyait ça. On disait
voilà c'est installé. Et aujourd'hui la vision
c'est plus... Ben non, je vais créer
des API et de l'automatisation qui vont
exposer un portail qui va permettre
en fait à mon développeur de
stop la machine et lui derrière, il pourra
déployer ce qu'il veut avec la CISID. Et ça
va pouvoir du coup, en plus, le mesurer quantifier
ce qui est top. Le métier il va pas
disparaître, il va juste évoluer.
Alors je me permets encore une fois un
chaîne SQL. C'est un sujet qui a été
particulièrement
adressé
lors de la session
de l'UdebsakeOps Tour
à Aobo KB par Adrien Blain qui a fait un
talk l'une heure sur le sujet
que donnaient les ops dans un
Google DevOps. Donc, encore une fois,
la vidéo sera dispose sur l'Edge.com TV.
Vous invitez à aller voir parce qu'il
s'est éprimé assez longuement là-dessous.
Pour clôturer un petit peu
le chapitre legacy, c'est
comme on fait pour mettre en place
Google DevOps sur un parc applicatif existant,
entendé par là, un parc applicatif qui
n'est pas forcément cloud native
avec un
rythme projet
qui peut être relativement lent parce que
encore une fois, c'est du legacy, il y a
de la contrainte, il y a de la sédimentation,
il y a des vieilles technos.
Guylaine, je te laisse, je t'en prie.
Oui, je suis assez
partagé sur ce type de
sujet-là.
Il y a des quick-win
qu'on peut utiliser
qui vont permettre d'améliorer
encore son détest de la CIA et des choses comme ça.
Ça va être des petits quick-win, surtout d'outillage.
Mais personnellement,
j'ai plutôt tendance à dire
don't touch aoye lady,
c'est-à-dire, laisser mourir le projet
en paix. Genre, laisser le tronc
si il fonctionne, alors actuellement,
laisser le mourir en paix.
Et gardez-vous du temps, de l'énergie, de l'effort
de...
Enfin, tout ce qu'il faut, même mentalement
pour le prochain projet.
En fait, en se disant, le projet projet, avec tout ce qu'on a appris,
on fera peut-être un peu mieux. Et en fait,
de laisser mourir des projets,
de gérer cette bascule, c'est
des fois même de préparer
devant le projet la suite.
C'est devant une application, de mettre un API manager,
par exemple, qui va permettre de se dire
je vais un API manager qui va permettre de monitorer
l'usage de l'ancien... de l'ancien
applicatif. Et en plus, le jour
où je mettrai la V2, et bien tout de suite
je pourrais y aller en fait. Et donc, je pourrais faire vivre
et cohabiter deux mondes
en même temps via ce type d'outillage-là.
Et donc, en fait, des fois, c'est peut-être de rajouter
des choses devant
l'applicatif pour pouvoir le faire basculer
au fur et à mesure. Et c'est notamment utilisé par
plein de gens qui ont des gros monolithes
ou le monolithe, clairement,
il y a personne qui arrive d'un seul coup
en un seul, débrancher le monolithe
et hop là, toute la nouvelle infrastructure
se lance. Mais c'est de se dire, au fur et à mesure,
on va décharger, on va...
et j'aime bien
Don't Touch a Oil Lady, c'est vraiment...
elle est là, elle fonctionne. Mais on va peut-être avoir
maintenant des petits jeunes à côté qui vont l'aider,
qui vont porter son sac, etc.
jusqu'au jour où
bah voilà, le projet
peut mourir en pêtre, tranquillement, l'un de l'autre.
Moi, c'est plus ma vision des choses à l'heure actuelle
et ça permet de limiter l'effort
et il faut voir qu'à chaque fois qu'on modifie
un composant, on le met en danger,
enfin, on le stress un peu. Donc,
potentiellement, même si jamais vous lancez
dans une transition de DevOps sur des vieux projets,
vous risquez d'avoir des échecs
et qui vont peut-être même d'ailleurs
mettre en péril tout le reste de la transition de DevOps
ou la vision des gens du DevOps. Donc, des fois,
privilégiez ça
sur les nouveaux projets, cool, etc.
pour pouvoir avoir des success stories
qui vont après permettre
de profiter pour que le management
se dise, ah oui, on a eu des success stories, donc
ça vaut le coup d'essayer d'avoir de nouveaux projets.
Alors, si on commence sur les anciens projets, qui sont en plus les plus critiques,
il y a beaucoup de chances qu'il y ait des problèmes,
parce que voilà, c'est normal d'échouer
et c'est un problème, si jamais
c'est vraiment la chose critique.
Pristof, pour vous dire
je vous rappel de la question, c'était
comment est-ce qu'on fait
une transformation de DevOps
sur un parc applicatif existant
legacy, cédimenté, etc.
C'est-à-dire, postile au DevOps
au sens technologique du terme.
Oui, ok. Alors, je remets mon casque
comme ça, je n'ai pas les coups. Alors, il y a
plus
pour moi, si
on doit absolument mettre en place
du DevOps dans ce genre d'applicatif
en fait, la première chose à faire
c'est l'analyme des pratiques des équipes
des équipes de DevOps
Est-ce que déjà, elle partage les mêmes objets
est-ce que elle versionne leur code dans 8
est-ce qu'elle intégration continue
par le bien
parce qu'en fait, ce genre
de prolès, c'est les meilleurs projets
pour changer
pour commencer à changer en bouffeur
c'est-à-dire, à changer les pratiques des équipes
changer les pratiques de code.
Donc, est-ce que la courée entre les VA
c'est-à-dire, est-ce qu'on va
mettre en place des tests, est-ce qu'on va
utiliser une version avec une
ou un autre. Et puis après, l'état
de suivance, est-ce qu'on peut mettre en place
des déploiements via des objets d'automatisation
sans en parler
d'un exemple, mais là vraiment
est-ce qu'on peut utiliser des outils comme
le perfection qui nous permettent
de faire la configuration
à soi?
Ce n'est pas dans la phrase code, vraiment, mais on commence
et puis, surtout
en profite de ces
projets pour mettre en place la
collaboration entre les équipes, et vraiment changer
les choses. Est-ce qu'on n'a pas d'impératif
d'y mettre très fort
par rapport à
toute automatisation?
Et bien du coup, on va
utiliser sur le changement lié
aux femmes qui travaillent sur ces projets-là.
Et après,
ça permet de se penser
plus oralement sur
les vrais projets où on va pouvoir partir
avec du cloud, de la phrase code
des necessités entre les forces, etc.

Du coup
compléter un peu ce que j'ai pas mal de choses qui ont été dites.
Je pense que, ouais, en tout cas d'un point de vue
purement technologique, pour moi le plus important
c'est d'établir une base d'outils un peu
peut-être plus modernes et plus adaptées au DevOps
dans le cas du legacy. Et pour construire
ces outils, pour moi le plus important, c'est vraiment
d'impliquer tout le monde. Pour que du coup, il est
dès la base en fait, une sort
d'émulsion culturelle sur l'échange
sur les différents outils, que tout le monde soit d'accord
et que tout le monde n'est participé à cette prise de décision.
Pour moi, c'est très important, parce qu'il y a de l'adhérence
en fait sur ces nouveaux outils et ces nouvelles stacks.
Après, pour la partie vraiment purement applicative
je pense que c'est très utopique
de penser qu'on va pouvoir un jour
recoder tout et faire
un truc super en microservice
et basculer tout d'un coup dessus. Et là-dessus
je pense,
je suis un peu plus dans la vision de Gillem, qui va être
du coup
de passer ça dans un portail, un proxy ou autre
et petit à petit en fait, découper le legacy
vraiment essayer de retirer un peu les bouts
potentiellement plus critiques, essayer
de faire avec les trucs les moins critiques au départ
pour un peu se faire la main, pour avoir des victoires exposées
et je pense qu'on a en parlé des échecs,
s'il y a des échecs, ça peut arriver,
ça arrivera sûrement au début du DevOps, surtout
quand les équipes et les outils sont un peu vieillissants,
quand les gens n'ont pas l'habitude, il y a des échecs
et l'important, c'est pas qu'il y ait des échecs, c'est que
d'en tirer des choses.
Pour moi, il faut pas esté à capitaliser là-dessus,
à faire des points, à en parler ensemble,
à présenter, dire, bah ça, ce projet là,
on a découpé telle partie dans un micro-service,
on a mis en prod, on a vu que c'était instable,
on a eu tel problème, tel problème et échanger
dessus, parce que c'est en échangeant sur ces problèmes aussi
qu'on va créer une culture d'amélioration continue
qui va nous permettre d'améliorer aussi un peu
les nouveaux outils qu'on va emplacer, parce que quand
on met une place, une stack d'outils, entre guillemets,
DevOps, donc une stack d'usines logicielles,
souvent, tant qu'on n'a pas testé,
il y a des petits trucs qu'on a oubliés,
ou des petits trucs qu'on se dit, ah merde, ça,
j'avais oublié ce cas là, comment je fais pour le mettre en place.
Donc du coup, pour les cas là, pour moi, c'est très important
d'échanger, vraiment de créer cet esprit de communauté
autour des nouveaux outils et de nouvelles pratiques
pour l'affaire évoluer, vers quelque chose
qui correspond à l'entreprise et dans le contexte.
Je crois que Dylan, tu as réagi, tu as tiré.
Tout le monde a été noir agi, je n'ai pas soumis les mots.
C'est bon. Super.
Donc, bah côté les gars, si on est à peu près fini,
donc on va faire un petit, on va faire une petite pause.
Ça fait une petite demi-heure qu'on va parler maintenant,
messieurs. Donc on va faire une petite pause troll.
Alors au niveau du cloud public,
c'est au Gafam ou ce qu'elle est au RH?
Christophe Chaudier.
C'est au Gafam.
On ne faut pas aller chez les Américains
parce qu'on a des lois interditoriales
qui nous empêchent en fait d'être sereins
qui d'avis de ces clubs.
Et avec ça, ça remonte à plupart
pour l'évasion fiscale, donc ça c'est une position
politique que je garde.
Donc plutôt que là, d'Europe et un, les Français,
pour même pas.
Est-ce que, alors au-delà de la position,
on va dire la posture, je dirais,
politique ou grandir
militante, est-ce que
il y a des questions opérationnelles
qui font ou
ou financières
ou de gouvernance
qui font, on va plutôt vers un
Gafam ou un Skallway ou un RH?
Oui. En fait, chaque
secteur de banque va être à la midi.
Et en fonction du besoin
et de l'objectif, il peut pas dire le meilleur
drop provider là-dessus.
Et les critères
peuvent à la fois être techniques
stratégiques et politiques.
J'insiste sur ces 3
mais il y a certaines boîtes
qui prennent que des critères
techniques et d'autres qui prennent
que des critères stratégiques. Pour moi, il faut les 3 types de critères.
Bien bien.
Guylaine, tu veux repondir?
Oui.
Toujours un sujet un peu touchy.
Et sinon, il va rester trop de temps là-dessus.
Oui, je pense ça.
Si vous voulez entendre, j'ai un podcast
de 2 heures et on doit encore faire 2 heures de
plus sur le flood souverain.
C'est le dernier que j'ai fait. Pour vous dire
que c'est vaste du sujet.
Je pense qu'on a un énorme problème avec les opérateurs
européens, c'est qu'ils ne sont pas au niveau.
Donc ça veut dire que ça va
dépendre beaucoup de ce que vous allez vouloir faire.
C'est-à-dire que si technologiquement
vous avez un besoin qui est assez limité
que en effet, politiquement, vous ne voulez vraiment pas
aller sur des GAFA, alors bah
il ne vous reste pas beaucoup de choix, donc vous avez
ceux qui ont l'art. Le problème
des acteurs français, c'est qu'en fait, ils vont vous faire perdre
énormément de temps. C'est-à-dire que les GAFA
ont une avance qui est démesurée
qui font qu'elles vont vous permettre
instantanément d'avoir
le state of the art.
L'état de l'art de exactement ce qui marche bien.
Et l'exemple typique
c'est sur Kubernetes, où
plein de gens commencent
sur du UVH Scale-O-Way.
Vous vous rapprenez à aller sur Twitter en disant
que la Kubernetes c'est compliqué.
Ces gens-là, moi je les récupère, je les mets sur GCP
et en 3 minutes, les développeurs ont quelque chose
qui fonctionne de A à Z.
Et c'est pas un problème, c'est-à-dire que juste à l'heure actuelle
la pression qui doit être mise notamment
aux acteurs français, c'est aussi celle-ci, c'est celle
de la qualité, et c'est de se dire
aller les voir, enfin, et de choisir
en fait pas un acteur en fonction de
enfin, de choisir à chaque fois
un acteur en se disant qu'on peut en partir.
C'est en utilisant des technologies
open source. Si jamais votre basse post-gray
elle est chez un provider A,
et ben demain où vous faites un DOM, vous serez chez
le provider B, même entre les GAFA.
Et c'est de vous dire que
en permanence, en mettant la pression
sur des acteurs français, on arrivera
à élever le niveau de qualité. En tout cas moi c'est ça que je pense.
Et de se dire même d'ailleurs qu'on peut avoir
plusieurs parcs, peut-être même avoir des applications
qui ont des besoins, et notamment
enfin je travaille pour plein d'entreprises qui sont même
sur du Alibaba, parce qu'ils ont besoin d'aller
sur le marché chinois, donc parle des GAFA
mais il y a le marché chinois qui est un gros marché
et donc les GAFA c'est pas possible.
Et donc à l'heure actuelle
il y a plein de gens qui font de librais de cloud en se disant
Macia est chez A,
Ma Prod est sur Memon Data Center,
une autre Prod est chez un GAFA
et ça permet même d'ailleurs de challenger
en interne, de comprendre les projets,
de comprendre les produits. Et la diversité
est quelque chose d'extrêmement bon.
C'est vraiment quelque chose qui doit être bien
en sachant à chaque fois que vous pouvez en partir,
que vous n'êtes pas marié avec quelqu'un
et voilà, et c'est plutôt ça en fait que je veux dire,
c'est choisissez des choses en vous disant
à chaque fois on peut en partir
même si ça a un petit coup de
de partir.
Damiens ?
Ouais je suis assez d'accord sur le fait qu'on
de choisir des choses sur lesquelles on peut partir
même si je nuance un peu, faut pas avoir
l'image de ces magiques, si on utilise
d'une infrastructure avec un cube, un post-gray
chez AWS, et qu'on veut le basculer
chez SkyLway, excusez-moi,
il faut recoder d'art ou un infrascode
comme on disait, par exemple Terraform,
vos adressages réseaux etc. Donc c'est pas
si transparent mais ça se fait quand même beaucoup mieux
que si on choisit des produits fermés.
Après dire ça dépend des cas en fait
je sais qu'AWS
comment dire, ils ont des produits ultra avancés,
il y a des startups qui commencent vraiment
à pas se lentir avec
pas grand chose on va dire, et qui doivent
assez rapidement mettre des POCs en ligne
et des choses comme ça, et souvent
d'un point de vue purement technique, c'est plus simple
chez AWS, c'est plus simple chez d'autres
ce qui vont avoir des services tout fait,
des choses qui existent déjà. Après
il y a des acteurs comme SkyLway
OVR je considère un peu moins parce qu'ils ont
à mon sens beaucoup de maturité
sur une vision produit plus moderne avec
des API et des choses comme ça, mais
vous avez des produits français qui fonctionnent mais encore une fois
en fait il faut vous attendre, si vous
êtes du cloud français, il faut être prêt en tant qu'entreprise
à vous dire, j'ai besoin de tel service
il existe pas en version manager, donc
il ne propose pas sur un plateau, je vais d'ailleurs
redevelopper un peu
à ma sauce un système pour faire mes
images avec du packer en cible
ou des choses comme ça, pour en fait
m'exposer à moi-même ce service, ou me mettre
dans du contenu, mais il faut être prêt en fait
à prendre des fois ce temps de se dire
sur ce Sprinkler, j'ai besoin de ça, c'est pas juste
tac, je le demande et je l'ai en mode
accès libre, je vais devoir un peu
repenser tout ça, mais si on est prêt
ça peut très bien marcher aussi.
Pour la première fois, je vais me l'expliquer
pour structurer un petit peu la pensée sur
quels sont les clés d'arbonitrage
sur un choix
de cloud provider ou pas,
c'est un conseil
de la conférence qui a été faite au DevOps
d'idée en 2018,
sur le cloud public
le cycle de live et derrière nous, on le
compterait loin, encore une fois
qui a été
expliqué par Adrien Melin, qui était
présent au calais
il y a trois semaines, et par mois-même
il y a une dernière nouvelle.
Je vais rajouter aussi quelque chose de celui dont on a pas parlé
la spèce sécurité
puisque moi en fait j'étais architecte
au Hdh, donc Helds Data Hub
sur Azure, comme on l'a su
donc j'étais architecte technique
là-bas, et il faut voir que c'est un point qu'on a
jamais dit, enfin qui a
jamais été soulevé dans le débat, c'est que
les architectures sécurité
des cloud provider
français sont extrêmement
basses, c'est à dire qu'on a pas
de réseau sécurisé bien, on a pas
de chiffrement at rest des disques durs
c'est ce qui s'est passé avec Skyloway
on s'est retrouvé avoir des disques durs
sur Skyloway, sur le bon coin, avec toutes les
deux mé clients, en clair
on a
plein de problèmes comme ça, sur ovh
le vrack, c'est yolo
pareil, plein de choses comme ça, donc
en gros, il faut voir que
d'un point de vue, des fois même juste
du choix de ce qu'on doit faire
il y a l'aspect, nous par exemple, qu'on était
sur AZUR, aucun était sur AZUR, aucun potentiellement
ce qui est faux, mais potentiellement
l'état américain pouvait aller voir
mais nous on se protégeait d'abord de hackers russes
ou de gens qui voulaient voler les données
pas d'une extraterritorialité, le principal
vous devez à chaque fois faire une
évaluation des risques par rapport à celui qui est le plus probable
c'est à dire que oui en effet
les Etats-Unis pourraient faire des choses
comme ça, mais nous il y avait juste des hackers qui
tous les jours essayaient de nous voler des données
donc on a y allé, dans celui qui nous permettait
de s'égriger les droits de manière
le plus fines possible
et ça c'est quelque chose que quand on fait
l'évaluation de notre la provévert, on doit prendre en compte
est-ce qu'il y a un ayam pour valider les identités
des gens ?
un autre type, il y en a pas chez les français, enfin
il n'y a pas d'ayam, enfin voilà c'est
ce genre de choses-là aussi qu'il faut regarder
et j'ai pas envie moi de reconnaître un ayam
avec l'un de raisons, celle que je suis fainé
déjà, mais c'est pas celle que
ce que j'ai envie de faire par défaut
donc voilà aussi le choix qu'il faut faire
et qu'il faut avoir conscience quand on va
dans ses prévénements
mais si jamais j'ai pas problème de sécurité
avec un projet perso etc, ça va très bien
chez un français, il faut faire le choix
par rapport à ce qu'on veut et à ce qu'on fait
j'ai beaucoup de petites questions
comme ça, on va dire un peu trop l'esque
mais je vais garder pour les vitres respirations
on va se faire un bon chapitre
sur la transfert de l'opsoir
il y a une petite 5-6 questions
alors la première c'est
quelles sont les grandes étapes et les écueils
à éviter dans une transformation
entre une affaire traditionnelle et une affaire à ce code
Ok, du coup
des choses qui sont un peu à éviter
là dedans, à mon sens
souvent c'est qu'on va partir
sur, je vais imaginer le cas, on va partir
sur le cloud et des choses comme ça
dans le cas là, il faut essayer de profiter
un peu toutes les fonctionnalités
donc dans le cas où on change là, je parle plus
d'un passage vers le cloud avec le IAAC
on va essayer le plus possible
de s'adapter aux nouvelles fonctionnalités
des autoscanning groups, des choses comme ça
notamment, ça peut être aussi pour des raisons économiques
simplement éteindre des VM la nuit
ou en mettre moins dans l'autoscanning group
c'est des choses assez classiques
donc on va essayer de s'adapter là-dessus
après on va essayer du coup de
on va pas essayer, on va du coup
plus rien faire à la main
donc ça veut dire qu'il faut à un moment se forcer aussi
à créer une base
en fait à mon sens c'est un truc qu'il faut
essayer de faire assez rapidement
surtout si vous avez plusieurs équipes
de faire une base commune, de définir une manière de faire
encore une fois, c'est une histoire de communauté
pour qu'on soit tous d'accord sur les règles et une organisation
notamment dans les ripotériformes etc
pour que les personnes ne soient pas perdues
si elles vont dans un ripot ou un autre
et aussi capitaliser sur des choses
si jamais je ferai un exemple, vous devez intégrer
des secrets en utilisant vault
et vous devez les récupérer dans votre IAC
pour les injecter sur votre infrastructure classique
dans le cas là et de l'IAC
il y a peut-être 10 manières d'autre faire
mais si vous vous mettez d'accord
pour en fait utiliser une manière et par rôle
réinventer la roue à chaque fois, vous gagnez du temps
à mon sens c'est un phrase code aussi dans une grande société
il faut en profiter
pour essayer de structurer les choses, découper
faire des modules, les partager
et éviter comme ça de réinventer un peu la roue
pour moi ça c'est le premier écoil
de éviter de faire un peu chacun dans son coin
son saversion
d'un phrase code
et après le deuxième
on va dire le deuxième écoil
que je vois là dessus
ça serait
comment dire
ça serait tout simplement
de faire juste
de l'import
pour moi vaut mieux
repartir, par exemple je prends un exemple très simple
j'ai un lot de balancer un peu les gâchis
j'ai des machines derrière
si on parle de l'infras code
je préfère qu'on refasse un peu le tout
qu'on réfléchisse de voir à la manière dont ça a été fait
pour l'implémenter mieux, de manière plus propre
en profitant comme je disais de toutes les fonctionnalités
que juste faire
un lift & shift et récupérer ce qui a été fait
et faire globalement juste des imports
ce qui ne va pas forcément en beaucoup de valeur ajouter
tandis que si jamais on repart un peu
on réfléchit un peu à nouveau à la problématique qu'on avait
on peut potentiellement y répondre mieux
et avec des fonctionnalités en plus de ce côté là
en profitant de l'IAC
ça c'est le deux principaux écoils que je vois
je vous place sur de butons planches
on ne voit pas spécialement d'autres
mais du coup je passe la patate chaud dans
je vais rebondir très vite, je suis super d'accord
avec le deuxième point
qui est un point important c'est
automatiser ce n'est pas
faire de manière mécanique ce qu'on faisait à la main
c'est un point qui est extrêmement important
c'est pour ça d'ailleurs que souvent je fais la distinction
entre mécanisation et automatisation
alors Google ils font même une autre distinction
ils font une distinction entre automatisation et automatique
c'est pas la même chose
et donc en fait des fois il faut repenser
les contextes donc j'aime bien
j'ai plein de GIF animé comme ça de machine industrielle
qui font des choses, font quelque chose qu'on pourrait faire
à la main facilement et en fait ils sont obligés de repenser tout
de manière différente donc c'est très marrant de voir les machines industrielles
bah dans l'automatisation c'est pareil
c'est à dire quand on a dans l'idée que
nos machines vont spawner de manière automatique
de manière en scaling
bah notre application ne peut pas fonctionner pareil
elle doit souvent prendre ses configurations de manière différente
elle va fonctionner de manière différente etc
donc des fois c'est pour ça qu'il faut se repenser
un peu, faire un pas en arrière
et pas foncer tel dc comme ça
il y a un autre point qu'il faut faire attention
c'est de pas tomber dans le
dans le note inventive IR syndrome
donc c'est de se dire on fait tout en interne
on fait tout nous même, on sait mieux que tout le monde
comment ça va se passer
mais c'est de prendre des fois de l'expérience
extérieure justement pour pouvoir
apprendre des écueils
c'est très bien, on est là, on partage de l'expérience
c'est vraiment quelque chose de très bien
mais il faut pas croire c'est rarement
ce qu'il y a fait dans les entreprises
les entreprises aiment bien refaire elles-mêmes
avec leur type process et refaire leurs mêmes erreurs
c'est permettre de faire des taux que on fait ça fait un taux
comment on est passé à tel techno et ça fait un taux
pour qu'on en est parti, c'est le taux pour le prix d'un
donc c'est plutôt pas mal
et un autre point
alors là je suis moins d'accord là dedans
c'est
moi je vais dire l'inverse
en fait du premier point qui a été dit
c'est moi je vais dire plutôt essayer de ne pas trop
rationaliser, essayer de ne pas trop
mettre tous vos oeufs dans le même panier
mais la diversité c'est cool, c'est un avantage énorme
c'est que quand on fait des erreurs, le scope
d'erreur est petit
parce qu'en fait, faire de jolis paternes
c'est très bien mais en fait
quand on ne connaît pas très bien où est-ce qu'on va
souvent on se plante, on essaie de faire des
on aime beaucoup en France faire des très belles
ingénieries qui vont marcher
dans tous les cas
mais en fait
des fois il vaut mieux rester agile et dupliquer
ça c'est même une pratique de développement qui a apparu
récemment qui est de se dire dupliquer c'est
mieux que de centraliser
c'est à dire en fait au lieu de faire une librairie commune
à deux logiciels, on va copier le code
d'un côté et l'autre et chacun vont faire leur vie à côté
ce qui permet de
quand on a un problème
de le ségriger à un seul logiciel
et donc ça va être le cas quand on fait
des choses comme ça, c'est mettre tout dans le tout saisant
le même panier, ça fait du shitstorm at scale
et c'est ça un peu le problème du at scale
donc quand on avait des problèmes à la main
enfin il y a des gens qui avaient à faire du problème
à la main à at scale mais quand on n'a pas
le processus de matomatiser au moins
ok on faisait des erreurs mais on les faisait petits
quand on automatise on peut faire des erreurs
de manière très grosse et donc c'est pour ça que des fois je dis
non non dupliquer, refaites, c'est pas grave
apprenez et vous revenez
et en fait maintenant on a un outil qui est génial
qui s'appelle sed et qui permet
de faire des changements at scale dans du code
donc le jour où vous avez un problème
ou control shift F sur votre vs code
ou emax je sais pas comment en fait
et bah en fait vous pouvez changer du code at scale
et donc bah allez-y
enfin partagez après vos expériences
vos bonnes pratiques et partagez votre code
entre vous et voilà
et pollinisez en fait les pratiques entre
moi c'est plutôt ça moi
après si je peux juste
vous remercier de la dessus
non mais quand je disais ça
comme je disais je prenais l'exemple
c'est partage aussi la manière dont vous gère les secrets
des choses comme ça et quand je dis ça
je dis pas de faire un module central
l'idée aussi c'est de partager des bout de code
et se dire tiens ça marche bien
j'ai jamais mis les bons paramètres etc et potentiellement
si là où c'est important c'est de savoir
ce challenger entre vous et je pense
qu'il faut faire attention à des marches aussi du copier collé
qui est on va pas se mentir on fait tous un copier collé
on a tous été un jour sur Stack Overflow
dire putain ce bout de code il marche
c'est super cool mais dans l'histoire
le plus important c'est pas que ça marche c'est cool
c'est que le bout de code qu'on a copié on le comprend
et on sait le challenge aussi
je vous prends un exemple la dernière fois il y a
un si longtemps on m'a dit de
faire une petite infra un peu à la con si je veux
se dire dans le sens où c'était vm load balancer
j'ai mis un load balancer on m'a dit
bah tu copies code ce qui a été fait là tu récupères
ce projet c'est la même structure et j'ai commencé
à regarder un peu le truc et il y a plein de choses
qui à mon sens étaient challenger
donc par exemple le chiffrement
était mauvais c'était du TLS
encore 1.0 donc
truc qui est totalement dépassé donc c'était plein
de choses comme ça et en fait j'ai commencé à reprendre
un peu le code et à challenger tout ça donc faut faire
un peu juste attention à ça mais il y a effectivement un équilibre
à trouver faut pas non plus
essayer de tout
modulariser et arriver à quelque chose
qui est ultra abstrait au final on va être interdépendant
plein de choses mais il faut quand même savoir
partager en fait des bouts que soit par copier colléo
par module sur des petits trucs précis
tout en ayant vraiment cette vision et ça j'insiste
à dire ce que c'est important quand copie code
c'est de comprendre ce qu'on fait et surtout de pouvoir
de challenger pour dire ça j'aurais pas fait comme ça
et là aussi important de DevOps c'est
de pouvoir pinguer à mon sens la personne qui l'a fait
et dire tient tient t'as fait comme ça c'est intéressant
pourquoi est-ce que tu penses que ça serait mieux
ouvrir une PR et à un peu itérer
là dessus ou à c'était pour faire mais d'un petit
temps. Pistole tu veux
dire quelque chose ?
Ouais j'ai complété un peu
la première chose pour moi
c'est déjà de faire un état de vieux
des compétences surtout
en tout cas un état de vieux
des compétences éluissantes pour éviter
justement de choisir tout un tas
d'outils différents
et essayer de se donner sur ces compétences
du coup la rationalisation
et la mutualisation pour le choix
des outils ça peut être interdépendant
va avoir avec un outil qui font la même chose
parce que c'est un peu compliqué pour faire
passer les jambes, les balles ou d'un
projet à l'autre
et surtout plus important pour moi c'est
en début de projet de
citer des objectifs
et puis des objectifs intermédiaires
ne jamais oublier
de faire des petits bases, c'est-à-dire faire
des petites intérations, des
petites analyses de révoluer
pour nous donner
du temps, de l'entraîner
les nouveaux projets mais vraiment
de manière tout petite
on parle de l'eau de réaction
au début
et il n'était pas si
c'est à peu près une incrétion mais
s'il n'y a pas d'environnement différent
ça m'étonnerait le fait
de mettre en place des environnements
avec le renfrage code commencé par le premier environnement
plus de diamènes et d'alcools, pégines,
faire de propres et d'alcools
et puis surtout
pendant toute la nuit des projets
mettre en place des points de partage, des boutons interne
des vidéos
peut-être créé dans le casque d'un certain je ne sais pas
mais il s'agit de la
connaissance et que l'expérience
de mettre
notre entreprise et par le fait que
cette équipe
a vraiment de la façon pour vraiment
mettre en place une culture commune et une culture
des choses
Super, un grand merci
à toi parce que tu as intervé en remote et c'est pas forcément évident
merci de faire le switch
de casque et de vous
merci pour les réponses
toujours dans le chapitre
transformation, j'ai plein de questions
donc
est-ce que vous avez une organe des SITI
pour faire du DevOps
je vous explique un petit peu l'organe ici
on a des équipes plutôt transverses
qui s'occupent de tous les sovres
administration system, administration base
de données, réseau etc
on a des équipes transverses qui s'occupent de la responsabilité
de la prod
et puis on a des équipes projets qui aident son focus
pour le build
les applications ou l'implémentation de projectiles
donc une organe relativement tradite
pour une entreprise de cette taille
est-ce que vous avez des organes qui vous semblent
plus pertinents qu'on met en place du DevOps
Guilem
ouais bah
les choses ou bien en fait
ouais ouais je vais essayer de pas trop trop les
enfin en tout cas je ne te rends même pas ça je le pense vraiment
non mais c'est vrai que le problème
qui va y avoir c'est que quand on a une structure
en fait les structures
historiques ont été conçues
pour optimiser les ressources
c'est à dire de se dire que si on a
5 projets mais qu'on a besoin
que de 3 testeurs
et ben comme ça on crée une équipe de test
c'est super c'est qu'en fait comme ça
on lui envoie 5 projets et j'ai pas besoin
d'embaucher trop de monde j'ai optimisé
les ressources exactement par équipe
et donc en fait toutes les entreprises
se sont créées comme ça
donc c'est pour ça qu'on a des développeurs
des testeurs des supports etc etc
et qui sont cross-projects
et donc en fait
on va avoir des interdépendances mais
c'est pas parce qu'on a en fait
c'est pas parce qu'on a besoin de 3 testeurs
sur l'année que en fait ça va bien
marcher parce que peut-être qu'en fait tous les projets ils ont besoin
de tester en même temps et en fait c'est pour ça
que le devops est apparu en se disant
ben en fait la principale
chose qu'on va essayer d'optimiser c'est le temps
de mise en production c'est ça
en fait la logique première de
l'agilité du devops
et on peut être contre cette philosophie
mais le but c'est
d'aller vite dans la mise en production de la valeur
et donc dans sa correction
si jamais il y a un problème et donc ce qu'on s'est dit
c'est qu'on va complètement bouleverser l'architecture
on va la passer d'une architecture
vraiment par étapes à une architecture intégrée
ou
ben si on a 5 projets on a 5 testeurs
il n'y a pas une équipe transverse de test
ce qui va permettre aux testeurs d'être
ok on a en fait un surplus
parce que les testeurs ça ne sont pas occupés tout le temps
mais le jour où on a besoin
la ressource est disponible instantanément
si vous avez fait du microprocessor
c'est exactement le problème de la contention
dans un pipeline
c'est ben en fait
on essaye de mutuel, de multiplexer
les usages en ayant plusieurs coeurs
qui seront peut-être plus petits etc
mais quand le besoin est là instantanément
j'ai pas une latence
à l'accès à une ressource et en fait ça c'est quelque chose
et on s'est aperçu en fait qu'on a besoin de plus de monde
mais en fait on s'est aperçu que tout le monde était plus efficace
donc en fait on a plus de monde
mais qui délivrent plus que avant
et beaucoup plus même que avant
parce qu'on n'a pas ce temps
de contexte switching
enfin on utilise vraiment quelque chose qui est comme dans un processeur
donc ce switch de contexte où je fais une features
et en fait il y a quelqu'un qui me dit 2 mois plus tard
en fait elle ne marche pas
et donc je reviens sur ma branche
elle a divergé énormément etc etc
et en fait là non on a quelque chose avec une boucle
de rétroaction qui est extrêmement rapide
donc en fait l'organisation elle se forme un peu
par petit projet et c'est moi ce que j'ai appelé
parfois la start-opisation
je n'ai pas de gros termes mais je n'en ai pas d'autre
la jeune pulsation
des gros entreprises en se disant
j'ai des petites entreprises en fait
à l'intérieur de ma grande entreprise
ma grande entreprise devient une tente qui héberge en son
simple un de projets qui ont leur propre vision
et ça aussi c'est parce que
on s'aperçoit que plus une équipe est grosse
et moins elle devient performante
et donc là ce qu'on va faire c'est qu'on va essayer d'avoir un trade-off
en trouvant le juste équilibre
avec un projet de 20 personnes
on va dire je dirais un chicropif mais il faut le trouver
par contexte, par projet
pour faire en sorte que toutes les personnes soient les plus efficaces
en leur sein donc en fait on se retrouve à avoir
des projets horizontaux
vraiment énormément avec une tente par-dessus
et en fait ça marche très bien dans le monde
les start-ups arrivent très bien à fonctionner dans le monde
pourquoi ça ne marchera pas aussi en les entreprises
et donc c'est vraiment un changement de paradigme
on va essayer d'optimiser le temps de déploiement
à tout prix et donc en multipliant
les ressources donc c'est pour ça qu'encore une fois
il faut aller voir les gens des ressources humaines
et du budget en disant
il faudra peut-être embaucher plus de gens
mais on sera plus rapide
et c'est tout un problème souvent
de ce genre de contexte-là
Christophe, tu voulais rebondir
exactement
parce que ça va vraiment dans le sens
ce que je voulais dire
moi je suis un grand réflexeur
des équipes curélycipulaires
par projet
ça veut dire que dans une équipe projet
on doit avoir des développeurs
des testeurs
des start-ups
des administrateurs systèmes
ou des administrateurs planformés
ça dépend du projet
qui est en train d'être mené
pour justement que les
piffes soient complètement autonomes pour que je reste en projet
du début jusqu'à la fin
c'est-à-dire que les commissions
le projet n'existe plus
donc toute la durée du projet
c'est-à-dire que je suis très très fan
du projet
qui nous build
qui nous concluté l'application
vous l'exploiter en fait
et je pense que c'était
une très bonne
manière s'organiser
dans les grandes boîtes
je l'imagine bien
j'ai pas vu mais j'imagine bien
des équipes curélycipulaires
se reposer sur d'autres équipes
un peu plus transverses
qui vont les supporter
comme
les équipes qui vont gérer tout le cloud interne
donc les équipes qui vont gérer toute la forme musicale
ou des équipes de MLD
qui vont fournir des brides
que vont pouvoir utiliser les équipes de projet
et là peut-être qu'on peut retrouver
cette transformation tant évidemment
retrouver la
utilisation
de la source dont on parlait hier
par contre j'attire
moi je ne suis pas
certain que l'utilisation
des ressources
va vraiment efficace parce que
on se trouve toujours en tout cas
en fait il y a des services
immutualisés mais les personnes
elles switchent le projet en problème
et le fait de plus petit à projet à l'autre
ça nous va faire énormément de temps
et je suis pas certain qu'en fait
avoir des services spécialisés
nous fait gagner plus de temps que ça
par rapport à une équipe curélycipulaire
qui ne s'occupe que d'un projet
et qui ne change pas d'un projet autre
je veux juste
juste un petit expérience
pour ça qui est contraint intuitive en fait
en fait c'est pour voir que là on parle souvent de biéconitif
en fait là-bas on croit que quelqu'un de spécialisé
va être meilleur qu quelqu'un de non spécialisé
et l'expérience qu'on fait souvent dans des ateliers
c'est on demande à quelqu'un de faire
mettre une lettre dans un enveloppe
et donc ça se passe en 3 étapes
c'est plier la feuille, la mettre dans l'enveloppe
et coller et on demande à des gens
de le faire toutes les enveloppes
les plier, les plier, les plier
mettre les enveloppes et les coller
ou on demande à des gens de faire les 3 à la suite
et on regarde combien de temps ça prend
et c'est celles qui font toutes les étapes
à la suite et en rebouclant
qui font le moins de temps
et ça c'est contraintuitif, on a vraiment l'impression
qu'en faisant les choses, tout le temps la même chose
on va être plus efficace
et en fait non le cerveau humain est pas vraiment conçu pour faire ce genre de choses
par contre l'automatisation
ça fait super bien
un ordinateur le fera extrêmement bien cette tâche compétitive
je suis du coup
pour rebondir un peu sur tout ça
je suis plutôt d'accord sur l'idée des équipes purilisciplinaires
dans le sens où
ça réduit aussi un peu la latence
on a tous connu le cas où par exemple
vous avez une équipe qui va fournir
un accès
au ripot d'artefact
vous allez pouvoir pousser derrière
vos images ou à vos pins maven
et du coup dans le cas là
vous allez ouvrir un ticket, vous allez potentiellement attendre
si jamais vos accès ne marchent pas
il faudrait ouvrir un ticket, il faudrait voir avec la personne
tout ça ça crée de la frustration
parce que c'est chiant
personne s'amuse à dire que j'ai ouvert un ticket c'était trop bien
franchement meilleur journée de ma vie
deuxième truc ça crée de la latence
parce que vous par exemple vous allez lire au stand-up
vous allez dire que j'ai ouvert un ticket et j'attends
moi ça peut être très frustrant
tandis que si vous déportez ça et vous avez des personnes dans les équipes
qui ont des compétences
vous allez gagner en fluidité
vous allez gagner en temps là dessus
il va aussi pouvoir challenger vos contextes
pour certains plus sur des produits bancaires
d'autres plus des produits d'assurance santé
donc des contraintes ne sont pas les mêmes
donc aussi cette connaissance c'est fiant du contexte qui est super importante
et après pour moi
en ce qui concerne un peu les équipes transverses
c'est important, il y a des outils qui à mon sens
sont du sens à être un peu transverses
je pense de tout à l'heure on ne peut pas vault
il n'y a pas forcément de sens à ce que chaque équipe
maintienne sa stack vault
avec la sécurité qui va d'ar et tout
parce qu'on sait il y a forcément un endroit où ce ne sera pas mis à jour
d'autre où finalement on a désactivé
les chiffres de ça parce que c'est un peu chiant
donc du coup tous ces outils là en fait
pour moi elles doivent passer dans des autres features team
qui vont être au même niveau que les autres
et qui vont fournir des outils aux différentes features team
donc il faut vraiment voir que ces équipes transverses
pour moi vont devenir des équipes projet à part entière
qui vont fournir ce qu'on disait un peu de tout à l'heure
des outils d'infrastructure
par exemple vous allez en équipe qui on va
et je sais pas équipe forge qui va fournir
je prends un exemple après
c'est adaptable mais qui va être responsable
de fournir un artefactorie, un vault, un console
et derrière va pouvoir fournir les accès aux équipes
un peu en mode self service
ce qui fait que ça va créer moins de frustration
et en même temps on va quand même profiter
d'avoir des...
une stack entre guimesses solides et maintenues
et de voir maintenir la même chose en parallèle
des fois des... un projet s'il a besoin
d'imagerons de stocker un secret de base de données
un secret... deux autres secrets
pour le cloud et des tokens applicatifs
ça vaut pas le coup de monter un vault
juste pour ça donc là c'est quand même
des briques qui ont tendance à...
à mon sens on du sens entre guillemets
à être mutualisé par une autre équipe
mais faut vraiment qu'elle voit ça plus en mode produit que transverse
parce que ça fait perdre aussi de la responsabilité
par exemple d'avoir une équipe qui s'occupe
de toute la maintenance
c'est ce qu'on disait, demain vous déployez quelque chose en prod
la prod essaie de bien passer toutes les verbes
votre cheveux qui sont basiques sont ok
tout le monde est content mais là vous vous rendez compte
qu'en fait ça génère plein d'alerte
des flaps ou des choses sur le monitoring
qui ont pas de sens mais vous allez moins le ressentir tout de suite
donc ça va un peu
changer à mon sens la manière de gérer le problème
donc là où c'est intéressant
du coup c'est que si vous gérez notamment avec le
youbois dit you run it
vous allez pouvoir le remarquer plus facilement
et pouvoir améliorer les choses grandement
donc voilà un peu...
aussi on comprend c'est super pour ça quelque chose
dans la structure de DSI, surviens la question initiale
dans la structure de DSI
il y a même la structure
d'évolution et la structure de paix
parce que à un moment on part d'argent
et en fait
dans ces structures là quand on est en mode projet
davantage on a dit on mesure
et appartientement on mesure
ça veut dire qu'on peut s'améliorer
parce qu'on améliore que ce qu'on mesure
et donc ça veut dire qu'on peut avoir
un incentive, on peut avoir une notion
de budget et
d'amélioration par rapport à ça
et donc on peut donner des objectifs de manière claire
simple qui sont mesurable
et pas juste il faudra
améliorer la communication client, non là c'est
comme on a dit par exemple sur le vault, comment on passe
d'un stade où on envoie un ticket
et peut-être un jour on a les accesses
en artefactorie par exemple, là non on a une équipe
artefactorie qui est
on peut mesurer le temps
de création des API, le temps
d'amélioration et tout et
toute cette équipe
de développeurs parce que souvent quand c'était juste des ops
qui géraient l'artifactorie ils disent bah ouais mais moi
je sais pas développer une API donc je sais pas faire
mais là non leur produit c'est par artefactorie
c'est pas la technologie, ils vont être l'équipe
forge ou l'équipe ceci
et donc elles vont choisir une technologie un moment, elles vont avoir
une API devant qu'elles vont développer
et qu'elles vont pouvoir s'améliorer et peut-être d'ailleurs
changer les produits donc en fait
cette équipe devient pourquoi ça devient
une équipe autant long parce que ça va être une équipe
qui va gérer la forge, même si il change de technologie
ça doit être un peu transparent pour les utilisateurs
et ils vont pouvoir s'améliorer
et donc on va pouvoir mesurer ça et donc après
il y a la notion vraiment de budget qui vient avec ça
et qu'on peut
mettre en comparaison ça veut dire
on attend d'utilisateurs qui utilisent tel projet
et donc ça correspond à tel budget
qu'on va pouvoir injecter et
les personnes se sont améliorées, elles ont fait
un bon travail, elles ont amélioré toute la boîte
je peux le mesurer, je peux donc donner un budget
associé à ça, aussi bien en termes salariats
de primes, de nouvelles personnes
à mettre dedans
et on retombe sur ce qu'on disait tout à l'heure et ça c'est beau
j'ai une question complémentaire
qui n'est pas posée par l'assemblée mais qui rebondit
sur votre question, c'est
donc dans vos interventions vous préconisez
pas mal des équipes plus sur plus
de projets
et donc éventuellement
diluer dans ces différentes équipes
dès que les compétences jusqu'au présent étaient resserrées
dans des équipes spécifiques
mono compétences
je caricature un peu parce que vous avez à parler aussi
d'équipe transverse
en support etc mais fondamentalement
donc on va dire
vous avez des SRE qui sont projetés dans les équipes projets
la question c'est comment est-ce que vous capitalisez
votre expertise quand
les compétences sont diluées
dans des équipes
dans lesquelles ces expertises
ne se
n'ont pas d'émulation
ça je rebondis
là dessus
du coup c'est vrai que ça c'est
une grosse problématique c'est fait en si les SRE
il faut qu'il soit dans chaque équipe avec le contexte
c'est pas pour autant qu'il faut qu'il soit isolé les autres SRE
donc c'est là où il y a plein de modèles
qui un peu à bord de ça niveau organisationnel
mais à mon sens il faut créer vraiment et c'est ce qu'on a déjà dit plusieurs fois
un esprit de communauté
où il faut que les gens puissent échanger
que ce soit en ligne avec des chats
ou des choses comme ça
et pour pouvoir du coup, comme on le disait
partager du code
pouvoir potentiellement aussi avoir du temps un peu banalisé
pourquoi pas se dire une demi journée par semaine
je suis pas dans mon équipe je suis avec les autres SRE
on voit un peu ce qu'on a fait
on remet peut-être en question aussi certaines approches
donc il faut arriver vraiment à créer cet esprit
de communauté transverse
en plus de l'équipe et ça c'est un petit chose qui est pas simple à faire
c'est-à-dire que globalement on est dans
deux équipes, si je casais 4 heures, on est dans notre équipe projet
et on est un peu dans notre équipe SRE
mais c'est quelque chose qui se fait
il y a des modèles, comme modèles Spotify qui l'abordent
et qu'il faut arriver à ritualiser
si possible
pour un peu que tout le monde soit dans la même dynamique
et puisse échanger là-dessus
il faut que ce soit aussi à synchrone, il faut prendre l'habitude de
tiens j'ai fait ça aujourd'hui
soit j'en parle dans une semaine, quand on se voit
soit je fais un bout de doc et je le partage sur le chat
dans un tonnerre j'ai fait ça si quelqu'un a une idée
et là on revient sur ce que je disais tout à l'heure
dans l'idée d'un autre SRE
ça fait attention, tu fais ça tu auras un bottleneck
attendre connexion etc mais cette option
donc c'est là aussi après tout l'interdit
etstof tu veux rebondir ?
ouais
en fait dans les cinq épisodes
c'est en arrière qu'on oublie un petit peu
maintenant c'est de la culture
c'est-à-dire que
il y a celui d'Arnaud Zé, le chef
il est partage en fait
et il est très important
dans une entreprise et même dans une entreprise
de partager comme je le disais
de partager
pour un des fondements
du déloyage
parce que l'étude pour les disciplinaires
ne va pas être tout simplement pour moi
sinon elle va perdre en capacité
d'évolution
elle doit partager avec les autres équipes
donc le LTA
il doit partager avec les autres ops
via les meetups interne
des formes de metup interne
des meetups esternes
mais l'idée est d'en rencontrer
pour une boucle d'avionration continue
et des pratiques de l'entreprise
et de ses propres pratiques et compétences
donc je ne dois pas s'inspirer
juste à informer une équipe de disciplinaire
on doit encourager que les gens
de s'informer
qui vaient de partager
les bénéfices et les essaisques
parce que les peuples verts
vont évouer les autres mondes
de l'entreprise
qui n'apparaît à juger les filles
oui je suis entièrement d'accord
donc je vais essayer de parler d'un autre point
souvent on sait
la peur c'est de se dire
j'arriverai pas à trouver des compétences etc
ce qu'il faut voir c'est que
en fait les entreprises partagent un marché commun
qui est celui des ingénieurs
qu'on va mettre ou des développeurs
c'est
de se dire que quand on a des équipes
des compétences qui sont un peu réparties
l'avantage c'est qu'on a accès
à des bassins d'emplois
qui sont plus élargis
c'est à dire que si je suis sur des technologies différentes
dans des bassins différents
je vais pouvoir avoir accès à un pool de personnes
plus importants
c'est un point à prendre en compte
de se dire que c'est un avantage
de se dire on va pouvoir avoir des ops
que j'ai travaillé par exemple pour la française
des jeux qui doit être à peu près organisé
comme les MGMN
je connais pas tous les détails
mais à la française des jeux
on a une équipe à vitrôle qui est la prod
une équipe à boulogne qui sont les développeurs
et voilà le problème c'est que
au bout d'un moment
le bassin d'emplois à vitrôle il est ce qu'il est
et on a un peu fait le tour et donc c'est dur
de trouver des compétences nouvelles
là aussi jamais il y avait des développeurs aussi à vitrôle
des ops aussi à boulogne
et ben on a une pollinisation comme ça
et on peut aller trouver plus de compétences différentes
et c'est d'ailleurs un point extrêmement important
à faire quand on parle de...
j'ai eu des expériences comme ça de rationalisation
trop importante
d'entreprises comme
je vous le disais
puisque c'est assez public c'est par exemple Critéo
qui a une stack technique entièrement dotnet
aujourd'hui
trouver des développeurs dotnet sur Paris
en fait ils sont tous déjà passés par Critéo
donc en fait leur rationalisation fait qu'aujourd'hui ils n'ont plus de développeurs
et c'est extrêmement dur pour eux
parce que les gens sortaient d'école n'ont pas de dotnet
n'ont pas fait de dotnet donc pas cette expérience là
tout ce qui était bon ne pas fut passé par là
et donc même d'avoir de la diversité
géographique de personne
et de technologie
permet de challenger les technologies entre elles
de voir les réussites et les malus
et de se dire c'est pas grave
d'avoir de la diversité
et aussi de pouvoir avoir des bassins d'emplois différents
et donc de pouvoir recruter plus
et c'est ça aussi la chose importante
on a l'impression qu'en ayant une monostache
c'est plus simple de recruter c'est souvent l'inverse
et en ayant plus de technologie
on a avec ça un plus de gens
différents qu'on va pouvoir embaucher
et recruter
ok
toujours dans le chapitre
de transformation
désolé pour le son
toujours dans le chapitre de transformation
combien de temps pour mettre en place du dévost
alors il nous reste 3 quart d'heure
donc évidemment
cette question là elle s'adresse plutôt
à un contexte d'entreprise tipemgn
évidemment pas start-up
essayez de faire des réponses courtes
il nous reste 16 questions
on les aura pas toutes
essayez de faire des réponses courtes
malgré tout
donc en combien de temps
on transforme l'entreprise
pour qu'elle fasse du dévost
qui veut se lancer sur cette question
quel que l'école ?
pour moi c'est un temps infini
c'est à dire c'est un symptotique
vous ne serez jamais entièrement dévost
c'est une progression
et vous allez atteindre le dévost
et sur ça d'ailleurs que je vous conseille
j'ai créé un inframort qui s'appelle Mepi
Mepitisi
qui permet seulement que vous évaluez
votre progression vers le dévost
et je pense même que les plus grandes entreprises
des goûts de gueule
nous clairement pas atteindre
le stade ultime du dévost
surtout de gueule d'ailleurs
ça sera quelque chose, ça sera une amélioration continue
vous dites pas que du jour au lendemain
en mettant tant d'argent sur la table
c'est bon on sera dévost, non ça sera quelque chose
de continue dans le temps et d'amélioration progressive
du coup
c'est vrai que ça ne se fait pas
je pense pas que c'est une question mais une réponse
en mode ouais ça fait 2 ans 7 mois
donc c'est ça, il n'y a pas vraiment
de réponse figée
et je suis d'accord sur le fait que c'est quelque chose
qu'on va toujours en s'améliorant
donc on peut se dire si on met des mines zones par exemple
je sais faire la cd donc déployer
de manière continue, des applications en production
totalement automatiquement sans qu'il y ait d'actions humaines
si on se met des milestones de ce type là
on va pouvoir mesurer
et c'est en là
j'ai pas de réponse magique
ça peut prendre
2-3 ans, ça peut prendre 10 ans
parce que ça dépend
c'est simplement à mon sens de beaucoup de l'humain
et en fait l'humain on a tous nos rythmes
nos façons de penser, certaines personnes vont changer
tu leur dis on passe au DevOps
lundi d'après
est-ce qu'on déjà a fonds en DevOps
avant d'apprendre des trucs et à des gens il va leur falloir plus de temps
pour s'adapter, comprendre pourquoi on fait ça etc
donc plus qu'il y a de l'humain
et que en plus c'est de l'amélioration continue
pour moi il n'y a pas de réponse en temps
magique c'est un peu réponse de norme
mais c'est à mon sens ta réponse
alors que tu es le meilleur de soi
je suis Lorin mais oui pas de messe
Christophe, tu veux répondre
à cette question casse gueule
oui je suis assez d'accord avec ce qu'il a bien dit
en plus ça dépend tout de pourquoi on part
avec les connaissances qu'on a
et dans les connaissances pour moi
ça peut être très mou
c'est rare pour
renseignement
les groupes que vous en avez pour vous montrer
plusieurs zones
moi je sers sur le fait que
en effet c'est la meilleure
chose continue mais il faut vraiment pas
s'arrêter au petit début c'est à dire souvent
en fait je vois des entreprises qui
veulent pas se développer et qui t'arrêtent
en fait en me mettant dans la paratouche
qui s'arrêtent au 20% d'actions
qui le rapportent le plus c'est à dire
en même temps que le déploiement continue
et puis en général elle s'arrête là
et elle ne continue pas
elle continue à faire ce tueur de leur organisation
et vraiment des VOPs
que je l'avais dit bien
c'est un virus continue tout le temps
et c'est d'accord
ça doit vraiment être arrivé en fait
toutes les personnes qui participent à l'instant de trôte
et t'aimeraient de continuer pour atteindre les objectifs
qu'on ne pense même pas à l'origine
et au début de la transformation
mais on ne vous aurait pas de résultats
en peu de temps
faut bien prendre en compte
que c'est un arrestissement
sur l'avenir faire un panso des VOPs
ça coûte cher, ça prend du temps
mais c'est un arrestissement sur l'avenir
parce que ça va vous donner un avantage
sur un rapport à vos procurements
et ça vous donnera d'avantages concurrentes
parce qu'en plus d'enfance
on le fait la plupart des entreprises
qui ne sont pas passées au déploiement
alors justement
comme tu parles de ces coûteux
etc.
il y a la question jumelle qui vient
qui est comment on mesure le héroï
du dévoce
ah qui veut se lancer ?
j'ai une réponse facile encore à ça
parce que j'en ai déjà parlé avant
le dévoce c'est l'amélioration
du temps de mise en production
d'une idée
donc en fait c'est simple
vous prenez combien de temps
aujourd'hui vous mettez entre l'idée
et ça mise
clairement
en production
et vous mesurez ça en continu
et si jamais ça baisse
c'est que vous y arrivez
et c'est que vous vous améliorer
et c'est ça ce mécanisme d'amélioration continue
donc si jamais un jour vous arrivez
dans votre application mobile
à avoir des fonctionnalités beta
en feature flag pour certains clients
vous faites de lab testing etc
vous avez commencé à bien faire les choses
alors ça c'est plus
une question d'indicateur pour le retour sur investissement ?
ben justement
le retour sur investissement
en fait dans le dévoce on considère que
en tout cas c'est aller vite
c'est
c'est ça le retour
le but c'est d'aller vite
après on verra ce qui se passe
il y a un effet magique que quand on va vite
on a des choses qui vont mieux
mais c'est quasiment philosophique
il n'y a pas de preuve formelle
que l'agilité fonctionne
on a vu que ça marchait
alors que par exemple la méthode en V
donc on sait que si on la fait bien
c'est la meilleure méthode qui soit
avec la méthode en V on a fait des bombes atomiques
et c'était comme ça qu'on l'a conçu
le truc c'est qu'on s'est aperçu que
à part quand on fait des bombes atomiques
ça marche pas très bien
et d'ailleurs un point qu'on a oublié
quand on a fait de la méthode en V pour les bombes atomiques
c'est qu'il y avait 3 projets en parallèle
c'est à dire que l'état américain a financé
dans le projet Manhattan 3 bombes différentes en même temps
pour les concurrencer
donc en fait c'est 3 fois plus cher qu'une seule projet
c'est aussi ça qu'on a oublié quand on a fait la méthode en V
c'est qu'il faut avoir des sphères au chaos
et c'est pour ça qu'on a 3 bombes différentes
en fait c'est très nity, fat man et little boy
qui veut rebondir sur
sur l'art glumon nuclear
Christophe ?
oui alors les art glumon nuclear peut-être pas
mais je voulais rebondir sur
les indicateurs en effet
quand on mesure le retour de surinvestissement
je vais essayer d'aller de l'île
et me mesurer en fait
le pendent n'est pas moins
je vais vous envoyer un rapport d'orac
un rapport qui est sorti en l'année en fait par google
qui a un rapport sur étal d'art
qui a un débat sur
une manière primitaire
et en fait il n'y a pas de gros indicateurs
qui est à la fréquence de l'épreuve
le temps qu'on met
pour faire le changement
c'est ce qu'il y a
le temps qu'on met pour rétablir le service
ça c'est un temps qui est important aussi
quand on fait du débat
le temps va à tendance à baisser
c'est à dire que le temps d'intervention
et le temps de révolution
est plus faible
et surtout
le tour du débat
plus on va
aller faire le débat c'est moins
plus on va éliminer
une grande partie de l'intervention humaine
et tous ces indicateurs
vont nous permettre de défier
à rapport sur un résultat
en fonction du budget
qu'on a mis en face
et du faible tour de débat
l'accélération de déploiement
et donc la carte d'ascente
pour nous de l'envers
ça va nous donner un rapport sur le rétablissement
il faut le calculer
il faut le voir
ce que je propose avec l'expérience
c'est de prendre ces indicateurs
et puis aussi des indicateurs humains
là c'est donc un point de vue
du retour sur le rétablissement
mais on limite le temps de révolution
grâce aux déblocks
c'est aussi un bénéfice pour l'entreprise
du coup
c'est d'accord à ce qu'il y a déjà été dit
à mon sens
il y a juste une chose
c'est que là on parle d'indicateurs
de comparer des indicateurs et tout
souvent c'est compliqué d'avoir des indicateurs
de avant le DevOps qu'on pense à mettre pour le DevOps
mais il faut pas oublier avant le DevOps
de mesure aussi ce qui s'est passé
pour comparer sinon ça a pas beaucoup de sens
c'est ça qu'on oublie souvent
et on se rend compte trop tard
on dit avant on mettait combien de temps pour déployer en moyenne
donc faut pas oublier ça
et je rajouterai peut-être juste
une dernière chose
mais ça dépend vraiment des domaines
mais on a vu aussi que le DevOps aujourd'hui
c'est quelque chose qui est le time to market
donc le temps qu'on va mettre à s'adapter au marché
ça va être quelque chose aussi qui peut sauver l'entreprise
je prends un exemple très simple
c'est le marché des sites de rencontres
c'est un marché qui était ultra classique
où tous les sites avaient le même système
avec pages de profils, messageries et c'est bon ça marche
tout le monde était bien content, fonctionné
on pouvait faire du cycle en v, de toute façon le produit n'évoluait pas
il y a un jour, il y a Tinder qui est venu
ils ont perdu les 3 quarts de leur client
la moitié ils étaient en mode soit je m'adapte en quelques mois
parce que c'est ce que j'avais à burn en argent
en attendant, soit je mets la clé sous la porte
pour certains business ça a été clairement
une question de vie ou de mort
et il y a des entreprises qui ont arrivé à survivre
parce qu'elles ont su s'adapter au marché
parce qu'elles ont su s'adapter, sortir des nouveaux produits, des innovations
et pouvoir répondre aux nouveaux besoins
qui avaient été créés par une entreprise
et c'est ce qui se passe notamment dans les marchés industrielles
avec des entreprises comme Tesla
qui viennent de changer des partis
et les autres entreprises sont obligés
un peu de rattraper leur tarve, on le voit bien
où il y a beaucoup de cycles un peu plus longs en v etc
dans l'automobile et dans l'industrie en général
où ça prend beaucoup plus de temps et on voit que c'est des situations délicates
donc ça peut
le calcul ROI est très compliqué
mais bon ça peut sauver l'entreprise
dans beaucoup de cas donc
c'est toujours un bon investissement
il nous reste une demi heure
on a encore quelques questions de panse-faux
mais on va les laisser pour plus tard
on va passer un autre chapitre qui est le chapitre
la responsabilité
ça vous chauffe hein
alors attention, qui donne le go pour une mep
dans un monde DevOps ?
les tests en CIA
donc dernier on a pris la main
attention, Daniel se détache
si les tests automatisés sont bons
en soi
ça dépend du produit encore une fois
si on parle d'un produit qui va être
nucléaire ou autre
c'est pas la même chose ou même une application bancaire
on peut consulter le solde, ça peut avoir beaucoup d'impact
mais pour moi la plupart des tests
doit être automatisé donc à partir du moment où tous les déploiements
dans les différents environnements de tests
sont bons, les tests sont bons
on doit pouvoir déployer en production
le plus important c'est que le go en soi
on peut en louper des erreurs
on peut prouver avec les tests
faut prouver ça, on peut prouver qu'on n'a pas vu d'erreur
mais on peut pas prouver qu'il n'y a pas d'erreur
il faut savoir justement y tirer là-dessus
si vous trouvez une nouvelle erreur qui n'a pas été détectée dans les tests
faut rajouter ça dans les tests et incrémenter là-dessus
et à mon sens il faut
mettre en production
utiliser des moyens de production potentiellement
en faisant du progressif déploiement
tout les trucs comme ça
et pouvoir surtout le plus important
être capable de rollback si jamais il y a des erreurs
si jamais il y a des problèmes
mais pour moi à partir du moment où la CIA
donne tous les tests ok et tous les environnements sont ok
on doit pouvoir lancer la mise en prod automatiquement
sur les produits aujourd'hui
Guilem, tu veux me rembourser ?
Oui non je suis assez d'accord, cette notion de test
elle a un gros intérêt
c'est qu'elle enlève cette partie risques humains
et il y a quelque chose après qu'on pourra acheter
c'est à partir du moment où on sait
que la mise en prod va être automatique
et bah en fait
il y a un deuxième effet qui se coule
qui arrive c'est qu'on peut se dire qu'on a du feature flagging
c'est à dire qu'on va séparer
la mise en production
de la release de la fonctionnalité
et en fait
si jamais il y a des tests au pas, si l'application ne plante pas
on la met en prod
et en fait on va avoir quelqu'un du business
qui va activer une fonctionnalité
qui est présente dans le code
mais juste désactiver sur le moment
ça va permettre comme ça
d'avoir toutes les fonctionnalités en prod
même des bétards
et de les activer pour le business
au business va dire bah regardez
ils vont tester, ils vont faire la recette en production
parce qu'il n'y a pas quelle production qui ressemble à la production
donc en fait on fait des recettes en prod
et on arrive même à un point
où pour vous dire chez Google
les tests des développeurs
le développement est fait en production
il n'y a pas de plateforme de staging, de test
ou je sais pas quoi
il n'y a que la prod qui ressemble à la prod
donc on fait tout en prod
et s'il y a un problème c'est qu'il n'y avait pas le garde-fou
qui allait bien
et donc on va rajouter des systèmes de feature flagging
où on va faire en sorte d'activer la fonctionnalité
un point important à ça qu'on voit souvent
moi j'ai travaillé chez d'V-Commerce par exemple
et bah quand on est au moment du Black Friday
le Black Friday il commence par exemple à 23h59
et bah là en fait on n'a pas forcément envie de déployer
toute la prod à 23h59
parce que comme c'est le lancement du Black Friday
on a envie que ça marche avant
mais ce qu'on va faire c'est qu'on va déployer le site
avec la fonctionnalité Black Friday
plusieurs jours avant
on va demander à plusieurs personnes dans l'entreprise
de tester la fonctionnalité, elles vont activer un flag
ça peut être un cookie, ça peut être un header
ça peut être le nom d'un utilisateur
il y a plein de façons de faire de feature flagging
et elles vont tester la fonctionnalité
et si ça plante, et bien on me voit instantanément
il y a un taux d'erreur qui est monté
on peut faire les ajustements etc
mais on va décoréler la partie déploiement
de la partie fonctionnalité
et ça permet un point extrêmement important
qui est que dans l'agilité
il nous faut donc cette boucle de rétroaction rapide
et bah on veut pas faire le code
mettre une PR
attendre que quelqu'un du business
valide la fonctionnalité pour enfin pouvoir la fermer
et avoir notre burn chart
sur notre agitée qui soit beau
non, on a codé la fonctionnalité, on la déploie en production
on va les désactiver, quelqu'un la testera
et on y tira, on va y térer dessus
et donc c'est pour ça que c'est important
d'avoir quand on a cette paraffin de test
de se dire, ah bah on a un autre fonctionnement
qui va nous permettre d'ajouter de la valeur
de manière rapide et donc
et ça si vous avez sur Google, enfin Google
utilise ça tout le temps, vous allez avoir même 2 personnes
qui ont utilisé la même application, n'auront pas les mêmes fonctionnalités
parce que certains auront eu un flag d'activer
automatiquement et pas d'autres
et donc on va comme ça avoir un rolling update
c'est pas parce que vous avez mis un jour
une application Google que vous avez la dernière fonctionnalité
il faudra attendre qu'un flag s'active
Christophe, qui donne le groupe
pour la mette chez toi ?
Oui, je récrocre
à l'entrée un petit peu tout ce qui a été mis
parce que c'est plutôt réservé à des études très inventées
parce que dont l'un de les lèvres c'est ce qu'on appelle
des features flags et tes équipes ne peuvent pas
faire ça
à dix personnels, il y a peut-être que
il y a mon expérience, il y a des trèques très gros
pas, j'ai des exploits très grands
des grands groupes
il y a le fait d'avoir des déploiements continus
dans tous les environnements hors production
c'est-à-dire dès qu'en effet
la délit et la mer de l'équaisse
évaluée
pour font des fois
des jinx et peut-être en préproque
ça se montre
que pour le déploiement de proc, ça reste pour moi le métier
qui décide de quand on va déployer
parce que
c'est lui qui a l'information
ça je voudrais que ce soit déployé
quand elle date ou en effet
nous on a fait des tests, on a bien pris en main
d'une bonne fonctionnalité pour qu'on ramile
et on voit ça
sur la prod
mais le déploiement reste tout pratisé
ça ne veut pas dire qu'on va le faire à la main
c'est juste qu'on appuie sur un trompe pour raminer
et chez nous c'est comme ça que ça se passe
sur notre service en ligne, tout est automatisé
sur la préprode prod
la stélie préprode
et c'est vrai que je peux être nouveau
quand je déploie en prod, il faut d'une pari-en-prime
alors une question qui est un petit peu en rapport
je vous demanderais de répondre vraiment
hyper rapidement sur celle-ci
sauf si vous voyez le matière
à aller plus loin
qui est responsable de la mep
en cas d'incident
en gros on dit que c'est le métier
qui pousse
qui lance le go
pour la mise en production
mais qui est responsable de la mep
est-ce que vous voyez
une équipe qui serait responsable de la mep
ou un acteur
on va dire logique
pour moi ça serait le service
qui a été déployé
qui va être responsable dans le sens
où c'est le premier personne
qui a en général dans les entreprises
après il y a toujours des cas un peu exceptionnels
mais pour moi c'est le premier personne qui va constater
les problèmes
et à partir du moment où il constate les problèmes
il n'y a pas tellement de questions à se poser
c'est le principe dans le conférence de ces rollbacks
il va rollback et redéployer une version précédente
où il va annuler le déploiement progressif
et revenir un peu à une version antérieure
et ensuite
il va y avoir du coup pas spécialement quelqu'un de responsable
mais ça va retourner
dans les équipes de dev pour analyser ce qui a été fait
redevelopper, redeployer
mais il n'y a pas de responsable strict au sens sûr
au point de vue légal
c'est cette personne qu'on va virer parce que la mep c'est mal passé
c'est que ça gère un peu
tu as parlé de rolling update
en fait on n'en a pas trop parlé
mais c'est ça le point le plus important
c'est que de se dire un déploiement
c'est juste un état nominal de l'application
c'est à dire que
scalez l'application
c'est à dire la faire passer de 2 instances à 10
en fait c'est 8 mises en prod
et en fait
mettre à jour c'est exactement pareil
on va juste changer une version par une autre
mais c'est conceptuellement exactement la même chose
et donc on va pouvoir quand on met en prod
stopper une mise en prod
et avoir toujours un état nominal
qui fonctionne
rollback
si jamais on a toujours la version antérieure
mais il faut voir que mettre à jour ça doit être
un état normal de l'application
elle doit être conçue en permanence
pour pouvoir être mis à jour
et donc oui ça va être le SRU
pour faire ça
parce que aussi on va décorrer les plusieurs choses
c'est vrai que historiquement
dans certains équipes où j'ai travaillé
j'ai un peu plus long que prévu
historiquement les équipes étaient même chargées
de mettre à jour le sous-jacent
ça veut dire que l'équipe qui mettait
une application en fait en dessous
il y avait
l'OS qu'on devait mettre à jour
il y avait le bio qu'on devait mettre à jour
il y avait plein de choses extra
donc on se retrouvait à avoir une mise en prod
parce que des fois on mettait à jour énormément de choses en même temps
et donc le rollback devenait quasiment impossible
on ne savait pas faire, on ne l'avait jamais essayé
et donc
ce qu'on a besoin souvent c'est des épis aides clairs
pour définir les rôles et les périmètres de responsabilité
quand je parle de Kubernetes souvent
je parle d'une API de différence de responsabilité
entre d'un côté les devs
qui sont ceux qui exploitent la API
et de l'autre côté les Ops qui fournissent cette API
de déclaration de déploiement
avec les OS
qui vont en dessous etc.
mais quand je déploie une application sur Kubernetes
je n'ai pas besoin de savoir quelle est l'OS qui est en dessous
les Ops peuvent avoir changé l'OS
400 fois depuis que le cluster existe
je m'en finis, mon application
doit fonctionner et donc il nous faut comme ça
ce périmètre de responsabilité entre les deux
et c'est-à-dire que quand on fait un déploiement
on fait un déploiement de manière atomique
on ne met à jour que ce qu'on a besoin de mettre à jour
dans une application
et d'où le rollback possible etc.
Je crois que Christophe que tu n'as pas réagi là-dessus
Non, je vais donner une troisième réponse
pour moi en fait dans le partage de responsabilité
c'est quelque chose que je transmets
dans mes cours et dans mes transferts
tout le déploiement des Ops
les Ops de l'équipe félicitaire
quand je parlais tout à l'heure
il ne peut pas répondre
en fait c'est l'équipe
on ne demande pas qu'il reste pour ça
mais il n'y a pas de personne qui est responsable
c'est vraiment à faire et résoudre les problèmes sur VAR
et donc s'il y a un problème il y a la merde
c'est l'équipe qui te charge de prendre le problème
on va arrêter le résoudre
parce que la fin de travail est équipe
et c'est la collaboration
Merci, là-dessus je vous fais encore un « j'aime les plug »
il y a quelques années quand je suis entré chez Octo
et que j'ai commencé vraiment à déployer mes aides
en tant que dévoilements
il y avait une conférence qui avait été donnée
par un titre du Boston Consulting Group
qui expliquait qu'il faisait un retour d'expérience
sur la SNCF
et qui disait que jusqu'à une époque relativement récente
à la SNCF quand il y avait un déguillage qui pétaient
grosso modo
la façon de travailler de la SNCF
c'était que son management lui tapait dessus
et que globalement en fait ça s'arrêtait là
en fait on tapait sur le titre qui est de la responsabilité
de l'éguillage
et ça s'arrêtait là et donc en fait globalement
la trafic était terturée
et quand le BCG est venu consulter
enfin conseiller la SNCF
ce qu'ils ont fait c'est qu'ils ont inversé
le blame
et donc en fait
ce qu'ils ont fait c'est que
globalement le blame s'adressait
à tous les autres acteurs
qui étaient en responsabilité du trafic
globalement, collégialement
parce que finalement
l'éguillage ça casse, ça arrive
et donc en fait ce qu'ils faisaient c'est que
si les contrôleurs ne faisaient pas monter
les passagers plus lits dans les trains
si les trains n'acceleraient pas
sur les voies de façon à pouvoir
délaister les voies plus rapidement etc
pour permettre que la réparation
plus rapide de les voyages
si les fournisseurs, enfin la logistique
s'occupe d'acheminer le
le nouvel éguillage jusqu'à l'endroit
où l'éguillage est cassé ne se bougeait pas en fait
que c'est eux qui étaient blémés
et pas la personne qui était en responsabilité
de l'éguillage cassé. Donc en fait finalement
c'est bien ce côté on fait porter
la responsabilité sur le collège
de l'ensemble des acteurs qui fournissent
le service global, le service renduqué
de la fluidité du pratique
et non pas ponctuellement la
responsabilité unitaire de l'éguilleur
qui a mal main plus son éguillage.
Je précise juste un truc important
deux phrases et demi
du coup on parle de responsabilité
de but c'est pas d'un responsable
juste pour blame, c'est à dire c'est ta flotte
l'idée notamment quand je parlais du SRE
il est responsable dans le sens où c'est lui qui va se dire
il y a trop de taux d'erreur, c'est trop dangereux
on roll back parce que c'est lui qui est en sorte
à aller de bonne métrique, d'y comprendre
et pouvoir du coup agir là dessus.
Mais en première fois le but n'est pas de blêmer
une personne, le but c'est de rétablir la situation
parce que ce qui est important c'est que votre service fonctionne
et après d'analyser potentiellement de faire un règles su etc
Oui oui tout à fait bien sûr
Je préférerais préciser
Oui tu as du tout à fait, c'est bien du tout
Alors justement
une question par rapport à la responsabilité
est-ce que la délégation
de l'ops au DEV, donc est-ce que le fait
d'empowerer le DEV, de rendre le DEV plus autonome
est-ce que ça convient pas
à avoir des VM de 20 teraoctés de RAM
avec des JVM de 2 teraoctés
de garbage collection
et c'est dit sans aucun troll
c'était pas un costume de Matthew
C'est vrai que c'est quelque chose
que l'on a souvent eu
enfin quand j'ai travaillé dans des équipes souvent
c'était quelque chose que j'ai souvent
comme moi souvent on fait comme
on a des équipes qui sont de la même manière

en fait c'est souvent entendu
en étant dans les équipes pops en disant
les DEVs ils nous ont encore fait
on a encore besoin de mettre des machines
et en fait ce que je dis souvent c'est
imaginer à WS
d'y dire, oh la la nos clients ils ont encore besoin
de trop de machines, on va encore gagner trop d'argent
en fait quand on a
une équipe produit
dont le but est de fournir de l'infrastructure
c'est à dire qu'elle fait un paiement
il y a une maitrique qui est combien
quelles sont les ressources utilisées par le développeur
ça devient juste une maitrique d'amélioration
mais en fait à l'heure actuelle comme c'est
je pousse et pille le lot
en fait je pousse et pille le lot
enfin moi de toute façon c'est pas mon problème
le jour où c'est une ressource qui devient payante
que le budget de mon équipe est imputé
par rapport à ce que, en fait comme n'importe quelle entreprise
comme n'importe quel budget d'un humain
et ben là je commence à faire attention
et justement cette notion d'avoir cette équipe
en entier qui a un budget commun
pour le support, pour le test, pour tout ça
fait que les choix des technologies
qui vont améliorer le test, qui vont permettre
d'avoir peut-être quelqu'un au moins pour le test
qui va pouvoir être devenu un développeur en plus etc
donc si jamais les développeurs ont besoin
de beaucoup de mémoire, et ben tant mieux
ça fait plus de ressources, plus de
mon appareil de la teur des ops et ben ça fait plus d'ops
c'est tant mieux, enfin si jamais les ops
on apporte de la valeur là-dedans
par contre maintenant c'est au développeur à se justifier du
pourquoi leur budget
à tripler ce mois-ci
mais si jamais les gars ont gagné 10 fois plus de clients
ben c'est cool
c'est pas tout le temps un problème
de consommer plus, si jamais on consomme plus
parce qu'on a plus de clients, cool
mais c'est cette équipe là qui devra se justifier avec ses entremes
si elle sortant
si je peux me permettre c'est pas pour du cloud quand t'achètes la machine
croisant
mais c'est justement toute la notion justement
du débordement sur le cloud et justement toute cette notion
que je parlais d'ailleurs c'est oui quand on commence
à avoir ces achats là, et ben le cloud il sert à ça
il sert à voir cette élasticité parce que quand
une entreprise monte, il y en a parfois d'autres
qui tombent et donc
le provider de cloud n'est que
juste une grosse entreprise qui a réussi
à lisser les achats sur longtemps
mais d'ailleurs même si les providers de cloud on achète
les machines sur 3 ans
c'est possible pour avoir des réductions
d'avoir un engagement sur 3 ans donc peut-être même les cloud providers ont exactement
les mêmes choses
c'est juste que on peut plus facilement
monter au dessus des 3 ans plus facilement
mais le cloud provider n'est que le lisage
de ces besoins là etc
mais ça peut arriver dans certains sites de se dire
ben ce mois-ci on se bouche un peu le nez, on sait que la nouvelle release
elle prend 3 fois plus de mémoire mais là on en a besoin
à tout prix et ben tout le monde se bouche un peu le nez
et puis on fait bon ben ce mois-ci ça sera un peu dur
et on verra le mois prochain mais au spin de
d'après on se souviendra il faut qu'on améliore
mais là tout de suite on a besoin de la fonctionnalité
aujourd'hui et quand les ops et les devs sont ensemble
ils font le choix en commun c'est-à-dire ils savent
que ça va être compliqué mais ils vont le faire ensemble
et ce choix là va être commun
quelqu'un veut rebondir
ou Daniel ?
ben je vais rebondir
moi globalement dans mon cerveau
je sais de catégoriser ça je vois un peu 3K
il y a seulement un cas où c'est de l'évolution naturelle
auquel cas ben vous avez plus de clients
on consommer plus c'est ok c'est même bon signe en fait
et vous avez aussi le cas
vous avez deux cas aussi pour moi qui sont existants
qui est le premier cas du
j'ai eu la flemme d'optimiser et du coup
en application ça me donne plus en plus
et ça c'est une problématique qui n'est pas nouvelle en fait
avec le devop c'est le cloud vous l'aviez déjà avant
ou vous aviez détiqué régulièrement
moi j'ai eu ma rappelle détiqué de ben ça marche pas
il faut plus de rames quoi, sans justification
et là dessus c'est un peu à mon sens
aussi un travail qui est plus à faire dans les équipes dev
notamment au niveau des leads
d'identifier de se dire bon là on n'a pas eu
le temps pour cette feature elle est pas très optique
mais c'est important qu'elle soit en preuve maintenant on verra plus tard
ça peut se justifier
niveau business ça peut se justifier sur un temps court
ou quand il y a des problèmes plus graves de fuite mémoire
ou haute, là pour moi c'est au leak tech
de voir avec les maitris qui a dit non là il y a
trop gros changements on voit ensemble
on analyse et on crée pas le problème mais pour moi
il y a vraiment ces trois on va dire
gros case
entre guillemets qui existent
qui sont
qui sont justifiables aussi en fonction du contexte
Christophe
oui je vais juste terminer
en fait
ce que j'ai compris avec Christian
c'est qu'il y a un bar de devops
gros à trafic de devs
et le dev
peut ne pas
faire de l'outil de l'esprit
c'est comme ça que j'ai compris avec Christian
du coup j'insiste sur le fait que quand on fait
quand on va faire des devops
ça veut pas dire qu'on va se passer d'autres
il faut quand même garder ces compétences stops
si en effet les devs ont des compétences stops
c'est qu'à mon avis
à mauvais patern de bref
il faut quand même garder des compétences stops
des compétences d'optimisation
et d'autres avoir trouvé
tous les problèmes et donc c'est pour ça que
sa mesure est super importante
et que vous avez aimé
c'est un des points d'amélioration
si on consomme des normes de bras
et que c'est pas justifié il faut que
il faut faire en face des réduction
d'optimisation dans son code
Ok ok merci
Alors il nous reste un petit quart d'heure
on a deux questions sur la sécurité
et puis peut-être qu'on finira avec
une petite question troll si on a le temps
Alors première question sur la sécurité
le code est-il validé
par la sécurité ou le RSSI
il y a quel moment ?
Alors je pense que là on parle de code pièce
d'apposer cette question est-ce qu'on parle
de code déploiement ou on parle de code applicatif ?
Non c'est ce code applicatif
qui va faire attention d'avoir
des basseurs de données chiffrés
d'accord mais
qu'on respecte la sécurité opérationnelle de notre company
Christophe ? Attends on Christophe
il faut lever de doigts excuse-moi
Ouais je vais commencer parce qu'en plus
avec la mire je crois j'ai trahi
il y a pas très longtemps un épisode sur le FC COPS
Pour moi la sécurité
elle fait partie de tout le monde
et donc elle doit être intégrée aux hommes
et donc du coup elle doit être intégrée au mouvement
ce qui veut dire qu'elles sont même
les confrins de sécurité et les besoins
en sécurité ça doit être codé aussi
les tests dont on parlait
ce sont des tests applicatifs, des tests sécurité
et les autres ces confrins-là
elles doivent être intégrées aux tests automatisés
et donc si les tests automatisés passent
ce n'est pas bon ils passent
il y a quand même un point qu'il n'y a pas d'intervention humaine
il n'y a pas de validation humaine
autre que le test d'automatisation
de la sécurité il est bon, on valide
et donc la personne de la sécurité va valider
la merche equête
du code de telle sécurité
pour moi c'est comme ça que ça ne me reste pas de vie
dans le contexte des hommes
Damière tu voulais rien dire ?
Je vais remer un peu dans la même lignée
pour moi ça doit passer par des choses qui sont automatisées
alors là on parle de tests dans un CICDR
effectivement des tests de sécurité dessus c'est important
même des choses déjà très basiques
et après pour tout ce qui va être test je rentre conformité
pour moi si on revient à l'idée
de je développais tout à l'heure une organisation
que l'équipe sécurité c'est une équipe qui va fournir
des produits, par exemple on peut imaginer
que son produit ça va être il y a des outils comme
CloudCostillian qui permettent de faire du check
en fait de règles de sécurité sur du cloud
donc ils vont passer différents comptes
à WS ou autre et ils vont vérifier que
les bug4 sont bien chiffrés que les bug4 sont fermés au public
et pour moi c'est par ça que ça va passer
c'est ce genre d'outils que la feature team
qu'on va appeler sécurité
sécurité ou... oh merde
non enfin bref
en tout cas c'est ce type d'outils qui vont implémenter
et maintenir pour s'assurer que les règles de sécurité
sont bien maintenues et après
pour tout ce qui va être un peu plus classique
pen test etc je pense que vu que
les livraisons viennent assez régulièrement
on peut plus trop se permettre de voir ça en mode
on fait un pen test je sais pas
tous les deux ans pour se dire est-ce que tout est
dans les clous et là ça peut être aussi intéressant
d'avoir des exercices
continu avec du coup
du bug bounty ou des choses comme ça
sur soit la plateforme de prode, soit des plateformes
différentes s'il y a besoin pour s'assurer
aussi qu'il y a un peu de vérification humaine en plus
ouais moi sur la sécurité
en fait j'ai un point de vue sur la sécurité
qui est que la sécurité
n'est qu'une qualité comme les autres
c'est à dire qu'on a la reliability du site
la school site est disponible en fait est-ce qu'il est
sécurisé ou est-ce qu'il est rapide c'est vraiment
juste des métriques de qualité
donc je suis assez d'accord
avec
un air d'amir justement qui est qu'on doit
avoir des équipes qui sont là pour garantir la sécurité
surtout quand on commence à avoir plein d'équipes
séparées
en fait on commence souvent à avoir des équipes
un peu au-dessus
qui viennent
analyser le
je fais ce que je dis, je dis ce que je fais
tu m'as dit que toutes mes bases de données
étaient chiffrées, bon bah très bien
je vais voir est-ce que vraiment c'est chiffré
mais ces équipes là des fois
elles vont faire du chaos
du chaos monkey
et donc si tu as une équipe par exemple ça veut dire
tu m'as dit que ton application elle pouvait tenir
si jamais je coupais la zone paris
bah je coupe la zone paris
ça marche pas c'est ton problème c'est pas le mien
et donc par exemple de faire des pen tests
en prod en disant bah toi tu m'as dit que t'arrivais
à résister à des
instructions basiques bah j'ai payé quelqu'un
pour essayer l'un de l'autre
de vrai tu en as une équipe qui est là pour me dire aussi
les SLAs, tu m'as dit que tu avais une disponibilité
à 99,9 et ben je la mesure
mais c'est pas l'équipe qui va le faire même, c'est une équipe à côté
et moi je parle un peu comme ça comme le contrôle technique automobile
qui est la sécurité des automobilistes
et ben c'est pas parce que je vais chez le garage
qu'il y a pas un organisme qui va checker
ce que le garage a fait
bah c'est un peu ça en fait c'est à dire qu'il nous faut
dans une entreprise un centre de contrôle technique
qui va valider que toutes les entreprises
au sein de mon parc
ont bien dit ce qu'elles avaient dit
qu'elles ont dit qu'elles allaient faire
dans ce sens là
et moi c'est plutôt comme ça après quand on parle
du code de sécurité c'est à dire plus
à l'intérieur du code
bah là ça va dépendre de chacune des équipes
en fait y a pas de règles de sécurité
en fonction des technologies
en fonction du périmètre
en fonction du besoin
pour avoir des règles de sécurité différents
donc là pour le coup c'est à chacune des équipes
de savoir le niveau de sécurité qu'elle doit atteindre
et de le faire
et donc là pour le coup d'avoir des gens qui font peut-être des fois de l'audit external
voilà le code il continue et continue
on demande un audit external sans même des fois le dire aux équipes
on a cette équipe qualité qui est là
et qui vient de checker
et donc par exemple nous quand on était au HDA
on avait des fois des validations de toute notre infrastructure
parce qu'on devait être certifié ANSI
etc etc
on avait des fois des audits externes et je trouve ça très bien
ça nous donnait une perspective par rapport à ce qu'on faisait de temps en temps
donc il faut pas
peut-être pas avoir des problèmes par rapport à ça
donc comme tu te testais
testais la mesure
il n'existe pas
de bonnes sauvegardes
il existe des restaurations testées
il passe pas le point de sécurité
je rebondais juste le l'outil
il y a un tool qui a été donné par Whiskale
par Tanguy
je vous ai coupé ça sur Youtube
c'est un outil qui est assez intéressant de faire de la compliance de sécurité
sur le cloud
il nous reste 7 minutes
on a encore pas mal de questions
mais je pense qu'on a un peu fait tout
c'est questionnel et intéressante
quel conseil vous pouvez le donner
pour pouvoir faire
pour pouvoir se lancer dans le DevOps
alors qu'on a toujours notre run à gérer
autrement dit comment on fait pour garantir
pour conserver un niveau de qualité
comment on fait pour transiter
transformer sans dégrader la qualité de notre run
est-ce que ça vous inspire
Christophe ?
oui, commenté par
de nouveaux projets
je rebondais la solution
là comme ça il n'y a rien qui me perd d'autres
les nouveaux projets
on essaie de faire du DevOps avec eux
d'appuyer les bonnes pratiques
mais tout ce qu'il y a en place
reste en place
moi je vais compléter avec ce que vous avez Christophe
on disait un peu de tout à l'heure
au niveau de la transition
on a un projet un peu legacy et DevOps
c'est de mettre des nouveaux projets
commencer à couper les anciens projets
et se faire la main de suite et se réserver un peu de temps
accepter de prendre plus de temps en début
d'échanger ensemble pour découvrir
parce que ce soit une découverte pour toute l'équipe
on ne faut pas essayer de prendre du temps là-dessus
pour découvrir et de timer ce temps possiblement
pour ne pas impacter le run
et dans tous les cas mesurer aussi
vos métriques de run
et vous assurer que vous ne dégradez pas
la situation actuelle
peut-être après une autre solution
qui est
de switcher
de technologie par exemple
pour la mise en production
on se fait la main sur les technologies de mise en prod
qui marcheront
à ce moment là
il va y avoir du Kubernetes
on peut très bien avoir cette même application
la passer d'abord dans des conteneurs
puis la passer dans des infrastructures d'orchestration
et tout en regardant la même prod
en regardant la même application
c'est juste la façon dont on a déploie
qui est devenue différente
ok ok
on se finit il nous reste 5 minutes
on se finit avec une petite question troll
allez deux petites questions troll
si vous êtes prêts
est-ce que les BDD dans Kubernetes
c'est ok ?
ça a toujours été
ça sera toujours
je suis pas le point de la plainte de la base
il y a argument
qui ça moi ?
oui oui oui
si les bases sont toutes petites
et qu'on quette
ça serait plus non critique on peut les mettre
si les bases sont critiques
ou sont un peu plus volumineuses
on n'a jamais été pas dans Kubernetes
parce qu'il peut y avoir corruption de données
la vente est toute petite base
et qu'elle pouvait se garder hyper annulièrement comme tout le plaisir
et donc même si la corruption de données
on ne le perd plus là
Dami, tu peux le remblier ?
oui moi je suis pas fan
c'est plus pour des questions
techniquement aujourd'hui on peut le faire
des opérateurs qui existent
et des choses un peu poussées qui existent
et qui sont assez sympa il y avait une attaue
qui avait été donnée au FOSSDEM 2020
qui est assez intéressant là dessus
et du coup je n'ai pas encore testé
mais moi je ne suis pas fan pour une question
de logique de cycle de vie
moi je pense que la base de données n'a pas le même cycle de vie
qu'une application au niveau conteneur
donc du coup pour moi il n'y a pas de raison
de le mettre au même endroit
moi je décide de regrouper là dessus par cycle de vie et logique
mais c'est plus humain on va dire
qu'un vrai point technique derrière de mon côté
oui je vais rajouter
une base de données mais qu'une application comme une autre
qui avait juste besoin
d'un disque
si jamais il y a une corruption de données
il faut régler le problème mais en mon avis
c'est pas possible l'un d'autre
sachant qu'en termes de taille on a maintenant des bases de données comme vitesse
qui sont juste des bases de données utilisées par Youtube
donc sachant que toutes les bases de données de Youtube sont dans un Kubernetes
donc en termes de taille ça va
ça passe
et en fait
une base de données n'est qu'une parmi une autre
Kubernetes c'est juste quelque chose qui met des disques durs
qui les branche sur une machine
et qui spawn un process
à un bon endroit mais en vrai
un conteneur c'est exactement pareil que si vous aviez une unit'
systemd ou runnit ou n'importe quoi
un conteneur n'est qu'une application comme une autre
c'est juste un DEB comme une autre
c'est juste qu'il n'a été pas cadier en flat pack
ou un app image mais il n'y a pas de notion
une base de données n'est vraiment qu'une application comme une autre
elle peut être
après en effet peut-être sur des clusters différents
parce qu'en fait si jamais on a des équipes
qui fournissent des bases de données à the service
et bah en fait ils auront des clusters qui auront un cycle de vie différent
avec des disques différents
et que t'as des technologies sous-assins différents mais Kubernetes
n'est que la manière de déclarer ce qu'on veut avoir
mais moi j'ai des pods qui ont un uptime
de plusieurs centaines de jours
ils n'ont jamais bougé parce que l'autre en dessous
n'a jamais bougé, ils bougeront jamais
enfin comme ma base de données qui était dans
une unit' systemd si ma machine bouge pas
l'avantage c'est que je sais que si
l'autre tombe
mes données elles bougent avec et j'ai pas perdu
de données justement là où avant
bon bah on prie y a un peu quoi
en fait OPEAS NOTE au strategy
l'espoir comme quoi la machine
va continuer de fonctionner à de vite un metternam
enfin pour moi c'est pas de la prod
c'est juste de l'espoir
c'est pas d'expertise
c'est une question trop alors en même temps
je sens que ça pourrait faire
ouais pas un nom débat je pense
allez on se fait une dernière question très rapide
quels sont les outils standards DevOps
une geek
une geek
j'ai un geek ici, Christophe
geek lab terraform
on s'y va
et minuc c'est évidemment
on m'a l'écartre à l'MGLN c'est incroyable
tu veux rajouter je pense
que Guilin qui le manque dans l'équation
bah et Kubernetes
je pense et non mais c'est en fait
en gros ce que j'explique souvent c'est que
vous voyez ce petit cycle DevOps avec les tyrons
avec d'un côté les devs, d'un côté les ops
bah en fait on a pas fait un rond on a fait vraiment
cette boucle inversée comme ça et bah
il y a un point remarquable quand il y a 2 points
et que les deux courbes qui se croisent au même endroit
ça fait un point remarquable et bah quand on veut séparer
2 mondes aujourd'hui on a des API
c'est cool les API parce que ça permet de tester, ça permet
d'évoluer etc. bah la seule API que je connais
qui permet d'aller du monde du dev au monde de l'ops
c'est à dire d'un côté les développeurs qui disent
ce que l'on s'y en envie et d'autre côté des opérateurs
qui peuvent mettre en place
et ressort cela c'est que l'indice
il y en avait d'autres avant mais qui étaient nuls
comme mesos ou comme un peu nomades
mais aujourd'hui Kubernetes a pris le marché
c'est devenu un peu comme Linux
enfin moi quand j'ai commencé à bosser en 2009 on me disait
Linux on ne pourra pas le mettre partout
j'ai entendu ça alors tout le monde voulait du Windows
aujourd'hui on voit Linux tourne partout
ça tourne dans des avions, ça tourne dans l'ISS
ça fait voler des fusées de SpaceX
c'est partout on arrive à mettre partout
bah Kubernetes c'est un peu pareil
Kubernetes moi je l'ai mis dans des avions pour Thales
ça passe ça marche très bien
je l'ai mis dans des conteneurs maritime
je l'ai mis dans n'importe quoi
ça tourne partout parce que en fait ça
l'everage sur Linux c'est juste un
c'est juste un rôneur de Linux
c'est tout, distribué avec une vulgaire
API en GRF-C mais c'est débile comme on l'a appelé
le troll s'est étendu à scale
puisqu'on a même des intervenants
de la salle qui interviennent sur le
le talk
donc à la vomitéus ça ne fait pas
oui ça fait partie donc il faut rajouter
tu prends tout le
CNCF
là le landscape
et puis voilà
et on peut parler aussi
de la table périodique du DevOps
de chez XecoDialax
maintenant digital AI
qui est de nos point de vue le meilleur
produit qu'ils ont sorti
ça a l'air un minuteur
son meilleur produit c'est cette table périodique
sérieusement
je pense que c'est ce qui
donne la meilleure valeur ajoutée
de tous leurs efforts
et là-dedans on trouve globalement
tous les outils
elle est constamment en mise à jour
mais c'est pas un très bon outil
après on n'avait pas trop parlé de notre solution
moi j'ai dit guide un peu en trop lent
aujourd'hui c'est le seul outil où je suis quasiment sûr
de reposer dans toutes les stacks
après oui il promet de l'us graphana ça marche bien
mais on peut mettre aussi du data dog ou d'autres choses
donc c'est vrai qu'on n'était pas trop partit sur les outils
mais en tout cas moi parce que ça dépend du contexte
ça dépend des besoins donc
on n'est pas sûr d'y le trouver
on ne pourrait plus acheter tout la partie
d'hockeur
un conteneur global
maintenant c'est standardisé
tout ce qui est runtime etc
qui est aujourd'hui
quelque chose de classique mais qui est embarqué donc
mais toute cette logique d'avoir des ripos
des images et tout ce toutillage qu'il y a derrière
pour moi c'est aussi très important
mais on pourrait le mettre dans le tooling de base
Ben bien sûr vous avez répondu à 16 questions
ce qui est pas mal il en reste 5
vraiment félicitations à vous
ça a été plutôt efficace
il nous reste d'abord moi personnellement
à vous remercier du temps que vous avez investi
vraiment généreusement, gracieusement
je suis très touché en plus de participer
à mon premier podcast
donc un petit tarmichette
depuis 10 ans que je m'écoute
et puis j'espère que ça vous a plu
si vous avez appris des choses
alors je garde précieusement les autres questions
et j'essaierai directement
par un autre biais
bien sûr par le podcast
donc normalement ici nos éditeurs
qui le publieront de façon publique
nous on va le récupérer pour le mettre
sur une belle pointe d'éleve
voilà et puis je vais travailler
le tout à son procès pour vous venir
au foot de vos vidéos
des différentes interdences en ce moment
merci beaucoup messieurs
bravo à vous
c'est un petit spécial à Christophe
qui était en remote et je sais que c'est pas facile
de travailler dans ces conditions
merci beaucoup à toi
je n'ai pas de rien, c'est moi que je pouvais faire