Bonjour à tous, bienvenue au premier DevOps.
Alors, c'est un podcast pour parler de la méthodologie DevOps.
Donc, bienvenue à tous.
Ça va se passer en plusieurs parties.
On aura de l'actualité, on aura des chroniques.
Donc, on espère que ça vous plaira.
D'abord, je vais laisser un peu tout le monde se présenter.
Donc, on est quatre à table.
D'abord, Bartélémy.
Donc oui, Bartélémy Vestemont DevOps chez Critéo actuellement.
Et j'ai un background.
Tout simplement.
Bien, moi, je suis Marc Falzon, j'ai 32 ans.
Je suis hop depuis un peu plus de 10 ans.
Et je travaille actuellement chez D2SI,
où je suis consultant cloud et automatisation.
Et moi, Victor de Monchi, DevOps aussi avec un background-ops.
Je travaille chez Critéo dans la même équipe que Bartélémy.
Et enfin moi, Guillaume Létron.
Donc, je suis DevOps ascendant-ops.
Et je travaille à l'heure actuelle chez Vendeprivé.
Donc maintenant, on va passer...
Il y a une petite rubrique, on va essayer de garder à chacun de nos podcasts.
En tout cas, si ça plaît à tout le monde.
On va demander à Marc de nous expliquer ce qu'est le DevOps pour lui.
Alors, pour moi, le DevOps, c'est ce qui se passe
lorsque les développeurs et les opérateurs,
habituellement, si s'admire,
travaillent en bonne intelligence
et en ayant conscience de leurs contraintes respectives.
Pour moi, le DevOps, c'est plus une approche,
une façon de penser plutôt qu'une organisation hiérarchique
qui consiste naïvement à mélanger des devs et des hommes dans une même équipe
et attendre que la magie opère.
Sans faire de mauvais jeûne mot.
Dans les faits, ça tient en fait à assez peu de choses.
Mais il faut quand même que les deux parties jouent le jeu.
Selon moi, les développeurs doivent se responsabiliser
vis-à-vis de leur code.
Du code qui produit et prend de conscience
que leur job, ça ne rède pas après avoir un comité d'anguite.
Mais à le déployer et à le porter en production,
se porter garant du bon fonctionnement
et de ses performances en production.
De leur côté, les ops doivent être transparents
quant à l'infrastructure qui construisent et qu'ils opèrent
et doivent contribuer à outiller les développeurs
pour qu'ils puissent déployer en autonomie
et superviser le comportement de leur application en production
en leur fournissant des logs, des métriques et des alertes, par exemple.
Moi, je suis convaincu que cette extension
du domaine de responsabilité entre guillemets,
j'ai pas trouvé mieux comme terme,
et bénéfique pour les deux parties,
des développeurs qui sont plus infantilisés
mais plutôt responsabilisés
Ce qu'on peut faire, c'est quelques pas supplémentaires
vers l'exploitation d'un service en production
et même potentiellement proposer des changements d'infrastructure pertinents
ou tout du moins d'ouvrir la discussion
avec du recul et une perspective différente des ops.
Les 6 admins proactifs plutôt que réactifs
ont toujours réglé les problèmes quand ils arrivent
capables de mettre à la main la patte
en termes de développement d'outils internes
plutôt que du vulgaire scripting entre guillemets.
Donc travailler sur les concepts de déploiement
et d'observabilité offre au dev de la visibilité
sur leur service et bénéficie de leur aide
en cas d'incident ou même en simple cas d'optimisation
de l'infrastructure.
Super, très complet, on peut plus d'accord tous.
Très bien préparé en tout cas.
Alors, on va passer maintenant à une petite phase d'actualité
donc bien sûr, on espère que ça changera un peu chaque semaine.
Je me demandais à Victor peut-être de commencer
une petite actue que tu as pu voir cette semaine.
Cette semaine, non, par contre,
il y a deux ou trois semaines de ça.
Du coup, je vais parler de SpaceX,
qui a sorti une vidéo
où ils ont parlé de tout ce qu'ils ont fait
pour arriver jusqu'au succès
qu'ils ont eu pour la roquette réutilisable.
Et ça va bien servir mon propos pour la chronique après
parce que les mecs en fait,
on n'a pas honte de montrer qu'ils ont échoué
plein de fois avant de réussir
à sortir quelque chose qui fonctionne.
Donc c'est une vidéo YouTube
que vous pouvez retrouver avec tous les échecs de Falcon 9.
Je l'avais vu sur Twitter en fait.
Marc,
Moi, je n'étais pas très inspiré pour ces actus.
Alors, je vais parler un petit peu Cloud.
Il y a quelques jours, Google Cloud a annoncé
un nouveau type d'instance
qui peut monter jusqu'à 96 vcpu
et 624 gigas de RAM.
Donc voilà, c'est la bonne grosse bobasse.
Donc du coup, on espère que maintenant,
j'avais pour enfin tourné convenablement.
Désolé, c'est gratuit.
Petite instant-troll.
Marc.
Pour ma part, c'est pas très lié au DevOps,
mais c'est un petit anniversaire
parce qu'il y a 7 semaines,
en fait je crois que c'était lundi,
c'était l'anniversaire des 10 ans d'hitère,
donc qui est un projet international
de travail autour de la fusion nucléaire
et de l'exploitation de cette technologie
qui est quand même une technologie assez ancienne,
en tout cas, qui est connue.
L'exploitation de manière industrielle
de cette technologie pour générer de l'électricité.
Donc c'est ces 10 ans et voilà,
le projet est toujours en marche.
On espère le voir aboutir de notre vivant.
Très bien.
Et alors pour moi, la petite actue
que j'ai pu trouver, c'est toutes les sociétés,
notamment les GAFA,
qui commencent à pas mal recruter en France.
On voit pas mal de news en ce moment
tombé avec Google qui va recruter en France.
Et on voit donc une certaine attractivité quand même
de Paris et même globalement la France
sur ces techniques, enfin,
pour les grands acteurs du web.
Donc plutôt cool, voilà,
n'hésitez pas à regarder.
Ça veut dire que vraiment,
on a une compétence, on a un écosystème
qui est attractif et c'est plutôt une bonne chose.
Ça fait quelques années déjà que ça commence à l'être.
On pourrait noter Docker qui a ouvert des bureaux à Paris, etc.
Enfin vraiment, il commence à y avoir
une pas mal de sociétés qui se mettent à ta dog aussi, par exemple.
On voit plein de sociétés qui s'installent à Paris
et j'espère ailleurs aussi en région.
Alors, maintenant, on va passer
un petit instant chronique.
Donc chacun de nos intervenants a normalement
préparé un peu un sujet.
Donc on va commencer par Marc,
qu'on a fait au tirage au sort.
Donc Marc va nous parler du Bluegrind deployment
et je le laisse parler.
Voilà, donc effectivement, on va parler aujourd'hui
la méthode de deployment de Bluegrind
et de Canary deployment.
Donc qu'est-ce que c'est que le Bluegrind deployment
c'est une technique de déploiement sans coupure,
sans downtime,
qui permet un retour arrière rapide
en cas de complication et instantané.
Donc le principe, c'est de disposer
de deux plateformes applicatives si possibles identiques,
dont une seule des deux sert le trafic à un instant T.
La première, qu'on appelle Blue,
fait tourner une version de l'application N.
Lorsque vient le moment de mettre à jour l'application,
donc en version N+,
celle-ci est déployée non pas sur la plateforme
qui sert actuellement le trafic,
mais sur la seconde plateforme appelée Green
et donc le trafic est ensuite aiguillé
sur cette seconde plateforme au niveau du load balancer.
Si un problème survient à la suite de la mise en production
sur la nouvelle version,
il est donc possible de réguler le trafic
sur la plateforme précédente, la Blue,
quasi instantanément et donc ainsi de revenir
au précédent état de fonctionnement connu.
A l'inverse, si tout s'est bien passé
et que tout tourne sur la plateforme Green,
elle reste active jusqu'à la prochaine version à déployer,
mettons, version N+,
qui sera faite du coup sur la plateforme Blue et ainsi de suite.
Donc, il y a une variante de cette technique
qui s'appelle le Canary,
qui consiste à déployer la version N+,
non pas sur une nouvelle plateforme dédiée,
qui peut être un petit peu problématique
en fonction des infrastructures.
Tout le monde n'a pas les moyens
de se payer un double load de frontaux, par exemple.
Et donc du coup, de déployer la nouvelle version N+,
plus sur un seul des supports applicatifs,
un serveur ou une instance de VM, par exemple,
et donc qu'elle ne reçoive qu'une fraction
du trafic de production et donc à analyser
les potentiels effets de bord sur cette nouvelle version
avec les outils d'observabilité classique,
les métriques, les logs, etc.
Et graduellement ensuite,
déployer la nouvelle version
sur le reste des instances progressibles.
Ce sont des techniques qui sont assez souples
et pas forcément très complexes à mettre en oeuvre,
avec les orchestrateurs qui commencent
à devenir le nouveau standard maintenant
dans le monde des containers,
notamment Kubernetes pour ne pas le citer,
intègrent nativement ce genre de déployment
pour faciliter un petit peu
les mises à jour de version et transparent.
Voilà, je suis terminé.
Super.
Donc là, on va commencer un petit débat maintenant,
parce que je sais qu'on a plein de choses à dire.
Déjà, j'ai peut-être une question.
Est-ce que tu l'as déjà vu en place
ou mis en place ce type de déployement ?
Mais je ne l'ai pas vu ou mis en production
à grande échelle.
Donc j'ai fait des tests et j'ai procédé
à des déploiements de prototype.
Et donc du coup, on voyait qu'on pouvait monter
de version sans qu'il y ait d'accro
en termes de qualité de service.
Ok.
Moi, j'ai une autre question,
parce que j'ai déjà eu été confronté
à ce genre de problèmes-là.
C'est comment on fait avec une base de données,
genre MySQL, tout simple, tout bête,
parce qu'on est quand même dans un cas
de visage quasiment majoritaire,
dans petites applications.
Comment on fait pour assurer la pérennité
à la fois la version 1 plus 1
et la version n pendant cette phase
de migration ?
C'est une très bonne question.
Et en effet, c'est là que ça se complique.
Ce n'est pas si simple que ça.
Dans le cas où en effet,
cela implique des changements
de schémat de base de données,
notamment, c'est la quelle babless.
Donc une des solutions de contournement
ou plutôt de technique
qui est invoquée dans ce genre de cas,
c'est de faire les changements
de structures de base de données
réversibles, à savoir,
lorsqu'on veut, par exemple,
changer le type de colonne.
Ce serait de créer une seconde colonne
qu'on va peupler avec le nouveau type,
qu'on va peupler à partir de la
nouvelle version.
Et ensuite, dans un second temps,
vraiment faire le switch
sur le nouveau schéma.
Donc, une fois qu'on a validé
que le bon fonctionnement,
le bon fonctionnement de la nouvelle version.
Ça ne demande pas plus de travail
pour les développeurs.
Enfin, ce n'est pas plus complexe
pour eux d'aborder,
de tester ce genre de choses.
C'est possible, mais est-ce qu'on fait
vraiment des changements
de schéma de base de données
vraiment souvent en production ?
Des vues du psychologie
d'une prod d'un logiciel, par exemple,
on va y en sera amené
beaucoup plus facilement
à faire ce genre de changement.
Peut-être que ce n'est pas le moment aussi,
on va vouloir aussi les appeler
le Blue Gun Deployment.
Oui, peut-être.
Oui, ce n'est pas un incontournable.
Si jamais le projet est tout début,
critique, etc.,
c'est peut-être un problème
d'indéfinition.
Je pense que pour tout ce qui est
state-life-web-service,
ça ne pousse pas de problème.
Par contre, et là,
on est tous d'accord là-dessus.
Par contre, pour ce qui est base de données,
moi, je me rends tendance
à pas trop utiliser ce genre de système.
Peut-être, comme Dimar,
qu'il m'en peut prévoir
des procédures de migration,
mais je trouve que ça rend le truc
un peu trop compliqué
et peut-être qu'il ne sait pas
la bonne méthode de déployment.
Je vous recommande
juste pour déterminer
un très bon article écrit par Octo,
l'entreprise Octo,
sur le sujet-là.
Je posterai le lien
soit sur le Twitter
ou sur le blog du podcast.
Super.
Moi, j'ai par contre aussi
un autre commentaire,
c'est que si jamais le plugin
n'est pas forcément fait pour vous,
il y a une autre technique,
sinon, c'est le feature flapping,
ou feature switching,
qui est donc d'intégrer
dans l'application directement
l'activation ou non des codes,
qui permet comme ça
de déployer avec
une autre configuration.
Donc là, ça veut dire, par contre,
que l'application doit vraiment
être pensée, développée
avec cette idée-là en tête.
Là, pour le coup,
j'ai en attendant ça dire
que c'est intrusif au niveau du code.
Et donc du coup,
ça peut générer potentiellement
beaucoup de déchets
en termes de développement
et un peu de salire
entre guillemets,
son code avec beaucoup de switch,
de if partout.
Et ça, les développeurs,
en effet, seraient peut-être
pas forcément enclins.
C'est une philosophie.
Et ce que ça peut amener,
ça peut apporter, en plus,
c'est une finesse dans le choix
que l'AB testing,
ou le Canary deployment,
ou le Blue Green deployment,
ne permettent pas.
Par exemple, on va pouvoir
cibler des utilisateurs précis,
par exemple, d'un OS
ou les utilisateurs
d'un Android,
ou de Mac,
ou peu importe.
Et le feature...
Le feature switching,
Switching,
ou Toggle,
feature flag.
Une feature flag.
Une feature flipping aussi.

