Dev'Obs #1 / Blue/Green, Fails, Automatisation

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, Barthélémy. Donc oui, Barthélémy Vessemont, DevOps chez Criteo actuellement. Et j'ai un background Ops, tout simplement.

Moi je suis Marc Falzon, j'ai 32 ans je suis Ops depuis un peu plus de 10 ans et je travaille actuellement chez D2SI où je suis consultant cloud et automatisation Et moi Victor de Monchy DevOps aussi avec un background Ops je travaille chez Criteo dans la même équipe que Barthélémy Et enfin moi Guillaume Letron, donc je suis DevOps ascendant Ops et je travaille à l'heure actuelle chez Vente Privée, Donc maintenant on va passer à une petite rubrique qu'on va essayer de garder

à chacun de nos podcasts casse, 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, donc habituellement des sysadmins, 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 ops dans une même équipe et attendre que la magie opère. Sans faire de mauvais jeu de mots. 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 du code qu'ils produisent et prendre conscience que leur job ne s'arrête pas après avoir un comité dans Git, mais à le déployer et à le porter en production, se porter garant du bon fonctionnement et de ses performances en production.

Et de leur côté, les Ops doivent être transparents quant à l'infrastructure qu'ils construisent et qu'ils opèrent et ils 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é, j'ai pas trouvé mieux comme terme, est bénéfique pour les deux parties.

Des développeurs qui sont plus infantilisés, mais plutôt responsabilisés, seront plus à même de faire ces quelques pas supplémentaires vers l'exploitation d'un service en production et même potentiellement proposer des changements d'infrastructures pertinents ou tout du moins d'ouvrir la discussion avec du recul et une perspective différente des Ops.

Les sysadmins proactifs plutôt que réactifs à toujours régler les problèmes quand ils arrivent, capables de mettre la main à la pâte en termes de développement d'outils internes plutôt que du vulgaire scripting entre guillemets. Travailler sur les concepts de déploiement et d'observabilité offre aux devs de la visibilité sur leurs services et bénéficient de leur aide en cas d'incident ou même en simple cas d'optimisation de l'infrastructure.

Super, très complet, je pense qu'on ne peut plus être 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 vais demander à Victor peut-être de commencer une petite actu que tu as pu voir cette semaine. Alors, cette semaine, non. Par contre, c'était 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 n'ont 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. En l'occurrence, je l'avais vu sur Twitter, en fait. D'accord. Marc ? Eh bien, écoutez, moi, j'é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, Java pourra enfin tourner convenablement. Désolé, c'est gratuit. Voilà, petit instant troll. Voilà. Barthes ?

Pour ma part, ce n'est pas très lié au DevOps, mais c'est un petit anniversaire parce qu'il y a sept semaines, en fait, je crois que c'était lundi, c'était l'anniversaire des 10 ans d'ITER, 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 ses 10 ans. Et voilà, le projet est toujours en marche. Il, on espère le voir aboutir de notre vivante. Très bien. Et alors, pour moi, la petite actu 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 tomber 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 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. Et ça fait quelques années déjà que ça commence à l'être. On pourrait noter Docker qui a ouvert des bureaux à Paris, etc. Vraiment, il commence à y avoir pas mal de sociétés qui se mettent, Datadog aussi par exemple. 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, on l'a fait au tirage au sort. Donc Marc va nous parler du Blue-Green Deployment et je le laisse parler. Voilà, donc effectivement on va parler aujourd'hui de la méthode de déploiement Blue-Green et de Canary Deployment.

Donc qu'est-ce que c'est que le Blue-Green Deployment ? c'est une technique de déploiement sans coupure, sans downtime, qui permet un retour arrière rapide en cas de complications et instantané. Le principe, c'est de disposer de deux plateformes applicatives si possible 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, en version N plus 1.

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 du coup possible de réaiguiller 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 plus 2, 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 plus 1, 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 lot de frontaux, par exemple, et donc du coup, de déployer la nouvelle version N plus 1 sur un seul des supports applicatifs, un serveur ou une instance de VM,

par exemple, et donc qu'elles ne reçoivent 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 progressivement.

