Bienvenue chers compagnons sur Radio DevOps, la balle de diffusion des compagnons du DevOps.
Dans chaque épisode, nous étudions l'actualité de notre mouvement ou du cloud en général.
Puis, nous débattons sur un sujet de fond.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bonjour et bienvenue dans ce premier épisode de la radio des compagnons du DevOps.
Avec moi, il y a Damir et Erwan.
Je vais laisser se présenter et juste après on va pouvoir commencer.
Damir, est-ce que tu peux te présenter s'il te plaît ?
Bonjour à tous, je me définis comme un créateur de nuages.
Je suis ingénieur cloud et DevOps à Whiskale.
Je suis passionné d'Open Source et de logiciel libre.
Je sais te partager régulièrement sur mon blog, Damir.fr.
Bonjour, moi c'est Erwan.
Je suis 6 admins de DevOps depuis un peu plus de 10 ans.
Aujourd'hui, je travaille pour une petite start-up qui s'appelle Toukantoko.
J'essaye de m'impliquer tant bien que mal dans l'Open Source sur des projets autour de la supervision.
Et moi, c'est Christophe.
Je suis le créateur et l'animateur des compagnons du DevOps.
Je suis aussi membre du collectif de frilance indépendant qui s'appelle Lidra.
Et en fait, on aide les entreprises du numérique à déployer leurs applications
sans couper leur service et à faire leur transition des DevOps en les monter en les quochant.
Et on va tout de suite commencer par les actus.
Et notamment une qui est un peu vieille, c'est la création de la fondation pour la promotion du déploiement continu.
En mars 2019, la Linux Foundation a annoncé avoir créé la Continuous Delivery Foundation
qui est définie comme une maison d'accueil indépendante pour les projets Open Source
les plus importants en matière de déploiement et d'intégration continu.
Les premiers projets qui sont hébergés par cette fondation, c'est Jenkins,
un système d'intégration et de déploiement continu Open Source.
Jenkins X qui est la même solution mais plutôt dédiée Kubernetes.
Spinnaker qui est une solution de déploiement continu Multi Cloud en Open Source.
Tecton qui est un projet et une spécification Open Source pour des composants de pipeline, intégration continu et déploiement continu.
Et enfin, ils annoncent que d'autres projets devraient rejoindre la fondation
puisque le comité de supervision technique a pour but justement de rassembler l'écosystème du déploiement continu.
Et du coup, leur objectif, en fait, avec cette fondation outre hébergée des outils de manière complètement indépendante,
c'est aussi d'apporter des spécifications pour améliorer la vie des projets
sur la portabilité et l'interopérabilité de l'intégration et du déploiement continu.
Alors, à l'origine de cette initiative, c'était un besoin de l'industrie collaborer
sur les sujets de pipeline et les flux de travaux sur l'intégration et le déploiement continu.
La fondation, en plus des outils et de la définition des pratiques,
elle a pour ambition d'aider les développeurs partout dans le monde
à améliorer en fait la robustesse de leur logiciel et à améliorer le fait de déployer plus rapidement leurs outils.
Et ils espèrent travailler avec la communauté Open Source et le leader de l'industrie
et surtout d'évangéliser les développeurs et les ops avec les méthodologies d'intégration continue,
déploiement continu et surtout du déops.
A l'origine de cette fondation, il y a 20 membres fondateurs, notamment les plus notables,
il y a Alibaba, Atos, CircleCI, Cloutbiz qui est derrière Jenkins,
Deploy Hub, GitLab, Google, HSBC, Huawei, IBM, JFrog, Netflix, Poupette,
Ransher, Red Hat et SAP et plein d'autres, puisqu'on ne peut pas tous les citer.
Pour en savoir un peu plus, on vous mettra des liens dans la description
du podcast et moi j'aimerais savoir ce que vous en pensez tous les deux.
Damir, est-ce que tu as un avis là-dessus ?
Moi je pense que ça peut être une bonne idée, notamment pour rassembler un peu tout ce qui est bonnes pratiques.
Ce serait qu'aujourd'hui les solutions de CI et de CD se multiplient quand même assez rapidement.
On le voit au marché avec des trucs comme CircleCI et des choses comme ça qui apparaissent assez rapidement.
Je pense que ça peut être vraiment bien d'avoir un endroit où se centraliser un peu les bonnes pratiques,
la bonne manière de faire pour ensuite diffuser ça au maximum de personnes possibles.
Moi je rejoins assez ce point de vue.
Après il faut voir concrètement ce qui ressortira de ce genre de fondation
et surtout comment ça va prendre.
C'est pas juste un regroupement de façades pour faire du chauf et dire que les différents partenaires existent.
C'est vrai que c'est un peu la crainte que j'ai quand j'ai vu les noms qui étaient associés,
notamment les grands noms et les premiers projets puisque les plus gros projets viennent de chez Google.
Enfin en tout cas l'annonce mettait bien gouvernant.
J'avais peur justement que ça puisse devenir un porté tendard de ces solutions-là.
Après je vais suivre ça de près.
Pour l'instant on n'a pas vraiment entendu parler plus que l'annonce en tout cas de mon côté.
Donc c'est une affaire à suivre et on verra ce que ça donne.
Erwin tu nous as préparé une petite annonce aussi, elle a fait grand bruit récemment.
Juste la nuit avant le DevOps.DD on a appris quelque chose, est-ce que tu peux nous en dire plus ?
Oui c'est la partie page rose de l'émission sur la revente de Docker de sa partie entreprise etc.
Donc c'est lié à la récente Le Betfond qui a eu lieu mi-octobre et qui accompagne toute une restructuration
au sein même de Docker avec un nouveau CEO Scott Johnson, une toute autre organisation.
L'idée qui était derrière cette revente de Docker entreprise à Mirantis, c'est de se séparer vraiment de toute l'activité,
d'hébergement, de la plateforme de conteneurs telles qu'on la connaît et de la livrer à Mirantis
qui finalement était un concurrent sur le marché puisqu'il faisait globalement la même chose.
C'était une espèce de plateforme de conteneurs sur du multi-cloud, c'était la promesse.
Ce qui est assez surprenant c'est qu'avec cette revente de Docker se sépare aussi de 300 salariés, c'est quand même pas rien.
Donc Le Betfond il allait autour de 90 millions de dollars, ce qui porte à une...
C'est censé préparer en fait une IPO qui devrait être annoncée dans les temps à venir
et tout ça pour une petite valorisation sympa de plus d'un milliard de dollars de l'entreprise.
Et pourquoi Docker fait tout ça c'est que globalement ils estiment qu'ils se sont un petit peu trop éparpillés
sur plein de choses entre le service, entre les outils, la communauté open source etc.
Et en fait en se libérant du poids du service et de leur partie plateforme, ils espèrent se recentrer,
se créer sur créer des outils pour la communauté et surtout se recentrer sur le besoin de créer des outils pour les développeurs et cette communauté-là.
Et donc toute la nouvelle stratégie de Docker est censée tourner là-dessus.
Y a Mirantis s'engage à garder les différents projets associés qui étaient open source, donc les garder aussi open source et assurer le suivi en partenariat bien sûr avec Docker.
Globalement ce qu'il faut retenir c'est que Docker, ils veulent plus vraiment faire 10 000 choses,
ils veulent juste continuer à développer leur engine et les différents outils pour permettre aux développeurs en local de pouvoir travailler dans les meilleures conditions et avec le meilleur tooling possible.
Et je ne sais pas, je ne suis peut-être pas entendu d'informations mais on sait combien a mis Mirantis sur la table pour acheter Docker entreprise ?
Les chiffres, il n'y a pas de chiffre officiel. Du coup c'est que des estimations, ce n'est pas hyper fiable.
Suivant les sources, je n'ai pas d'informations pour pouvoir te donner un chiffre exact.
Du coup ça restera un mystère. Damir, t'en penses quoi ?
Moi je vois surtout que c'est un constat un peu triste pour tout ce qui est grosse entreprise de la tech qui sont dans l'open source.
Il y a Red Hat qui s'est fait racheter par IBM il y a peu. Là il y a Docker, on voit quand même que trouver un business model avec un produit open source qui soit viable,
c'est quelque chose qui est compliqué même si l'open source c'est quelque chose qui est vraiment à la mode, qu'on pousse beaucoup etc.
Ce n'est pas pour autant que le business model est facile à trouver et que créer une entreprise rentable dans l'open source est facile visiblement.
J'attends de voir ce que ça va donner.
C'est exactement ça. Moi dans les différents articles que j'ai lu, globalement on sent que Docker a levé plein de fonds pour tenter plein de choses aussi pour trouver un niveau de rentabilité satisfaisant.
Il y a plein de choses qui ne marchent pas ou dont les projections ne sont pas suffisantes pour assurer les investisseurs et du coup ils sont obligés de choisir leur combat.
C'est marrant parce que tu parles du rachat de Red Hat et je pense qu'en fait on pourrait même faire un épisode complet sur les rachats des entreprises open source
parce qu'il y aura beaucoup de choses à dire mais je pense que Red Hat n'était pas dans la même position que Docker.
Parce que Docker, si on se rappelle bien, avait perdu quelques portées tendards l'année dernière et l'année d'avant.
En plus moi je connais Docker depuis le début et j'ai pas vraiment l'impression qu'il faisait beaucoup de chiffres d'affaires.
En tout cas que le chiffre d'affaires n'était pas là et que c'était une entreprise qui vivait vraiment sur les levées de fonds.
Moi je me pose quand même une question aujourd'hui c'est comment est-ce que même en séparant de la partie entreprise Docker va gagner de l'argent.
Parce que créer des outils open source et libre c'est super mais où est-ce qu'ils vont faire du chiffre d'affaires ?
Comment est-ce que cette entreprise va vivre en dehors des levées de fonds ? Est-ce que vous vous en avez une idée ?
Déjà juste un truc qui est sûr c'est que par exemple leur plateforme d'hébergement de conteneurs,
ce qui était sur la partie entreprise c'était que 750 clients qui sont tous repris par MIRANTIS.
Mais en fait dans les 650 clients quand tu vois les références ça reste hyper modeste.
Donc c'est sûr que c'est pas avec ça qu'il n'était pas ça le vrai levier et en plus j'imagine que pour eux ça coûte énormément d'énergie de maintenir ce genre de services et de plateformes.
Ils ont essayé, ça n'a pas appris autant qu'il fallait, ils se recentrent sur leur cœur de métier qui est de faire des outils pour les défaits.
Démir, toi tu as quand même un truc hyper important à nous annoncer, quelque chose qui est même proche de l'apocalypse on peut dire ?
Ah oui clairement là, on n'est pas loin de la fin des temps.
Et voilà il n'y a plus d'IPV4 libres du moins pour la zone Europe tout simplement.
Le 25 novembre 2019 la Network Coordination Center de l'Union Européenne a annoncé avoir attribué le dernier sage 22 d'IPV4 restant.
Donc un petit pincement au cœur pour nous.
On ne peut pas dire que ce soit réellement une surprise, l'épuisement de l'IPV4 était prévu et suivi de longue date.
On se souvient des rapports de l'Arcep régulièrement qui montraient le graphe en chute libre.
Mais concrètement, qu'est-ce que ça signifie ? Tout d'abord, rassurez-vous, ce n'est pas la fin de l'Internet, c'est pas l'apocalypse comme on l'a dit.
Néanmoins, ça attend à ce que les prix de l'IPV4 augmentent rapidement au vu du déséquilibre entre l'offre et la demande.
Il n'y a clairement plus d'offres nouvelles qu'il a injectés sur le marché.
Alors, il y a-t-il des solutions ?
Oui, l'IPV4, on sait que ça va être fini depuis des décennies.
Maintenant, ce n'est pas une surprise, loin de là.
Vous connaissez d'ailleurs sûrement son remplissant, il n'est pas nouveau pour autant, c'est l'IPV6 tout simplement.
Alors, vous avez sûrement vous demandé pourquoi l'IPV6 qui est assez ancien,
il ne faut pas oublier qu'il a été spécifié officiellement dans les années 90, enfin 90-98,
pourquoi il n'est tout simplement pas encore largement utilisé ?
Je pense que c'est surtout lié à un Internet qui a grandi rapidement, peut-être trop rapidement,
tout a évolué très vite. La colonne vertébrale de cette expansion, ça a toujours été le réseau,
qu'on le veuille ou non.
Pendant des années, il a failli construire vite, facilement, en minimisant les risques,
on est resté sur ce qu'on connaissait, ce qu'on maîtrisait,
ce sur quoi on était sûr que nos scripts passeraient, nos matériels passeraient, donc c'est l'IPV4.
Le souci, c'est que le réseau, c'est le lien de tout ça, de notre web moderne, notre web 2.0.
Et oui, votre site en Angular ou Node.js dépend d'une technologie qui date de 1983.
Le remplacer, c'est possible, mais ça va être long, coûteux,
et surtout, le manque d'expérience de retour sur l'IPV6 va compliquer largement les déploiements.
On le voit bien aujourd'hui chez les FAI, les fournisseurs d'infrastructures,
on a eu pas mal d'études qui ont été faites ces derniers temps sur le taux d'éploiement de l'IPV6.
La majorité n'ont pas déployé en fait l'IPV6 à très grande échelle,
malgré un nombre de techniciens assez qualifiés dans ces entreprises-là.
Mais j'aime à penser que la fin de l'IPV4 et l'augmentation des prix de celle-ci
va mettre un peu d'eau au mur certaines entreprises et va forcer à mettre plus de moyens
et accélérer les migrations vers l'IPV6, notamment chez eux, en fait tout simplement.
Je mettrai le lien dans la description, donc il y a un très bon article de l'Arcep là-dessus.
Et Christophe, qu'est-ce que tu en penses du coup de cette fin du monde entre guillemets ?
Et bien, il va falloir que je me mette l'IPV6 et que c'est pas gagné parce que c'est un peu compliqué à retenir en plus,
dont déjà l'IPV4 n'était pas ça. Mais bon, je pense que ça va quand même bien se passer
parce que c'est pas nouveau l'IPV6 comme tu le disais et a priori on s'en sort.
Et malgré le fait qu'il n'y a plus l'IPV4, pour l'instant internet ne s'est pas arrêté.
Donc jusque-là, tout va bien.
Moi, c'est rigolo, ça me rappelle mes années d'étudiant.
J'ai étudié à Paris 6, à Jusieu, qui est un des laboratoires qui a beaucoup participé à l'IPV6.
Et on en a entendu parler énormément, il n'y a pas de soucis là-dessus.
Mais par contre, ce qui était rigolo, c'est qu'il y a un de mes profs qui est justement reprenait un peu ce que tu disais,
qui était que le problème c'est que non seulement on ne peut pas faire le move,
parce que forcément c'est hyper délicat, même s'il y a plein de systèmes de transition
qui ont été trouvés, que ce soit de l'encapsulation des tunnels, etc.
Mais surtout, c'est qu'il y a un manque de formation des gens en général sur l'IPV6,
qui fait que quoi qu'il arrive, en fait, tant que c'est possible, c'est le switch qui va être repoussé.
Finalement, il n'y a pas tant de gens que ça qui sont à l'aise avec le sujet.
Du coup, c'est marrant, c'est un peu comme le réchauffement climatique.
On va attendre de se prendre le mur avant de faire le move.
C'est vrai que c'est un peu dramatique, de devoir attendre dans la tête là,
parce qu'on le voit venir depuis un petit bout de temps le mur.
On a tous les mois le graph qui est publié, le stock qui baisse, mais visiblement, ça n'a pas suffi.
Comme je disais, on va voir ce que ça va donner, parce que l'IPV4 va être de plus en plus cher.
Donc, qu'est-ce que des entreprises ont commencé à faire des moves là-dessus ?
Ce qui serait intéressant ?
Je sais que Google disait qu'ils servaient plus d'incartes de retrafic en IPV6, ou je ne sais pas quoi.
C'est les prémices, on va dire.
C'est les prémices.
En tout cas, ce qu'on sait, c'est que le bon avancissement à faire, ce n'était pas le Bitcoin,
c'était dans un an, c'était bien d'acheter des IPV4 pour les revendre aujourd'hui.
C'était le bon placement.
Clairement.
Il n'y en a plus.
Alors, est-ce qu'on va pouvoir le faire avec les IPV6, l'avenir, on le dira.
Du coup, on va pouvoir passer au sujet de fond.
Pour ce premier épisode, quoi de mieux que de traiter du fameux ingénieur DevOps ?
Alors, l'ingénieur DevOps, mitouréalité, ça, c'est vraiment quelque chose que je dois fleurer
sur les réseaux sociaux un peu partout.
Je sais que Damir, il est un peu comme moi, un peu tachin, et il aime bien pousser un petit peu,
puisque je l'ai vu sur Twitter, pousser des questions sur les gens qui veulent recruter des ingénieurs DevOps.
J'aimerais quand même rappeler une petite définition que j'ai présentée à mes élèves pas plus tard que la semaine dernière.
Donc, le DevOps, c'est un mouvement qui vise à aligner le système d'information sur les besoins de l'entreprise.
Alors, c'est une définition parmi tant d'autres pour l'entrevail plein.
Mais, du coup, l'ingénieur DevOps, est-ce que ça existe ?
Alors, moi, j'ai ma petite idée sur la question.
Du coup, je vais poser la question à Erwin.
Erwin, pour toi, un ingénieur DevOps, qu'est-ce que c'est ?
Ouais, c'est marrant qu'on parle d'ingénieur DevOps comme ça,
puisque effectivement, c'est plus une culture et un ensemble de pratiques plutôt qu'un métier.
Donc, c'est plutôt une culture et des pratiques qui peuvent s'appliquer à des métiers.
Et donc, moi, je le vois plus comme des pratiques qui ont été principalement mises en place pour les métiers
autour des sysadmines et des devs.
Et donc, c'est un peu de la question que j'ai de la question.