Une boule à la.
Une feature de question.
Et en fait,
cette méthodologie-là va permettre
une grande nullarité
beaucoup plus importante
et qui peut être intéressante
pour les développer.
J'irai jouer d'accord avec toi.
Et dans un autre contexte,
technique intéressante,
par exemple,
pour faire un mode dégradé
de son application,
pour pouvoir désactiver
certaines fonctionnalités
lors d'un incident,
par exemple,
désactiver des fonctionnalités
coûteuses
sans avoir à pénaliser
tout le reste du service.
Super.
Alors, maintenant,
on va passer
à la deuxième chronique.
On va demander à Victor
qui va nous parler
de la culture de l'échec.
Juste pour vous utiliser,
après, on aura quelque chose
qui s'appelle
mécanisation contre automatisation.
Et enfin,
les armes du DevOps.
Voilà, pour le petit teasing
qui vient ensuite.
Donc Victor,
culture de l'échec.
Oui, oui.
Alors, bon,
c'est beaucoup moins technique
que le Blue Green deployment.
C'est quelque chose de plus général,
mais dont j'avais envie de parler.
Donc la culture de l'échec.
Et donc, avant de commencer,
je voulais un peu définir
les termes culture-échec
pour qu'on sent bien un corps
sur la définition.
Donc,
il faut savoir que la culture,
au sens large,
peut la définir
de plein de façons différentes.
Mais une des définitions
que j'ai cherchées,
forcément,
quand j'ai préparé ces chroniques,
et que j'ai trouvé
qui me semble plutôt bien
servir le propos,
c'est donc,
selon un sociologue québécois,
qui s'appelle Guérochet.