Ce sont des techniques qui sont assez souples et pas forcément très complexes à mettre en œuvre 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éploiement pour faciliter un petit peu les mises à jour de versions et transparents. J'ai terminé. Super. Donc là, on va commencer un petit débat maintenant, parce que je sens 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éploiement ? J'ai joué avec, prototypé avec, 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 prototypage. 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à été confronté à ce genre de problème-là, c'est comment on fait avec une base de données. Genre MySQL, tout simple, toute bête, parce qu'on est quand même dans un cas d'usage quasiment majoritaire dans de petites applications, comment on fait pour assurer la pérennité de à la fois la version N plus 1 et la version N pendant cette phase de migration, en fait ? 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émas de base de données, notamment, c'est là que le bas blesse.

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 structure 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 du coup une fois qu'on a

validé que le bon fonctionnement le bon faussement de la nouvelle version. Ça ne demande pas plus de travail pour les développeurs ? 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 ? Au début du cycle de vie d'un logiciel, par exemple, on sera amené beaucoup plus facilement à faire ce genre de changements-là.

Peut-être que ce n'est pas le moment aussi, on va vouloir utiliser à tout prix le Blueground Deployment. Oui, c'est pas un incontournable. Si jamais le projet est tout début, critique, etc., c'est qu'il y a peut-être un problème dans la définition. Je pense que pour tout ce qui est StateLight Web Service, ça ne pose 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, j'aurais tendance à ne pas trop utiliser ce genre de système.

Alors peut-être, comme dit Marc, on peut prévoir des procédures de migration, mais je trouve que ça rend le truc un peu trop compliqué. Peut-être qu'ils n'aient pas la bonne méthode de déploiement. Je vous... Pardon. Non, mais vas-y. Je vous recommande, juste pour 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 Blueground Development n'est pas forcément fait pour vous, il y a une autre technique. Sinon, c'est le feature flapping ou le 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'aurais tendance à 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 salir, entre guillemets, son code avec beaucoup de switches, de ifs partout. Et ça, les développeurs, en effet, seraient peut-être pas forcément enclin à le faire.

C'est une philosophie et ce que ça peut amener, ça peut apporter en plus, c'est une finesse dans le choix que l'A-B 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 switching. Le switching, oui. Toggling. Le feature flag. Le feature flag. Le feature flipping aussi. Voilà.

Et en fait, Cette méthodologie-là va permettre une granularité beaucoup plus importante et qui peut être intéressante pour les développeurs. Je suis d'accord avec toi. Dans un autre contexte, c'est 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 teaser, 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, 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 et chèque pour qu'on soit bien d'accord sur la définition. Donc, il faut savoir que la culture, au sens large, on peut la définir de plein de façons différentes. Mais une des définitions que j'ai cherchée, forcément, quand j'ai préparé cette chronique, et que j'ai trouvée, qui me semble plutôt bien servir le propos, c'est selon un sociologue québécois, qui s'appelle Guérocher.

Donc, la culture est un ensemble lié de manières de penser, de sentir et d'agir plus ou moins formalisées, 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 je ne vous ai pas perdu. C'est complètement, mais on va suivre le reste. Ok, c'était un peu l'instant culture. Ça sera un peu moins abstrait après. Maintenant, on passe à l'échec.

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. Et donc, ça c'est pour l'aspect culture. Pour la partie culture. 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 abouti au résultat escompté. Voilà. C'est 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 d'échouer par peur de laisser un avantage décisif à ses concurrents, par exemple si on parle au niveau business, ou même par peur de d'avoir une mauvaise note à sa, notation biannuelle s'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. Comme on sait tous, c'est difficile de prévoir toutes les issues possibles d'un projet quand on le démarre, sauf si on veut essayer de faire du bon gros waterfall, des familles.

Mais plutôt que de faire ça, on peut se dire, à un moment donné, on définit la direction générale vers laquelle on veut aller quand on 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, en fonction du retour 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'itération assez rapide, en théorie efficace, entre les différentes équipes.