Alors, ouais, moi, c'est vrai que j'ai une petite patience sur Twitter,
mais moi, c'est plus au-delà des entreprises, c'est plus vers les écoles.
Je trouve ça triste d'enseigner des choses qui induisent en erreur les gens, mais bon, c'est mon avis personnel.
Moi, j'ai une définition du DevOps qui est assez, on va dire,
je pense qu'il y a tout le monde qui a sa définition, je pense qu'il n'y a aucune qui est réellement fausse.
Donc, moi, je dirais plus que c'est en fait la traduction d'un besoin,
qui est un besoin, en fait, du coup, économique, qui était de se dire,
il faut réduire au maximum le time to market et on s'est rendu compte que,
au niveau du développement, c'était bon, on était bien dans des cycles l'agile,
on délivrait un livrable tout les sprints, tous les temps de temps,
donc on pouvait délivrer rapidement, donc un time to market assez faible,
et on s'est rendu compte qu'en réalité, on a émis de l'agilité partout en se disant,
putain, on va délivrer vite, vite, vite, vite, vite, et au bout de 2-3 ans,
c'est dit, mais attends, mais tous les semaines, on fait une nouvelle feature,
mais elle est livrée que dans le déploiement, qui est trimestriel.
Donc, c'est vrai que pour moi, c'est un besoin d'abord, voilà, plus économique et stratégique,
qui, ça, après, traduit un rapprochement, en fait, des ops et des développeurs
sur un même cycle, en fait, de déploiement, de développement et d'avancement,
et ça, en fait, ça nécessitait un gros travail de la culture,
au niveau de la collaboration et aussi au niveau de l'automatisation.
Donc, pour moi, ça, c'est des choses qui sont induites, du coup.
Voilà, et donc, effectivement, aujourd'hui, il y a beaucoup qui disent que c'est un travail,
ce qui me gêne un peu dans la mesure où, pour moi, c'est pas un travail,
c'est comme Erwan l'a dit, c'est une culture, et ça peut être,
comme Erwan nous disait encore à nouveau, ça peut être tout et rien.
Et j'ai déjà vu, petite anecdote, j'ai déjà été faire un entretien
dans une très grande banque en France qui est très présente sur l'innovation,
dans laquelle, je suis venu pour un entretien de DevOps,
et première question qu'on m'a posée, c'est, tu vas faire combien de pourcent d'ops
? Je fais, non, alors je pense qu'on s'est mal compris,
et donc, du coup, voilà, c'est la petite anecdote,
mais c'est vrai que c'est un peu un sujet épiné aujourd'hui,
j'ai l'impression aussi, moi, c'est une impression personnelle
que beaucoup de gens considèrent que l'ingénieur DevOps,
c'est celui qui veut vraiment s'occuper de tout ce qui est CIA,
et si le déploiement et tout ça, et j'ai l'impression que pas mal de gens
considèrent ça, je sais pas ce que vous en pensez, toi, par exemple,
Christophe, t'en penses quoi de ça ?
Oui, là-dessus, sur la CIA, j'ai mon avis tout fait,
parce que moi, je suis spécialisé justement dans le déploiement,
et quand j'étais dans des grandes boîtes, je faisais que du déploiement,
mais c'était pas pour ça que j'étais un ingénieur DevOps.
Je me suis toujours considéré comme un ops parmi tant d'autres,
à l'époque, on disait que j'étais gestionnaire d'applications.
Aujourd'hui, il y a encore des gestionnaires de livraison,
des personnes qui planifient les livraisons, et en fait,
moi, je discute beaucoup sur LinkedIn avec les recruteurs,
moi, c'est eux, ma petite cible, même si les écoles, en effet, je les taquine,
et les recruteurs, je leur demande toujours,
mais c'est quoi pour vous, un ingénieur DevOps, c'est il fait quoi ?
Et là, du coup, en fonction des personnes que j'ai en face,
c'est un profil totalement différent, quel que soit les interlocuteurs.
Donc du coup, en fait, on ne peut pas savoir vraiment,
des fois, c'est un DBA, souvent, c'est un développeur
qui doit faire le déploiement, souvent, c'est un ops qui doit aider les développeurs.
Enfin bref, c'est tout et n'importe quoi.
Alors du coup, moi, je me rappelle avoir, dans mon cours pour mes étudiants,
encore, j'y reviens, avoir dit ce que c'était pas le DevOps.
En plus de l'ingénieur DevOps, je leur ai rappelé que c'était pas un outil,
puisque, en effet, dans la philosophie DevOps, on utilise des outils,
mais c'est pas un outil. Évidemment, c'est pas un rôle ni un profil.
J'aime bien rappeler que l'ingénieur DevOps, c'est comme la cuillère,
ça n'existe pas. C'est tout ce qui se passe dans l'organisation informatique,
mais c'est pas un rôle. Du fait, si c'est pas un rôle, c'est pas non plus une équipe,
parce qu'on voit souvent fleurir dans les grosses boîtes, voire très grosses boîtes,
des équipes DevOps. Je sais pas si vous avez vu ça arriver, mais moi, je le vois chez
mes clients et du coup, je me dis, mais non, mais comment ils font ?
Déjà, ils n'arrivent pas à faire coopérer leurs dev et leurs ops,
ils viennent rajouter une équipe de plus, mais c'est pas possible, mais comment ils font ?
Et enfin, c'est pas une méthode. Alors, on parle beaucoup de méthode agile,
méthode DevOps, mais pour moi, c'est en effet plus un mouvement, un état d'esprit,
qu'une méthode. C'est-à-dire qu'en fait, chacun, chaque entreprise doit trouver ses propres outils,
ses propres méthodes et leurs propres voies.
Alors vous, l'équipe DevOps, ça vous évoque quoi ? Erwan, par exemple ?
Je serais curieux de savoir dans l'entreprise que tu décrivais,
justement, quel était le rôle ? Parce que s'il y a d'une partie,
il y a une équipe déjà ops et une équipe de dev et que,
en fait, c'est des gens qui font le lien entre les deux, je vais...
Non, je vais te répondre, c'est encore mieux que ça.
Cette équipe DevOps, elle est chargée d'exploiter l'outil de déploiement continu
qui va être déployé dans le ESC et elle ne fait que ça.
Ouais, voilà. Donc, du coup, finalement, c'est...
Ouais, j'ai pas trop d'avis sur la question.
Là, pour le coup, ça fait plus, on a appliqué un buzzword,
un nom d'une équipe qu'on a monté pour faire une tâche précise,
plutôt que d'essayer de représenter un peu les pratiques et les méthodes
qu'on citait avant sur la réduction du Time to Market.
Moi, mon sentiment comme ça, gros grain, c'est...
J'ai le sentiment qu'à chaque fois qu'on parle de DevOps,
on met en parallèle l'automatisation.
Moi, quand j'ai commencé ma carrière, avec JT6 admin,
j'ai essayé d'automatiser tout ce que je faisais.
Alors, c'était pas les mêmes outils qu'aujourd'hui,
mais globalement, il y avait toujours cette volonté de...
On doit faire une mise en prog.
À l'époque, c'était des Bedscript Bash.
Aujourd'hui, on peut avoir des choses plus ambitieuses,
avec des conteneurs, des Yuantsybell, du terrain,
enfin, ce qu'on veut.
Mais je veux dire, en tout cas,
moi, j'ai le sentiment que ça a toujours existé.
Aujourd'hui, on a juste appliqué, on a juste donné un nom à tout ça.
Moi, ce que je retiens de ce mouvement,
c'est ce côté de ne plus avoir de silo entre les équipes
et d'avoir des ponts qui se créent avec des langages communs.
Et les langages communs, c'est justement les pratiques
autour de, par exemple, tout doit être à The Code,
avec des reviews, avec des tests,
et ça qu'on parle de Code ou d'infrastructures, de configurations.
Et moi, c'est plus comme ça que je le vois,
enfin, que je le vois un peu grossièrement,
ce qu'on appelle le rôle de DevOps.
Pour moi, c'est quelqu'un qui est garant de cette méthode
et qui met en place les outils pour arriver à tendre vers ça.
Enfin, je ne sais pas si ça match avec ce que vous pensez,
mais en tout cas, moi, c'est comme ça que je le vis aujourd'hui.
Il s'avère que j'ai un bac grand de 6 admins,
donc effectivement, les questions d'infra, etc.
C'est souvent moi qui y répond.
Mais mon travail premier, c'est avant tout de mettre en place ce qu'il faut
pour que les DevOps se concentrent uniquement sur leur travail de DevOps,
que faire des tests, avoir un environnement,
ou déployer, ça soit quelque chose qui puisse faire en total autonomie
avec des outils, donc le langage commun qu'on a mis en place
pour faire le pont entre l'infra et ce qu'ils font, et ce qu'ils produisent.
Je ne sais pas si vous rejoignez ce point de vue.
Alors, moi, je rejoins plutôt, je suis entièrement d'accord
sur le côté automatisation.
C'est pareil, j'étais à la base administrateur.
Je faisais du Peupet sur mes machines, etc.
et j'ai clairement pas attendu qu'on vienne dire,
attends, si tu pourras automatiser, ça serait super.
C'est un truc que je fais automatiquement,
en fait, par principe, pour t'économiser du temps aussi.
Donc, c'est pour moi quelque chose qui, si tu ne le faisais pas avant,
il y avait quand même un autre problème.
Et après, je pense effectivement qu'il y a une grosse notion de buzzword
et j'ai aussi cette impression qu'il y a beaucoup d'entreprises,
surtout des grosses entreprises qui ont dit,
« le DevOps, c'est à la mode, c'est ça qu'il faut,
on va venir des nouveaux talents, c'est ça qu'il faut,
pour avoir vraiment de la visibilité sur les Technos.
» Et ce qu'ils ont fait, c'est qu'ils ont dit,
« on va prendre une équipe, on va dire, c'est l'équipe DevOps,
on va faire passer à deux une certif AWS,
on va les envoyer au DevOps Rex et dans un autre salon,
ils vont venir, ils vont prendre des photos,
pour les mettre sur Twitter et dire, vous avez vu, on est DevOps.
» Je caricature légèrement, mais moi, c'est ce que j'ai l'impression
de beaucoup d'entreprises, malheureusement,
ça a été pris plus comme vraiment quelque chose de marketing,
à un effet de mode, que réellement quelque chose.
Et souvent, là aussi, souvent, les équipes DevOps que j'ai vues,
en fait, c'est des gens qui faisaient comme avant,
c'est juste qu'on leur a fait passer une certif AWS,
on leur dit, « vous faites sur AWS.
Vous faites exactement la même chose que vous faisiez
sur votre essai interne.
» Ben non, c'est pas, c'est pas ça une équipe DevOps,
c'est malheureusement beaucoup d'entreprises
qui l'ont compris comme ça.
Donc ouais, moi, c'est un peu mon avis sur le point là.
Je sais pas si Christophe, toi, tu as un autre avis là-dessus.
– Moi, j'ai un avis complémentaire, du coup, je vais vous le donner.
Ce que tu décrivais tout à l'heure, AirOne,
pour moi, ça faisait vraiment penser
à un coach ou un mentor DevOps
qui va en effet insuffler la philosophie
et le mouvement à l'intérieur de l'entreprise
plus que le rôle d'un ingénieur.
Alors moi, je sais pas d'où vous venez,
mais moi, à l'origine, j'étais développeur,
c'était il y a déjà 20 ans,
j'étais développeur, je faisais du C et tout.
Et donc du coup, c'est vrai que j'ai le background
développeur qui automatise tout.
Et suite à justement, dans cette grosse boîte
où j'étais chez Casino, je peux la nommer maintenant,
je faisais de l'exploitation de la prod,
je faisais de l'exploitation des applications
et j'écrivais des scripts d'automatisation en effet
pour faire le déploiement des logiciels.
Bon, à l'époque, on n'osait pas tout automatiser,
mais déjà, on faisait de l'automatisation.
Puis après, dans cette même boîte,
j'ai rejoint une équipe qui s'appelait l'équipe outil.
Et notre rôle, c'était d'écrire des outils
pour les développeurs ou pour les autres ops.
On s'appelait pas l'équipe DevOps,
bon, le terme n'est visité pas encore,
mais on n'était pas, je veux dire,
je ne me considérais pas comme un autre rôle.
Et il y a un article très bien là-dessus que je vous conseille,
d'ailleurs je vous mettrai le lien en description,
alors excusez mon anglais, mais c'est cet article qui s'appelle
Wives DevOps Engineer is a Mizzendenstude role.
Du coup, pourquoi est-ce que le rôle d'ingénieur DevOps
est mal compris, est un rôle mal compris.
Alors c'est un article qui a été mis à jour
en avril 2019 de Kaia Ismail
et dans cet article, il cite Sylvane Yergen
et lui demande pourquoi est-ce qu'il y a une confusion
dans le rôle de l'ingénieur DevOps
et le rôle de l'ingénieur administrateur système ou autre.
Et en fait, Sylvane dit quelque chose de très très juste,
c'est qu'en fait dans les entreprises et notamment dans les grosses,
c'est tellement compliqué d'insuffler
ou d'introduire une nouvelle méthodologie
que c'est beaucoup plus simple d'embaucher une personne
qui aura un rôle.
Et du coup, ces entreprises-là
pensent qu'en embauchant des ingénieurs DevOps,
si c'est comme ça qu'elles les appellent,
ils vont pouvoir passer aux DevOps plus facilement.
Et en discutant avec les recruteurs
et recruteuses en leur posant des questions,
beaucoup me disaient en effet à force
qu'ils utilisaient le terme ingénieur DevOps
par facilité, parce que déjà ça fait rêver,
c'est un buzzword.
Et pourtant, ce n'est ni plus ni moins qu'un rôle d'ops classique
qui ajuste des méthodes
et qui a eu un état d'esprit complètement différent de ce qu'on faisait.
C'est-à-dire qu'un administrateur système
qui suit le mouvement DevOps,
ce n'est pas un administrateur système à papa comme je les appelle,
qui va se connecter sur les machines,
qui va installer ses paquets manuellement,
qui va modifier sa petite conf-engings comme ça en scred.
Non, non, l'ingénieur DevOps,
enfin, tout le cas tel qu'il l'appelle,
l'ingénieur ops qui suit le mouvement,
il va justement automatiser tout ça.
Je suis un petit peu parti dans tous les sens,
mais c'est normal, c'est comme ça un podcast.
Donc on part dans tous les sens.
Alors je vais peut-être rebondir et remettre une pièce dans la machine,
un nom d'Amir, il voulait le dire quelque chose, d'Amir, je t'en prie.
Oui, alors c'est vrai que moi je me suis intéressé un peu
d'un autre point de vue,
plus des commerciaux en fait dans les grosses USN notamment.
Et j'ai essayé un peu de pousser,
mais pourquoi on dit ingénieur DevOps en fait ?
Et c'est aussi une autre question
à laquelle on n'a pas pensé,
qui est vraiment sortant du cadre technique,
pourquoi les gens ont cette confusion,
c'est tout simplement les outils.
Parce qu'au final aujourd'hui,
quand on travaille tous sur les mêmes stacks et les mêmes choses,
on travaille avec les mêmes outils.
Par exemple, un ops aujourd'hui on lui demande de connaître, je ne sais pas.
Par exemple, du Jane Keane, s'il y a de la CIA,
mais le dev on va aussi demander du Jane Keane,
c'est parce qu'il y a aussi ça parti de la CIA.
Donc en fait il m'expliquait que dans les fiches de poste,
il y a des techno qui étaient de plus en plus similaires dans les deux côtés.
Donc ils avaient tendance à un peu être perdu,
parce qu'ils n'ont pas forcément le background technique.
Et du coup ils abrègent ça, ils disent
il y a ça dans la stack c'est DevOps.
Comme ça, il y a moins de confusion pour eux.
Ils ont des outils moins en étant techniques,
mais les outils prêtent vraiment à confusion,
vu qu'ils sont utilisés par les deux côtés aujourd'hui.
Moi je trouve que ça valide un peu ce que j'ai dit un peu plus tôt
sur ce côté de langage commun.
Et qui fait que la frontière peut être hyper confuse
entre où s'arrête le périmètre de l'ops
et où s'arrête le périmètre du dev.
Enfin moi je trouve que ça illustre vachement ce propos.
Alors moi du coup je vais reprendre la parole.
Tout à l'heure j'ai vu une offre d'ingénieur DevOps.
Alors je vais prendre un petit extrait,
comme ça on comprendra un petit peu de quoi on parle.
Donc un ingénieur DevOps,
qu'est-ce qui fait en tout cas son poste, qu'est-ce que c'est ?
En collaboration avec l'équipe des développeurs
et l'équipe à frasse structure.
Donc ça veut dire qu'il collabore avec les devs et avec les ops.
Déjà on peut poser la question d'où il est.
Mais bon, vous devez mener les tâches suivantes.
Donc mettre en place la fin de la migration du legacy,
de quoi on sait pas.
Installer des VM et des dockers.
Gestion des logs.
Poursuivre la mise en place de l'intégration continue.
Automatiser des tests.
Supervision et amélioration au niveau de l'applicatif
et du système de sécurisation.
Redaction de documentation technique.
Donc il va évoluer cet ingénieur DevOps.
Il va évoluer dans un environnement docker,
Suntos, Jenkins, Redis, excusez-moi PHP et Oracle.
Et le profil qui est recherché, c'est une première expérience
dans un projet similaire.
Intervenir en autonomie sur les problématiques des Vops
et être un bon communicant.
Travier en collaboration avec les différentes équipes.
Bon, ça va de soi évidemment quand on fait du DevOps.
Du coup, qu'est-ce que vous en pensez de cette offre ?
C'est un peu une offre d'ops qui...
Enfin moi je veux...
Si on retient les besoins, pour moi c'est un taf d'ops en fait.
Tout ce qui est décrit, c'est quand même pas mal de...
Enfin par exemple, les migrations qui sont évoquées,
c'est du travail qui concerne vraiment les Vops
parce que j'imagine qu'il va y avoir du travail d'infrastructure,
du travail d'architecture, etc.
Donc enfin, en tout cas pour moi, c'est un boulot d'ops.
Oui, je suis assez d'accord avec Airwan sur le fait que c'est un boulot d'ops
qu'on a un peu rebrandé parce que c'est à la mode.
D'ailleurs c'est assez intéressant parce que ça c'est un truc qui arrive aussi assez souvent
je sais pas si vous l'avez remarqué.
Moi j'ai eu le cas, par exemple, je travaille dans une entreprise
où mon poste à la base était administrateur système
et avec le galère qui a notamment recrutement.
Quand je suis parti, en fait je suis retombé sur l'offre du poste que j'occupais
et le poste on l'avait renommé en ingénieur...
en SRE en fait, pour un peu attirer plus de personnes.
Donc j'ai l'impression aussi qu'il y a cette mode,
vu qu'il y a une pénurie quand même dans l'informatique en France,
de faire un peu de renommage pour rendre des choses un peu plus sexies
parce que là dans l'offre on comprend bien avec...
il y a du oracle, du PHP, du Sainte-Ouest,
ça n'a pas l'air d'être clairement la stack la plus sexy au monde.
Donc on sent qu'il y a un peu peut-être ce côté de mettre DevOps
pour un peu attirer des gens sur un poste d'admin 6 assez classique
qui n'arrive pas à se démarquer au final de la masse et à intéresser des gens.
Je sais pas ce que vous en pensez.
Je suis entièrement d'accord, c'est...
pour moi je le vois vraiment comme ça.
En tout cas, la description d'une job,
tu messies s'admines, c'est la même chose.
Et tu mets le même contenu.
Ouais, exactement.
C'est assez intéressant parce que...
justement quand j'ai fait mon cours à ces élèves ingénieurs,
eux ils savaient même pas ce que c'était qu'un Ops.
Ils imaginait qu'un Ops c'était quelqu'un qui allait brancher des câbles réseaux
ou brancher des racks dans les data centers
et ils pensaient que c'était quelqu'un qui était beaucoup plus proche de la machine
et en discutant avec eux ils ont compris que non en fait.
Et alors moi ça me fait penser qu'il y a un manque de culture sur notre métier
que le métier d'administrateur système déjà il est mal connu.
Alors pour le rendre sexy on a peut-être inventé le terme dévoque,
c'est pas le plus collé dessus.
Mais je pense qu'en fait il y a plus une évangélisation à faire.
C'est quoi le métier d'administrice et c'est quoi le métier d'administrice aujourd'hui?
Et moi quand je lis l'annonce, en fait il y a un truc qui me fait tiquer
c'est que cette personne là elle va travailler avec l'équipe infrastructure
alors j'en déduis qu'en fait l'équipe infrastructure c'est un peu les administrateurs système papa comme je les appelle
et que du coup cette personne là elle va finalement quelque part soit les remplacer soit les former
et elle est embauchée pour ça.
Et on retrouve justement ce que disait la personne de l'article
que c'est plus facile d'embaucher quelqu'un que de faire évoluer une entreprise.
Moi je pense qu'en effet ça demande du travail de faire évoluer une entreprise
mais en tout cas c'est valorisant pour les membres de l'entreprise d'évoluer.
J'ai presque pensé que c'est nécessaire de faire venir des gens de l'extérieur.
Il y a eu un papier qui est assez intéressant d'OVH et c'était Octave Clabach
je crois qu'il avait rédigé qui expliquait, alors je digresse un peu mais c'est pour reprendre cette problématique
qui expliquait qu'en fait ils avaient fait une grosse erreur
parce qu'il y a beaucoup de postes stratégies notamment sur l'innovation etc.
C'était que des gens qui étaient là depuis les fondements de l'entreprise
donc du coup ils n'avaient jamais rien vu d'autre
donc au final ils restaient quand même pas mal sur les acquis
et du mal à se rendre compte d'une certaine réalité du marché des technos
et c'est vrai que aussi des fois faire venir des gens de l'extérieur
ça peut aussi apporter une autre vision des choses, donner un peu de perspective
donc pour ça je suis assez d'accord au final de se dire que parfois faire venir quelqu'un d'extérieur pour le DevOps
ça peut grandement aider quoi.
Du coup je sais pas ce que t'en penses toi Christophe là dessus ?
Oui je sais pas, on peut aussi clôturer
vu que je vois que ça fait quand même 40 minutes qu'on parle
Alors tout à l'heure tu parlais du SRE
en plus le SRE il me semble que c'est une méthodologie
en plus d'être un rôle pour le coup qui lui est bien identifié
qui est une méthodologie qui est prenée par Google je crois
je me trompe pas
Non c'est ça, ça a été définit par Google en gros et c'est un métier
effectivement et une méthodologie qui prend racine dans le DevOps on va dire
Ok, alors oui
donc moi je pense qu'en effet faire venir des gens de l'extérieur c'est vachement bien
par contre les faire venir sous des faux termes c'est pas une bonne chose
en plus ça m'embête parce que c'est vrai que mon métier c'est quand même
d'accompagner les entreprises à faire des transitions DevOps
donc si ils embauchent des DevOps qui rebrandent dans des DevOps
et qui font pas appel à des personnes, des coachs comme moi
quelque part, enfin moi je pense qu'ils, comment le disais
ils se focalisent un peu trop sur l'automatisation
qui est un des piliers en effet DevOps mais ils oublient tous les autres piliers
et on n'oublie pas c'est calme, c'est coopération
automatisation, ligne donc amélioration continue
mesure et chair donc partage pour partager l'information
et du coup j'ai peur qu'en fait en se focalisant sur ce métier là
ils oublient tout le reste et que du fait alors c'est bien pour ces entreprises
mais tant qu'elles n'auront pas fait une transition des DevOps complète
elles vont peut-être pas aller aussi loin qu'elles pourraient aller
alors je vais, si ça vous en dit pas je vais clôturer un petit peu sur ça
et juste en lançant une pièce dans la machine peut-être pour un prochain podcast
le devc cops, alors le devc cops, est-ce que le devc cops ça existe
est-ce que le devc cops c'est un rôle en devenir
bref on en parlera peut-être un jour
je crois qu'il est temps de clôturer ce podcast
puisque mine de ral, on a quand même pas mal parlé
et je vais vous laisser la parole à tous les deux
c'était bien pour une première
c'était sympa, je pense qu'on a pu, c'était intéressant d'avoir les points de vue de chacun
et aussi profiter d'expérience de chacun sur ces questions
parce qu'on n'a pas forcément même ressenti les mêmes vécues
donc non c'était plutôt cool
donc voilà, merci à vous en tout cas
merci
et bah en tout cas moi je vous remercie profondément
parce que ce premier épisode annonce de futurs épisodes plein de bonnes choses
et si je peux te dis un petit peu
je crois que prochain épisode il est prévu comme sujet de fond
le claudact et la souveraineté numérique
donc si vous voulez en savoir plus sur claudact et la souveraineté numérique
n'hésitez pas à vous abonner au podcast
et puis bah on vous dit à la prochaine fois
merci d'avoir écouté Radio DevOps
la balle de diffusion des compagnons de DevOps est produite par l'Hydra
si l'épisode t'a plu, note le plus la note sera élevée
et plus il sera mis en avant dans les applications
tu peux aussi le partager, cela nous aidera à le diffuser et à rendre le mouvement beaucoup plus visible
si tu as envie de discuter du mouvement
le plus simple c'est que tu rejoins la communauté des compagnons de DevOps
le lien est en description
à bientôt