Donc, la culture est un ensemble
de liés, de manière de penser,
de sentir et d'agir
plus ou moins formalisé,
qui, étant apprises
et partagées par une pluralité de personnes,
servent d'une manière,
à la fois objective et symbolique,
à constituer ces personnes
en une collectivité particulière et distincte.
J'espère que vous n'avez pas perdu.
Ah, c'est complètement on met.
On va suivre le reste.
Ok.
C'était un peu l'instant culture.
Ce serait un peu moins...
un peu moins abstrait après.
Maintenant, on passe à l'échec.
Oui, mais en gros,
ça veut dire que c'est
un ensemble de personnes
qui pensent de la même manière.
Tout ça pour dire ça.
Voilà.
Et puis,
pour ça, c'est pour l'aspect culture,
pour la particulture.
Et donc, l'échec,
bon, je pense que c'est assez simple
à définir, mais juste pour être d'accord,
encore une fois, je vais le définir.
Donc, l'échec, c'est une situation
qui résulte d'une action
n'ayant pas goûtive résultat
et se compter.

Tout simple.
C'est clair.
C'est clair.
Et moins long.
Et donc,
dans un monde
où on valorise de plus en plus
la performance individuelle,
plutôt que la performance collective,
je pense qu'il peut être difficile
de concevoir des chouets
par peur de laisser un avantage
décisif à ses concurrents.
Par exemple, si on parle
au niveau business
ou par même,
même par peur de,
je sais pas,
d'avoir une mauvaise note
à sa notation
bienuelle,
si il y a ce système
en place dans son entreprise
ou de ne pas avoir
sa promotion, etc.
Et donc,
ce qui peut être intéressant,
c'est plutôt que de redouter
l'échec, de l'intégrer
en quotidien dans le travail
pour qu'il n'apparaisse
plus comme une démonstration
du manque de réussite,
mais comme le corollaire
de l'innovation et de l'action.
Et donc, en gros,
ça revient à dire
qu'il faut banaliser l'échec.
Commencer tous,
c'est difficile
de prévoir
toutes les issues possibles
d'un projet quand on le démarre,
sauf si on essaie
de faire du bon gros waterfall
des familles.