Et donc, comment on pourrait appliquer ça concrètement dans le DevOps, justement ? Ce que je viens de dire, c'est 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 que 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 ne va au final pas marcher ou ça va aboutir à un truc tellement compliqué que ça ne 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 n'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 comme on voulait il faut ensuite débattre ensemble de ce qui n'a pas marché et en tirer des leçons pour pas reproduire les mêmes échecs plus tard et surtout quelque chose. Peut-être d'encore plus important c'est de ne 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. Il ne faut pas le rejeter sur quelqu'un qui prend très mal le livre. Donc, ce que je veux dire, c'est que ça coûte moins cher d'accepter l'échec qu'on signe dans une voie, plutôt que de... Voilà, que de... Enfin, ce sera ma conclusion.

D'accord. Plutôt que d'une voie sans issue. Alors, je vais te reposer la même question, c'est que j'ai pu poser tout à l'heure à Marc. Est-ce que tu as pu déjà vivre ce type de condition de travail, cette philosophie en tout cas ? Ouais, j'ai déjà pu vivre ça. C'est quand on arrive dans une boîte, par exemple, et qu'on nous donne un projet sur lequel on a un regard nouveau, parce qu'on ne faisait pas partie de cette boîte avant.

Donc, on arrive avec un regard nouveau, on voit le truc, on se dit, mais ça ne peut pas marcher, pourquoi vous faites ça ? Il faut tout refaire, ça ne va pas du tout. On dit, non, mais ça marche comme ça depuis des années et tout. Mais 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 tout redévelopper et même quand on dit ç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. Moi, j'ai remarqué depuis quelques années cette tendance des grands du web à faire ce qu'ils appellent le blameless post-mortem, que j'aime beaucoup.

J'aime beaucoup cette démarche-là, en effet, de faire l'introspection sur quelque chose qui a merdé. 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 rajouterais aussi que peut-être pour des fois atténuer ce type de problème, c'est de mettre toute l'équipe, t'as parlé de la feature sim c'est même aussi la notation d'équipe c'est quelque chose qui permet 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, et bien ça se passe mal c'est forcément de sa faute, ou en tout cas c'est lui qui va être pénalisé,

mais en ayant une notation d'équipe en prenant tout le monde encore, mais il peut y avoir toujours une notation individuelle, mais vraiment dans l'aspect RH, quelque chose qui peut faire changer c'est vraiment aussi cette notation d'équipe, quelque chose que je vois in fine 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à.

Pondérés dans la note finale pour des raisons x ou 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 biannuels qui sont reflétés sur nos résultats. Alors qu'on est demandeur. 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 ou en tout cas dont 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 à quelque chose où les gens se mettent en avant de manière extrêmement forte au-delà même du projet pour que eux, leur visibilité se le soit 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 ne sais pas, Mathieu ? En tout cas, on sent qu'il l'a écrit avec le cœur et qu'il était attaché à ces problématiques-là. Non, c'est sûr que c'est un problème. J'espère que ce n'était pas trop abstrait, en tout cas. Peut-être un petit peu, pour une première chronique, je pense que ce n'est pas forcément très concret. 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 à cœur depuis un petit moment.

En fait, dans le cadre de mon expérience, je me suis, enfin, je connais très bien le logiciel chef d'automatisation et en fait je me suis aperçu très souvent en travaillant aussi bien avec la communauté que 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 CCTL pour aller, mettre un paramètre du kernel si jamais ils utilisaient quand ils étaient sur

un serveur plein de méthodes souvent ils avaient tendance à aller réutiliser la même chose dans le logiciel d'automatisation, ça veut dire à exécuter la même commande, si c'était elle, avec un execute, ç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, parce que c'est vraiment quelque chose qu'on voit très souvent, des commandes mises, c'est l'exemple aussi du bash. Quand des gens font des scripts bash, c'est vraiment l'exemple de commandes qu'on aurait fait à la main. On va tweaker quelques petits if, quelques petits for autour et encore quand on sait les faire en bâche et au final on arrive à quelque chose qui essaye

d'arriver à un résultat en tout cas. Mais c'est vraiment les mêmes commandes qu'on aurait fait à la main.

Ce que j'en conclue 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, donc 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 pianoter 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 ne se cahit pas. Ce qu'on a 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 quels que soient 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 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 lamelles ou en frites, les mettre dans une friteuse, les faire cuire, et ça sera très bien. Maintenant, 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 qu'au final, c'est la même chose qu'un couteau, c'est juste qu'on l'a fait un peu à la main, 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 dans quelque chose, on tourne et il y a une espèce de petit. Éplucheur qui vient enlever. Le problème, si vous le voyez très vite, c'est comment on fait ça à l'échelle, comment 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, 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, il suffit de 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 cuit.