tant que de faire ça,
on peut se dire,
un moment donné,
on définit direction générale
vers laquelle on veut aller,
on entend démarre un projet,
et plutôt que de
prévoir toutes les issues possibles,
on favorise l'action
et on réagit,
quand c'est nécessaire,
fonction du retour et d'expérience
de chacun.
Et finalement,
on arrive à un processus
qu'on pourrait qualifier d'agile,
plus ou moins,
où on a une boucle d'iterration
assez rapide,
en théorie efficace
entre les différentes équipes.
Et donc,
comment on pourrait appliquer ça,
concrètement, dans le DevOps,
justement.
Donc, ce que je viens de dire,
c'est donc,
travailler en étroite collaboration,
voire même en immersion,
dans les équipes concernées
par un même projet,
on pourrait notamment appliquer
le concept des feature teams,
prendre les décisions
qui s'imposent,
quand il le faut,
même si elles sont difficiles,
c'est-à-dire,
si à un moment,
on va dans une direction
qui ne fonctionne pas,
plutôt que d'essayer
à tout prix de
mettre des rustines
et de faire en sorte
que ça marche,
alors qu'on sait que ça va,
au final, pas marcher,
ou ça va aboutir un truc
tellement compliqué
que ça va pas être exploitable,
il vaut mieux dire,
stop, on arrête,
et on commence
dans une autre direction.
Il faut valoriser,
capitaliser sur ce qui a pas fonctionné,
quand l'échec survient,
ça c'est super important.
Pour moi, c'est-à-dire,
il faut à tout prix,
quand on prend la décision
d'arrêter,
ou que ça va pas,
ça va pas comment on voulait,
il faut ensuite
débattre ensemble
de ce qui a pas marché
et en tirer des leçons
pour pas reproduire
les mêmes échecs plus tard.
Et surtout,
quelque chose
peut-être bien
encore plus important,
c'est de pas essayer
de rejeter la faute
sur une équipe
ou une personne,
parce que quand on est
dans une boîte,
quand on est dans une équipe,
quand on est
sur un projet,
on est
finalement tous
dans le même bateau,
et l'échec
peut affecter tout le monde
de la même manière.
C'est...
Il faut pas
la rejeter
sur quelqu'un
qui prend très mal le lieu.
Donc,
ce que je veux dire,
c'est que ça coûte moins cher
d'accepter l'échec
qui consiste dans une voix
que plutôt que de...
voilà, que de...
enfin, ce sera
ma conclusion.
D'accord.
Tant que tu devais s'en issu.
Alors, je vais te reposer
la même question,
c'est que j'ai pu poser
tout à l'heure un marque.
Est-ce que t'as pu déjà
vivre ce type
de condition de travail,
cette philosophie, en tout cas ?
Oui, j'ai déjà pu vivre ça.
C'est...
Quand on...
Bah, typiquement,
quand on arrive
dans une boîte, par exemple,
et qu'on nous donne un projet,
qu'on a...
Sur lequel on a un regard nouveau
parce qu'on faisait pas partie...
On faisait pas partie
de cette boîte avant,
donc on arrive
à un regard nouveau,
on voit le truc, on se dit
mais ça,
ça peut pas marcher,
pourquoi vous faites ça ?
Il faut tout refaire,
ça va pas du tout.
Et vous dites non,
mais ça marche comme ça
depuis des années et tout.
Mais là,
là, on a plein de demandes
des clients,
il faut qu'on modifie le truc
pour que ça fonctionne,
on n'a pas le temps
de tourner bloper.
Et même quand on dit,
oui, mais c'est...
ça prendrait moins de temps
de repartir de zéro
et de faire autre chose.
C'est pas forcément évident
de convaincre en face
quand on a ce genre de réaction.
Ok.
Moi, je suis assez...
J'ai remarqué depuis
quelques années,
cette tendance des grandes
du web, entre guillemets,
faire ce qu'ils appellent
le blameless post mortem,
que j'aime beaucoup,
j'aime beaucoup cette démarche-là
en effet, de faire d'introspection
sur quelque chose qui a merdé.
Ça, il y a eu un fail.
Du coup, on analyse
les causes vraiment
sans pointer du doigt,
sans essayer de rejeter la faute
les uns sur les autres.
Et on va de l'avant
et c'est vraiment quelque chose
qui me plaît beaucoup.
J'aime beaucoup cette approche.
Moi, je rajouterai aussi que
peut-être pour
des fois atténuer
ce type de problème,
c'est de mettre
toute l'équipe à parler
de la future sim.
C'est même aussi la notation
d'équipe.
C'est quelque chose qui permet
d'en bas,
mais aussi d'un seul coup
d'embarquer tout le monde
dans le même bateau,
de pas avoir forcément
quelqu'un qui va être chargé
du déploiement.
Et si le déploiement
se passe pas,
eh bien, se passe mal.
C'est forcément de sa faute.
En tout cas, c'est lui
qui va être penalisé.
Mais en ayant une notation
d'équipe,
en prenant tout le monde,
il peut y avoir toujours
une notation individuelle.
Mais vraiment,
dans le aspect RH,
quelque chose qui peut faire
changer,
c'est vraiment aussi
cette notation d'équipe.
Quelque chose que je vois
infiner assez peu.
Le manager est noté
pour l'équipe,
mais c'est rare de mettre
une notation.
C'est vrai qu'en général,
on dit que les résultats
de l'équipe
ou de l'entreprise
sont déjà,
font déjà,
comment dire, pondérés
dans la note finale
pour des raisons X, Y.
Mais c'est vrai que
on note en général
que sur des objectifs personnels
et on voit rarement
les objectifs d'équipe
ou les objectifs bienuels
qui sont reflétés
sur nos résultats.
Alors qu'on est demandeurs.
Je pense qu'on a tous vu
des gens avoir des résultats
au final très bons
dans une équipe qui
faisait n'importe quoi.
Dans le résultat,
n'était pas là.
Je pense que ça m'a toujours choqué
cette vision.
Ce qui fait même des fois
que ça peut arriver
avec quelque chose
où les gens se mettent
en avant de manière extrêmement forte
au-delà même du projet
pour que eux,
leurs visibilités se le soient
quand ils sont dans un projet.
Au lieu de fixer le projet,
il vaut mieux avoir une visibilité
sur d'autres choses
plutôt que de vraiment
s'attaquer
aux vrais problèmes.
Je sais pas.
Mais tu es ?
En tout cas,
on sent qu'il l'a écrit
avec le coeur
et qui était attaché
à ces problèmes-là.
Non, c'est sûr que c'est un problème.
J'espère que c'était pas
trop abstrait, en tout cas.
Peut-être un petit peu
pour une première chronique.
Je pense pas forcément
très concrèmme.
On réécoutera.
Alors moi,
je vais vous parler
de mécanisation
contre automatisation.
C'est un sujet
pour ceux qui me connaissent
que j'ai accordé
depuis un petit moment.
En fait,
dans le cadre
de mon expérience,
je me suis dit
je connais très bien
le logiciel chef
de automatisation.
Et en fait,
je me suis aperçu très souvent
en travaillant aussi bien
avec la communauté
dans les sociétés où j'étais
que les gens avaient tendance
à faire
comme ils avaient l'habitude
de faire à la main.
C'est-à-dire que
si jamais ils lançaient
la commande 6ctl
pour aller
mettre un paramètre
du carnel,
si jamais
ils utilisaient
quantité sur un serveur
plein de méthodes,
souvent ils avaient tendance
à les réutiliser
la même chose
dans le logiciel
de automatisation.
Ça veut dire à exécuter
la même commande 6ctl
avec un exécut
avec...
ça va dépendre
de votre logiciel d'automatisation.
Et donc on s'aperçoit très vite
que ça pose des problèmes.
Ces commandes-là
sont rarement immutables,
par exemple.
Elles peuvent poser des
soucis.
Et en fait,
en ayant vu tout ça,
c'est vraiment quelque chose
qu'on voit très souvent
des commandes
des commandes mises.
C'est l'exemple aussi
du Bache,
quand des gens
font des scripts Bache,
c'est vraiment l'exemple
de commande qu'on aurait fait
à la main.
On va twequer
quelques petits ifs,
quelques petits forts
autour,
et encore quand on sait les faire
en Bache.
Et au final, on arrive
à quelque chose qui essaye
d'arriver à un résultat.
Mais c'est vraiment
les mêmes commandes
qu'on aurait fait à la main.
Ce que j'en conclut de ça,
c'est que vraiment,
en fait,
il y a une différence
entre faire ce qu'on aurait
fait à la main,
la mécanisation.
C'est-à-dire vraiment
avoir un automate
qui fait des choses...
un automate humain,
comme on le faisait avant.
Même pour reprendre l'histoire,
les premiers automates,
c'était par exemple
des personnes
qui jouaient sur des pianos.
Donc c'était des automates
qui allaient vraiment
piano-ter sur un piano
existant.
Mais qui faisaient
exactement toujours la même séquence
de manière indifférenciée.
Et en fait,
le problème de ce type
de solution,
c'est que très vite,
même dans l'histoire,
ça se cahit pas.
On s'en est aperçu
au moment de l'industrialisation,
par exemple,
et quand il a fallu
produire des voitures en masse,
ou vraiment,
même avoir une production
en masse,
de quel que soit les objets,
il a fallu repenser entièrement
la façon dont on
faisait les choses.
L'exemple que je donne souvent,
c'est celui des...
des pommes de terre.
Et comment on fait des frites ?
À la main,
si vous allez chez votre grand-mère,
le week-end,
vous savez qu'elle va
éplucher de manière
consciencieuse les pommes de terre.
Elle va les couper
en lamelle,
ou en frites,
les mettre dans une friteuse,
les faire cuire,
et ça sera très bien.
Maintenant,
en fait,
pour montrer vraiment la différence,
qu'est-ce que ça voudrait dire
de mécaniser ce processus-là ?
Par exemple,
ça existe déjà,
si jamais vous voulez
couper en frites vos patates,
il existe des moules
que vous allez mettre,
vous mettez la pomme de terre,
vous appuyez très fort,
et ça vous sort des frites.
Voilà une mécanisation,
un exemple de mécanisation.
C'est-à-dire,
au final, c'est la même chose qu'un couteau,
c'est juste qu'on la fait
un peu à la main,
un peu...
un peu mieux.
Si jamais
vous avez envie d'éplucher,
il existe des épluches légumes,
on enfonce le légume,
ou la pomme de terre,
quelque chose,
on tourne,
et il y a un espèce de petit...
de petit éplucheur
qui vient enlever.
En fait,
le problème,
si vous le voyez très vite,
c'est qu'on fait ça
vraiment quand on a beaucoup
de pommes de terre à faire.
On a des risques
que ça ne marche pas,
il faut des bras robotiques,
enfin,
il y a une compréhension
de l'outil qui doit être là.
Donc en fait,
qu'est-ce qu'on fait les ingénieurs
pour faire des frites,
toujours dans mon exemple,
pour éplucher,
pour éplucher la pomme de terre.
En fait, ce qu'ils vont faire,
ils vont utiliser le principe
que la pomme de terre cuite
devient plus molle.
Donc, ils suient cuire
très vite, très fort,
en brûlant un peu la surface,
pour faire en sorte que
juste l'épiderme de la pomme de terre
soit ce cuit.
Et après,
un soufflet,
et la partie dure reste,
le cœur de la pomme de terre,
et la partie molle par la croute.
Pour mieux,
on voulait enlever cette partie.
Après, pour faire des frites,
bon, bah simple,
on prend une patate,
on la lance dans un filet,
et puis ça fait des frites,
il y a juste un cadrillage,
et voilà, on a la sortie,
on a de jolis frites.
Et enfin, pour les cuir,
il suffit de mettre les frites,
pour les cuir le bon temps,
de les mettre dans un bain d'huile
qui reste là,
mais les frites,
elles avancent au fur et à mesure,
elles arrivent dans le bain d'huile
froide et pas cuite,
elles sortent à la fin,
tout cuite exactement le même temps,
parce que toutes les frites
sont partis à la même vitesse.
Voilà, par exemple,
un exemple de vraiment
de repenser le processus
dans le cadre industriel.
Appliquer un informatique,
bah souvent,
ça revient à peu près à la même chose.
Des fois, c'est repenser.
Si je donne l'exemple de 6ctl tout à l'heure,
très souvent,
exécuter la commande 6ctl,
c'est pas forcément un choix judicieux,
fonction de la distribution
sur lequel vous allez être,
ou même,
enfin, ou même, vraiment, oui,
le contexte,
la commande 6ctl peut ne pas être présente,
elle peut aussi avoir évolué de version,
les options que vous allez utiliser
ne vont plus être là,
est-ce que vous utilisez les options courtes,
les options longues, etc.
Donc, souvent,
il vaut mieux aller directement,
se tracasser peut-être un peu plus,
mais aller directement taper
dans les appels systèmes
qui doivent être faits,
et d'avoir quelque chose
qu'on peut programmatiquement
simplement faire
en allant changer les appels
au bon endroit.
C'est peut-être pas le meilleur exemple
6ctl, mais la philosophie est là.
C'est-à-dire que vous pouvez toujours
redécouper votre problème
d'une autre façon
pour arriver à quelque chose
qui a le but d'être industriel
et qui va marcher tout le temps.
C'est le cas de l'échec,
c'est-à-dire que vraiment,
si jamais vous avez 1% de chance
que ça foire,
mis à l'échelle,
sur 1% va devenir votre quotidien.
Donc, le but, vraiment,
c'est d'aller changer ça.
Et donc, c'est là
où on passe à l'automatisation,
c'est vraiment
de vraiment avoir quelque chose
qui va fonctionner.
D'ailleurs,
petit à petit, à partait,
dans le livre et ses reboucs
de Google,
il y a même cette distinction-là,
c'est-à-dire qu'en fait,
ils ne parlent pas
de mécanisation et de automatisation,
mais ils vont faire une différence
entre automatisation et automatique.
Le but dans un SRE
n'est pas d'automatiser.
Le but est de rendre
le système automatique,
c'est-à-dire qu'il va réussir
à se faire de...
à se réparer tout seul, par exemple.
Ça va être encore ça
la distinction qu'on va pouvoir faire.
Moi, je vais pas parler d'automatique,
mais de mécanisation
versus automatisation.
Voilà.
J'espère que vous l'êtes assez...
assez précis tout à fait.
Et très clair.
Pas de questions, auto-or...
Si c'est...
pas vraiment une question,
c'est plutôt une remarque, en fait.
T'es...
dans ta logique
et dans ta démarche,
ce que tu essaies de dire,
c'est que tu dois...
fin...
c'est de remettre en cause, en fait,
l'essence même de l'outil,
parce que l'outil, c'est...
c'est quelque chose qu'on tient
dans la main,
c'est issu du travail de l'homme,
c'est pour aider l'homme,
c'est pour assister l'homme,
et...
et...
il y a une...
il y a une composante anthropomorphique,
en fait, dans l'outil.
Et toi, tu essayes de sortir
cette composante humaine
de l'outil, complètement,
et de faire en sorte
que ça soit la machine pour la machine,
et en cela,
il faut sortir du contexte humain,
et c'est ce que tu essaies de dire, en fait,
c'est sortir l'humain de la machine
pour faire en sorte que la machine...
Je suis...
On te plus d'accord, c'est vrai,
c'est quelque chose dont j'ai vu,
que je n'ai pas abordé,
mais c'est vrai que souvent, en fait,
il est difficile d'appréhender
certains problèmes
à l'un de ce qu'on fait quotidien.
C'est pour ça que, par exemple,
quand on parle d'orchestrateurs
ou de choses comme ça,
les opérations faites par un orchestrateur
peuvent paraître complètement démentielles
quand un humain essaie d'y réfléchir,
enfin, faire des vérifications,
à avoir des implications, etc.
C'est que, en plus,
la plupart des checks vont être valides.
C'est-à-dire, un humain ne les ferait pas,
parce qu'il sait que ça va marcher.
Quand on parle d'un ordinateur,
et là, dans l'automatisation,
il va y avoir énormément d'actions
qui vont être du bruit,
de l'action qui n'a pas de buts,
qui n'a pas de sens,
mais elle n'est pas grave
dans le cadre d'un ordinateur.
Et c'est là, vraiment,
où il faut repenser les choses
et arrêter de penser, comme tu le disais,
à l'outil et cette chose liée à l'humain,
mais repenser ça de manière très différente.
C'est chiant, je suis vraiment très d'accord.
Est-ce que ce ne serait pas lié
des questions de biais
que l'humain ait biaisé de nombreuses manières
et que l'ordinateur ne les l'est pas ?
Et donc, du coup,
faire confiance à l'ordinateur
pour qu'il fasse ce qu'il doit faire
de la manière dont on lui a dit de la faire,
du coup, de ne pas avoir dit des préconçus
et d'historique et d'inertie
dans la réflexion,
mais vraiment qu'il se concentre
vraiment sur un script à exécuter,
sur une liste de tâches,
et vraiment, désolé, je ne sais pas comment finir, ça...
Non mais ça en fait partie, en effet.
C'est quelque chose de notamment
quand on déploie des logiciels
qui peuvent être assez compliqués.
On a des fois ce biais-là
où pour déployer des clés, par exemple,
de sécurité, c'est toujours problématique
quand on essaie de faire les choses
qu'on aurait fait à la main
en utilisant les mêmes outils,
parce que quand on a un humain,
en fait, il y a plein d'implications
qu'on arrive à comprendre immédiatement
et qu'une machine automatique, type chef
ou un orchestrateur, quel compte,
ne peut pas faire.
Et donc, souvent, il faut repenser le problème,
décentraliser les clés avant un autre outil,
créer des outils, en fait, et c'est là
où d'un coup, on arrive dans le DevOps
et dans la partie où des fois,
il faut créer des outils pour permettre ça.
Un exemple que je vais te donner,
par exemple, dans une de mes précédentes sociétés,
on avait le souci de configurer le réseau
sur des machines qu'on envoyait chez les clients.
La configuration se faisait dans une interface web
codée en Django.
Le problème, c'est que donc,
les machines c'est du débian,
un développeur, pour mettre du réseau,
qu'est-ce qu'il fait ?
Il va toucher dans OTC Network Interfaces.
Et il met les configurations
et il fait un joli networking restart.
Dans le cadre du quelque chose d'automatique,
qu'est-ce que ça implique ?
Ça implique énormément de choses,
c'est-à-dire déjà Django de tourner en route
pour pouvoir aller modifier TSC Network Interfaces.
En plus, derrière,
c'est ça...
Configurer vraiment le réseau,
en faisant le réseau,
c'est vraiment quelque chose de très compliqué.
Faire de manière basique, ça va,
mais quand il commence à y avoir
plusieurs interfaces, etc.,
le TSC Network Interfaces,
c'est vraiment une interface...
enfin, c'est une interface de gestion du réseau
qui est vraiment basique,
humainement très compréhensible.
Mais pour une machine,
déjà, il y a un niveau d'abstraction
en script BAS, Shopper, etc.,
qui est vraiment très fort.
En fait, au final,
ce que j'ai fait,
c'est que j'ai créé un petit blob,
go, mais qui écoutait sur un socket,
UNIX,
donc ça veut dire que la communication
de PSR en HTTP reste
mais liée à la machine,
avec les droits qui vont bien.
Le blob, lui, était route,
pouvait faire des réseaux,
pouvait faire des opérations réseaux.
Mais surtout, il n'allait pas toucher
le TSC Network Interfaces,
mais il allait directement,
allait à plein et link,
et allait, donc,
il allait taper dans la Librarie
des réseaux de Linux,
et directement,
faire les actions,
au lieu de passer par
y-at-a-nozor abstraction
qui est faite pour un instrument.
Ok.
Voilà.
On va passer à la suite.
Une dernière petite remarque,
parce qu'il a quand même
soulevé la question des algorithmes.
En gros,
il faut faire attention.
Aujourd'hui, on parle de technique
pour la technique,
pour l'infrastructure,
ou du développement.
Mais se faire diriger par des algorithmes,
ça soulève de nouvelles questions
qui pourront être abordées,
je pense, dans un peu plus vite.
Donc, c'est juste,
il y a un petit warning,
attention à l'algorithme
qui gouverne
et qui prend des choix
à ne place, simplement.
Bon.
Barc qui est anti-Google Home,
alors, on va passer, finir les chroniques
avec les armes du DevOps.
Alors, en effet,
pour ce numéro d'ouverture,
je vous propose d'aborder
un sujet légèrement sympathique
qui a été teasé,
de multiples reprises,
juste avant.
C'est donc,
une chronique qui vous parlera
d'arme, de conflit,
et plus généralement,
de résistance.
Car oui,
notre activité quotidienne
dans la IT
est riche de passion,
de bataille,
voire parfois de petites luttes,
clandestines.
Et si de temps en temps
ces passes d'armes nous échappent,
ou si nous les fuyons,
telles les anguilles,
elles forment,
malgré tout, la richesse
et le sel de nos journées.
Eh, on gêlerait des regards
qui s'échangent,
qu'est-ce qu'il est en train de dire ?
Dans ces situations,
les plus conciliants
chercheront le compromis avant tout,
alors que d'autres iront lutter
pour leurs idées
et accuseront les coups
jusqu'à en jeter les ponches.
On voit même
les plus téméraires d'entre nous.
Et je regarde Guillem
qui pourra témoigner anonyment
la fin de cette chronique.
On voit même les plus téméraires
d'entre nous,
abandonner tout espoir
et déserté
pour de meilleures horizons.
C'est donc,
au travers de cette thématique
que je voulais vous parler
de nous, du DevOps.
Et de ce que peut nous offrir
en pratique
ce modèle de collaboration
face à des cas tendus.
Attention.
Chante DS,
la colère d'Achille,
fils de Pellé,
détestable colère qui,
aux Achaeens,
valut des souffrances
sans l'ombre.
Liliade d'Homère,
dès ses premiers vers,
place la colère
au centre de son propos.
Ce n'est pas un hasard
si les philosophes
se sont très tôt
intéressés à cette émotion,
car il s'agit bien
d'un très humain ancestral.
Et pour le résumer grossièrement,
il fallait, selon ses mêmes penseurs,
la dompter,
la privoiser,
la bannir
ou simplement
par sa geste,
l'éviter.
On peut très simplement
retrouver ce même thème
dans nos mythes modernes.
Par exemple,
dans l'illustre saga Star Wars,
c'est bien la colère
qui mène au côté obscur.
Elle permet alors
l'accès à une puissance,
immense,
mais tout autant
corruptrice
et destructrice.
Dans le comics américain Hulk,
c'est également
le déclencheur
de la transformation
d'un homme
en colosse herculéen.
Ces légendes populaires
n'ont donc jamais
de cessé
d'illustrer
cette tempête
qui anime nos coeurs
et nos actes.
Symbol de l'affirmation
de soi,
processus de défense
ou encore marqueur
d'une volonté,
d'une volonté
altruiste,
ont tenu que la colère
est un moteur
ou un vice
universel.
Et c'est bien ce processus
qui nous motive au quotidien.
La rage de voir se répéter
les mêmes problèmes,
la colère d'entendre
proposer des solutions identiques
pour tous les besoins,
le désespoir de voir
les équipes produits
se défausser de leur responsabilité
via d'habile manœuvre d'évitement
ou enfin la déception
de subir le maintien
de force,
des modes de fonctionnement
du passé.
Je pense qu'on a chacun
pu assister au désamorçage
de tentatives de changement
ou de projets
jugés trop disruptifs
tourneurs
lors de nos carrières.
Fontez-moi non.
Il s'agit donc
dans des moments comme cela
de répondre en bons dévops.
Avant même d'aller plus loin,
il faut être conscient
que la chose la plus simple
au quotidien
est d'opérer un changement
des esprits
et gagner la bataille de la culture.
Le réflexe est simple.
Il s'agit d'être inclusif
– on l'a répété
quand cette émission –
de donner une confiance absolue
à ses collaborateurs
et de corriger systématiquement
les marqueurs de dédain
ou de supériorité
que l'on entend souvent au quotidien.
Il faut donc se placer
du côté du bien,
celui de l'indiscutable,
cesser d'opposer les eux
ou nous
et par cela infuser les idées
des devops
au sein même des esprits
de votre entourage.
Confucius lui-même écrivait
«Si j'avais le pouvoir,
je commencerais par donner du sens
aux mots.
Et c'est en cela
que se battre sur le terrain du
langage va permettre de donner
– pardon – du langage
va permettre de donner corps
aux problèmes sous-jacents.
De les identifier
et de mettre au clair les nondis
qui polluent les projets
et les relations.
C'est en mettant les équipes
en défaut face au concept
des devops
et en se plaçant comme héros
de la collaboration
que vous pourrez aller plus loin
dans ces concepts.
Par la même occasion,
vous serez possible d'identifier
les conservateurs acharnés
qui barreront la route
à toute évolution,
les sortant alors
de leurs zones de confort.
C'est donc ici
une guerre psychologique,
une guerre des mots,
celle qui oriente les esprits
par le martellement
des mêmes vérités
pour, au final,
transmettre aux gens
le réflexe
et la logique des devops.
Ah, je crois qu'on me fait signe
de côté de la table.
Tout cela, c'est bien beau,
mais je suis censé être devops.
J'ai l'impression d'être toujours coincé
dans un gros silo.
Donc, même en changeant les mots,
ma structure n'accorde visiblement
pas de place
aux devops.
Qu'est-ce que je fais ici ?
Bien, disons-le,
une bonne fois pour toutes,
vous êtes une victime
du devops bashing,
devops washing,
sorry, pour mon anglais,
et ce, comme beaucoup d'autres.
C'est peut-être le contre-coup
d'une direction
ou d'une politique manageriale
qui ne sait absolument pas
comment amorcer un changement
et qui se rassurent
avec des modèles connus,
d'une entreprise qui veut rester
dans l'air du temps
sans connaître le modèle à suivre.
Peut-être, même s'agit-il
simplement d'une question
de recrutement,
ou est-ce encore la résultante
d'une transformation échouée
que sais-je ?
Là, n'est pas la question.
L'important à retenir ici,
c'est que tout n'est pas perdu.
Vous avez le principal.
Le titre de devops,
vous pouvez désappréz-en
prendre ce badge qui vous est dû,
l'accrocher à votre t-shirt,
docker préféré et foncé.
Quand on se saigne en son droit,
on entre plus facilement en résistance
et cela donne assez propos
un écho supplémentaire.
Grâce à cela,
il est légitime d'aller voir,
seul s'il le faut.
Les équipes clients
s'intégrer voire même s'immerger
dans leur univers,
faire partie de leur quotidien
pour capter leurs besoins
avant même leur formalisation concrète.
Logiquement,
vous devrez délaisser
quelques précédentes taches
et en cela,
vous serez peut-être coupables.
Mais rappelez-vous
que votre ligne défensive
est le devops
et qu'il ne vous est pas opposable
en l'état.
Finalement,
vos meilleurs armes
seront vos résultats.
Vous pourrez facilement
mettre en avant le bien fondé
de cette démarche
la valeur ajoutée
pour votre produit.
L'identification,
la classification
des nouveaux besoins émergents.
Plus que tout,
vous pourrez également
ériger la collaboration
et la confiance mutuelle
en tant que valeur fondamentale.
Enfin,
vous brandirez fièrement
la satisfaction
et la confiance
de vos utilisateurs.
La rapidité de mise en place
des changements, des tests,
des facultés nouvelles
de déploiement
seront vos étendards.
En mesurant et comparant
factuellement l'évolution
de chacun de ces points,
vous achèverez simplement
vos détracteurs,
souvent armés de mauvaise foi
ou d'a priori.
Alors, certes,
ce n'est pas simple.
Pour toujours aller vers le mule
plus adapté,
il faudra jongler
avec les contraintes
des différents intervenants,
parfois se conformer
à des process
issus d'un autre temps.
Mais dites-vous
que si le bilan
n'est pas concluant
sur le plan professionnel,
il vous restera
au moins la satisfaction
d'avoir personnellement avancé
et de vous être engagé
sur un modèle
que vous savez juste.
Après tout,
la force est avec vous.
Je pense qu'on peut rajouter
des applaudissements.
C'est beau.
C'est très beau.
Vous pouvez discuter.
C'est un petit peu long,
j'admets, mais...
Non, non, vraiment bien.
Je ne sais pas d'inscrider.
Il y a juste quelque chose
que je vais rebondir
sur ce que tu as dit.
Ce n'est pas la colère
qui mène à la souffrance,
c'est la peur.
C'est la peur.
Je pense que ça,
c'est aussi quelque chose
qu'on peut rajouter.
Il y a aussi ce côté peur
chez les autres,
même chez tous,
chez qui existe.
La peur du changement.
La peur du changement,
la peur de perdre sa place,
la peur de plein de choses,
en fait.
Tout simplement,
c'est le changement
qui n'a pas, franchement,
mon sens.
C'est la peur
qui mène à la colère.
Tout à fait.
Je ne sais pas si vous avez...
Vas-y, vas-y.
J'avais une remarque
ce que tu dis.
Il faut, en gros...
En tout cas,
est-ce que t'aurais quelques conseils
à donner pour réussir
à convaincre le management
qui pourrait opposer
de la résistance
au changement?
Justement.
Tu veux les conseils de...
Aristo,
de ma grand-mère.
C'est toujours compliqué
de donner des conseils universels,
mais est-ce que t'aurais
quelques tips?
Des quick wins.
Des quick wins.
Des quick wins.
Peut-être.
C'est difficile.
C'est très difficile.
Si vous n'avez pas un management,
alors que ce soit un management
de la direction
ou un management de proximité,
qui vous est favorable,
vous partez avec un énorme malus.
Vous le savez,
vous allez évoluer
avec cet énorme malus.
En revanche,
vous allez pouvoir, comment dire,
lancer un mouvement.
Éventuellement rassembler
des gens autour de vous
et essayer de donner des exemples.
Comment dire, pas des quick wins,
mais des wins stories.
Je ne sais pas comment
pour dire ça,
mais des cas d'usage
où vous avez appliqué certaines
choses,
où vous êtes allés voir les gens,
vous avez outrepassé
certains process
pour appliquer,
je ne sais pas, des moments,
mais pour nous,
un processus de déploiement
nouveau,
et ça a marché.
Voilà.
Vous avez aidé les gens
et vous êtes allés vite,
parce que c'est ça qui compte.
À partir de là,
vous avez coché
une grande majorité
des cases des DevOps.