Après, un soufflet, et la partie dure reste, le cœur de la pomme de terre, et la partie molle part, la croûte. Tant mieux, on voulait enlever cette partie. Après, pour faire des frites, bon, simple, on prend une patate, on la lance dans un filet, et puis ça fait des frites.

Il y a juste un quadrillage, et voilà, on a la sortie on a de jolis frites, et enfin pour les cuire, il suffit de mettre les frites pour les cuire 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, toutes cuites exactement le même temps, parce que toutes les frites sont parties à la même vitesse.

Voilà par exemple un exemple de vraiment, de repenser le processus dans le cadre. Industriel. Appliquer en informatique souvent ça revient à peu près à la même chose, des fois c'est repenser.

Si je donne l'exemple de CCTL tout à l'heure, très souvent exécuter la commande CCTL c'est pas forcément un choix judicieux en fonction de la distribution sur laquelle vous allez être ou même vraiment, oui, le, contexte, la commande CCTL 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ème 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 si c'était elle, 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, ce 1% va devenir votre quotidien. Le but vraiment, c'est d'aller changer ça.

C'est là où on passe à l'automatisation, c'est vraiment de vraiment avoir quelque chose qui va fonctionner. D'ailleurs, Sous-titrage ST' 501 Petit aparté, dans le livre SREbook de Google, il y a même cette distinction-là. C'est-à-dire qu'en fait, ils ne parlent pas de mécanisation et d'automatisation, mais ils vont faire une différence entre automatisation et automatique.

Le but d'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 réparer tout seul, par exemple. Ça va être encore ça la distinction qu'on va pouvoir faire. Moi, je ne vais pas parler d'automatique, mais de mécanisation versus automatisation. Voilà, j'espère que j'ai été assez précis. Tout à fait, très clair. Pas de questions autour ?

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 essayes de dire en fait c'est sortir l'humain de la machine pour faire en sorte que la machine s'assume On n'est plus d'accord, c'est vrai, c'est quelque chose que je n'ai pas abordé mais c'est vrai que souvent il est difficile d'appréhender certains problèmes à l'aune de ce qu'on fait

au quotidien c'est pour ça que par exemple quand on parle d'orchestrateur 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. C'est-à-dire qu'il faut aller faire énormément de checks, faire des vérifications, avoir des implications, etc. En plus, la plupart des checks vont être valides. C'est-à-dire qu'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 but, qui n'a pas de sens, mais elle n'est pas grave dans le cadre d'une... 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.

Je suis vraiment très d'accord. Est-ce que ce ne serait pas lié à des questions de biais, que l'humain est biaisé de nombreuses manières et que l'ordinateur ne 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 le faire, du coup de ne pas avoir d'idées préconçues, 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 cette question. Non, mais ça en fait partie, en effet.

C'est quelque chose, 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 est un humain, il y a plein d'implications qu'on arrive à comprendre immédiatement et qu'une machine automatique type chef ou un orchestrateur quelconque ne peut pas faire.

Et donc, souvent, il faut repenser le problème, décentraliser les clés, avoir 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 les machines étaient du Debian, un développeur, pour mettre du réseau, qu'est-ce qu'il fait ? Il va toucher dans ETC 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 doit tourner en route pour pouvoir aller modifier ses network interfaces.

En plus, derrière, ça a configuré vraiment le réseau. 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 network interface c'est vraiment 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 bash, perl, 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 qui écoutait sur un, socket Unix donc ça veut dire que la communication pouvait se faire en HTTP REST mais liée à la machine avec les droits qui vont bien le blob lui était root pouvait faire des opérations réseau, mais surtout il n'allait pas toucher à OTC Network Services mais il allait directement aller à PlanetLink et aller taper dans la librairie réseau de Linux et directement faire les actions,

au lieu de passer par Yet Another Abstraction qui est faite pour un être humain. 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 d'autres techniques.

Donc, c'est juste, il y a un petit warning. Attention à l'algorithme qui gouverne et qui prend des choix à notre place, tout simplement.