après,
si il n'y a aucune réception
assez point bonus,
il y a d'autres solutions.
Il y a d'autres solutions,
par exemple,
appliquer la loi des deux pieds.
C'est ça.
C'est-à-dire,
si ça ne vous plaît pas,
si vous n'apprenez rien,
barrez-vous.
Je l'ai dit tout à l'heure en actu,
je vous rappelle que
beaucoup de sociétés
sont très intéressantes,
commencent à venir à Paris
et vous recherchent.
Et si jamais vous avez ces zones-là...
À Paris ou d'autres réglementations.
Et à Paris,
même à autre réglementation,
même à l'international,
si vous parlez étranger.
L'étranger.
Mais non, non, très instructif.
C'est pas marqué si t'as un...
Non, j'ai pas grand chose à ajouter.
Je pense que tout a été dit.
Je pense que tout a été dit.
Donc, je vais d'abord remercier
tous les participants ce soir
pour leur travail,
leur intervention
et leur motivation.
Et puis,
je vais vous laisser là-dessus.
J'espère déjà que ça vous a plu,
que vous nous ferez des retours
aussi bien en live,
en meet-up,
sur Internet.
Les endroits où vous les écouterez,
on espère que vous allez vous aborder.





Et vous allez avoir vos commentaires,
parce qu'on est aussi agile là-dessus
et qu'on va aussi adapter
en fonction de tous les retours.
Donc,
merci à vous aussi d'avoir écouté.
Et on vous dit au revoir.
La prochaine surtout.
Au revoir.
Ça, à la prochaine.