Bon, Barc est anti-Google Home, alors on va 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éger, fort sympathique qui a été teasé de multiples reprises juste avant. C'est donc une chronique qui vous parlera d'armes, de conflits et plus généralement de résistance. Car oui, notre activité quotidienne dans l'Haïti est riche de passions, de batailles, voire parfois de petites luttes clandestines.

Et si de temps en temps ces passes d'armes nous échappent ou si nous les fuyons telles des anguilles, elles forment malgré tout la richesse et le sel de nos journées. Il y a 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 l'éponge.

On voit même les plus téméraires d'entre nous, à m'en donner tout espoir et déserter pour de meilleurs 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 déesse la colère d'Achille, fils de Pellé. Détestable colère qui, aux Achaéens, valut des souffrances sans nombre.

L'Iliade 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 trait humain ancestral. Et pour le résumer grossièrement, il fallait, selon ces mêmes penseurs, la dompter, l'apprivoiser, la bannir, ou simplement, par sagesse, 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 cessé d'illustrer cette tempête qui anime nos cœurs et nos actes.

Symbole de l'affirmation de soi, processus de défense ou encore marqueur d'une volonté altruiste, on ne peut nier 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 leurs responsabilités via d'habiles manœuvres 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 lors de nos carrières. Fondémoinant. Il s'agit donc dans des moments comme ceux-là de répondre en bon DevOps. Avant même d'aller plus loin, il faut être conscient que la chose la plus simple au quotidien et 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é au cours de 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 » au « nous ». et par cela infuser les idées 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 corps aux problèmes sous-jacents, de les identifier et de mettre au clair les non-dits qui polluent les projets et les relations. C'est en mettant les équipes en défaut face au concept 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, il vous sera possible d'identifier les conservateurs acharnés qui barreront la route à toute évolution, les sortant alors de leur zone de confort. C'est donc ici une guerre psychologique, une guerre des mots, celle qui oriente les esprits par le martèlement des mêmes vérités pour, au final, transmettre aux gens le réflexe et la logique des votes. Je crois qu'on me fait signe de l'autre 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 au 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 managériale qui ne sait absolument pas comment amorcer un changement et qui se rassure 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 DevOps. Vous pouvez dès à présent prendre ce badge qui vous est dû, l'accrocher à votre t-shirt Docker préféré et foncer. Quand on se sait dans son droit, on entre plus facilement en résistance et cela donne à ses 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 tâches et en cela vous serez peut-être coupable. Mais rappelez-vous que votre ligne défensive est le DevOps et qu'il ne vous est pas opposable en l'état. Finalement, vos meilleures 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 mieux, le 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. Non, non, vraiment bien. Moi, il y a juste quelque chose. 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. C'est la peur. Et 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, 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 forcément le bon 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. Est-ce que tu dis, il faut, en gros... En tout cas, est-ce que tu as quelques conseils à donner pour réussir à convaincre le management qui pourrait opposer de la résistance au changement ? Les conseils de... peut-être pas d'Aristote ou de ma grand-mère.

C'est toujours compliqué de donner des conseils universels, mais est-ce que tu aurais quelques tips ? 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, pas des quick wins, mais des win stories, je ne sais pas comment on pourrait dire ça, mais des cas d'usage où vous avez appliqué certaines choses, vous êtes allé voir les gens, vous avez outrepassé certains process pour appliquer, je ne sais pas, pour nous, un processus de déploiement nouveau ?

Et ça a marché. Vous avez aidé les gens et vous êtes allé vite parce que c'est ça qui compte. A partir de là, vous avez coché une grande majorité des cases DevOps. Après, s'il n'y a aucune réception à ces points 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. Comme je l'ai dit tout à l'heure en actu, je vous rappelle que beaucoup de sociétés très intéressantes commencent à venir à Paris et vous recherchent et si jamais vous avez ces sociétés-là à Paris ou d'autres réglementations et même à d'autres réglementations et même à l'international si vous parlez étranger, voilà l'étranger l'étranger l'étranger l'étranger bien.

Mais non très instructif c'est pas marre que c'était 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, on va 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 avoir vos commentaires parce qu'on est aussi agiles 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. À la prochaine.