Bienvenue sur Radio DevOps, la balade aux diffusion des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les
futurs épisodes. C'est parti !
1. Ingenieur DevOps, 6-Ops, CloudOps, Admin 6, c'est que des noms de métier et on s'y perd.
Et c'est quoi la différence entre tous ces métiers ?
En fait, c'est une question que m'a posé Olivier et Olivier me demandait,
« Bonjour, je souhaiterais que tu nous parles plus précisément de la définition
de ce qu'est un DevOps-Ingénieur et le rapport qu'il y a avec un 6-Ops ou un Admin 6,
qui durant quelques temps ont semé la confusion. »
Et c'est justement l'objet de ce numéro en solo où je vais te parler de ces métiers.
Mais avant ça, j'ai remarqué qu'il y a beaucoup de gens qui nous écoutaient,
qui n'étaient pas abonnés au podcast, ou qui sur YouTube n'étaient pas abonnés.
Donc si tu écoutes ce podcast au travers d'une application, abonne-toi et active
les notifications citées sur YouTube. Comme ça, tu seras prévenu à chaque
fois que je sors un épisode de podcast.
Alors avant de commencer dans les détails de tous ces métiers,
je voudrais rappeler ce que c'est qu'un Ops. Un Ops en fait, c'est un ensemble de métiers
qui est en rapport avec l'infrastructure. On dit souvent les devs pour désigner les
développeurs full stack, les développeurs frontaine, des développeurs backend,
des développeurs système aussi, ce qui peut y avoir des développeurs système ou des développeurs
d'API, et on les nomme les devs. Et les Ops, c'est tout ce qui s'occupe de gérer l'infrastructure
et d'assurer la stabilité du système d'information. Donc que ce soit les administrateurs système,
les administrateurs cloud, les administrateurs de données, etc., les administrateurs sécurité,
toutes ces personnes-là sont des Ops. Donc dès que vous voyez quelque chose Ops, vous savez que c'est
quelqu'un qui s'occupe de l'infrastructure et pas du code de l'application. Voilà. Alors maintenant,
comment est-ce qu'on se retrouve dans tous ces métiers quand on n'a pas l'habitude ? On va commencer
par l'administrateur système, ou le sysadmin en anglais. Donc lui, il s'occupe vraiment du système
d'exploitation. Il l'administre, il le configure, il le maintient. Il s'assure qu'en fait les serveurs
y tournent bien, qu'ils ne soient pas surchargés. Et s'ils sont surchargés, de voir pourquoi
est-ce qu'ils le sont. Et ils font des retours au développeur si jamais il y a un problème dans
l'application justement qui est hébergée par le serveur. En fait, moi je vais parler du web. Donc
la plupart des cas, c'est des administrateurs système Linux. On a très peu d'unix dans le web et on
a encore moins de Windows. Si vous êtes administrateur système en entreprise, vous m'excuserez, mais là,
je vais vraiment parler de ceux qui font du Linux. Donc ils doivent vraiment connaître sur le bout
des doigts Linux, le Bache et maintenant depuis quelques années les conteneurs. C'est vraiment pour
moi les trois compétences techniques que l'administrateur système doit avoir. En sachant que
Linux, c'est la base de la base. Si vous ne connaissez pas Linux, vous ne pourrez pas faire
un bon admin 6. C'est vraiment très important de connaître Linux, comment ça fonctionne,
comment il est architecture, comment on s'en gère les droits, les fichiers, etc. L'administrateur
système, lui, peut utiliser des outils d'automatisation comme en cible, Peupet et Chef ou d'autres.
Moi, je préfère en cible, vous le savez, pour administrer ces serveurs puisque maintenant,
un administrateur système dans le mouvement DevOps, il va administrer plusieurs dizaines,
centaines de serveurs. Ce métier-là, il est fait pour ceux qui aiment Linux, la ligne de commande et
qui y arrive à faire de l'abstraction. Maintenant, vient le CISOPS. Alors je vous avoue qu'avant de
creuser cet épisode de podcast, j'avais pas vraiment entendu parler de CISOPS. Donc en français,
c'est un opérateur système. C'est un terme qu'en fait j'ai trouvé vraiment en lien avec AWS,
Amazon Web Services. Je l'ai très peu trouvé en lien avec les autres technologies, mais CISOPS
en fait, ça désigne le rôle d'une personne qui va automatiser l'infrastructure. Donc l'infrastructure
dans son monde semble le réseau, les serveurs, les disques et toutes ces choses-là. Donc c'est
une évolution de l'administrateur système d'après Amazon Web Services et si on se focalise là-dessus
sur l'automatisation de l'infrastructure, pour moi aussi, c'est une évolution de l'administrateur
système. Parce que pour pouvoir automatiser la création d'infrastructure, il faut quand même s'y
connaître en script, en outils d'automatisation et avoir des notions de Linux parce qu'évidemment,
comme je vous l'ai dit dans Cloud et surtout dans Web, il y a beaucoup de Linux. Donc cette personne-là,
elle va créer des serveurs Linux. Donc évidemment, il faut qu'elle connaisse un petit peu. Il y a des
notions un petit peu techniques comme quand on va lancer des serveurs, on va les initialiser avec
par exemple Cloud Init qui est un système d'initialisation d'un serveur pour le configurer
au moment où il se lance la première fois et ça, ça utilise Linux. Pour moi, c'est ce que j'appellerai
un engineer cloud. Et c'est un engineer cloud, il doit connaître plusieurs choses. Les concepts
de virtualisation, il peut s'entraîner sur sa machine avec Vagrant et VirtualBox. Les concepts
d'infrastructure à ce service, donc les briques de base que sont les serveurs, les réseaux, les
routers, les disques, c'est quoi un block storage, c'est quoi un object storage. Toutes ces questions-là
et tous ces concepts-là, il doit les connaître. Et puis, c'est mieux s'il connaît un ou plusieurs
classes publiques. Bon s'il ne reconnaît aucun, c'est sûr, il va avoir du mal à faire un opérateur
système. Mais s'il en connaît un ou quelques-uns, il va vraiment pouvoir y arriver. Donc les plus connus
Amazon Web Services, Google Cloud, Azure, vous savez ce que je pense de ces trois-là, mais en l'occurrence,
il y a du boulot là-dedans. Et puis sinon, on peut citer aussi OpenStack, SkaLway. Là, avec ces cinq-là,
vous avez une bonne vision de ce qui se fait en entreprise aujourd'hui dans le web en France.
Pour automatiser tout ça, il va utiliser des outils comme Terraform et EnCible. Et ça,
ce métier-là, il est fait pour ceux qui aiment le cloud. Donc si vous aimez le cloud, c'est le
métier qu'il faut que vous visiez. Viens ensuite le DevOps, l'ingénieur DevOps. Alors moi,
je suis vraiment emmerdé avec ce terme. Vous le savez, si vous avez écouté Radio DevOps n°1,
qui parle de l'ingénieur DevOps mit aux réalités. Si vous l'avez pas écouté, allez-l'écouter et
puis revenez. Mais ce terme-là, en fait, il semble regrouper plusieurs métiers et à chaque fois
que j'essaie d'obtenir une réponse des recruteurs ou des entreprises, parce que pour moi, ce n'est pas
un métier, le DevOps. Mais à chaque fois que j'essaie de déduire une définition, il y a
le pire étant, c'est quelqu'un qui fait à la fois du Dev et à la fois de l'Ops.
Partir du moment où on estime que quelqu'un doit faire à la fois du Dev et à la fois de l'Ops,
il fait mal les deux. Ou, selon notre point de vue, il ne fait pas bien les deux. Les deux métiers
sont vraiment hyper complexes. Déjà, un ingénieur, un développeur full stack, il a des tonnes de
concepts à apprendre. Mais un ingénieur, un administrateur système, un administrateur cloud,
il a aussi beaucoup de concepts à apprendre. Donc on ne peut pas faire les deux.
Bon, d'après moi et d'après la définition que j'ai pu en sortir après toutes les questions que j'ai
posées, les définitions le plus adaptées de l'ingénieur d'EvOps, si on ne veut le définir,
c'est quelqu'un qui gère l'intégration continue et le déploiement continue, la CI-CD.
Moi, c'est ce que j'appelle un gestionnaire d'application ou un gestionnaire de déploiement.
Donc, c'est des fiches métiers qui existent. C'est des métiers qui existent. Le gestion de
application, c'est ce que j'ai fait pendant des années. Je ne vois pas pourquoi il était rebrandé
en DevOps, peut-être parce que ça ne faisait pas rêver un ingénieur d'application. Pourtant,
c'est un métier qui est tellement complet et complexe qu'on peut faire plein de choses.
Ça, c'est vraiment le métier de ceux qui se passionnent pour le déploiement.
Moi, j'adore le déploiement. C'est vraiment ce que je vends. Je vends du déploiement continue,
parce que l'objectif, c'est d'arriver à déployer à chaque fois qu'un développeur pousse son code
et d'arriver à déployer sans couper le service. C'est un challenge hyper intéressant et hyper
important, surtout pour les entreprises du web actuel. Si vous gérez une application et vous
déployez une application qui n'est pas une application disponibilité, il y a quand même
des choses à faire. Mais dès que vous touchez à la haute disponibilité et au déploiement
sans coupure de service, vous avez beaucoup de travail, beaucoup de choses à réfléchir.
Pour automatiser, il va utiliser en cible. Évidemment, beaucoup les services d'intégration
continuent, donc Geeklabsci, Circleci, Travis, Jenkins. Moi, je conseille toujours Geeklabsci.
Mais bon, c'est ce que j'adore Geeklabsci. Ça vous l'aurait compris. Mais en fait,
quel que soit les 3 métiers, que ce soit l'administrateur système, l'ingénieur cloud ou le gestionnaire
d'application, dit le DevOps, au travers ces 3 métiers là, et bien d'autres,
que je n'aborde pas parce que sinon l'épisode sera tout long, tous ces métiers là et bien d'autres,
ils peuvent rejoindre le mouvement DevOps parce que DevOps, c'est avant tout un mouvement et une
philosophie. C'est une philosophie qui touche tous les métiers de l'ops, au dev, de dev, à l'ops.
Il y a beaucoup de membres de la communauté des compagnons d'idox qui sont aussi des développeurs.
Bon, il y en a énormément qui sont des ops, mais ça touche tout le monde. Et c'est un mouvement
dans lequel on doit rentrer. Alors maintenant, tu peux te poser la question de quel métier
choisir. Parce que c'est ça aussi le truc, c'est quel métier choisir. En fait, en fonction de l'expérience
que tu as, tu peux faire tous ces métiers. Moi, aujourd'hui, je suis consultant indépendant et je
fais un peu tous ces métiers parce que j'ai les infrastructures qui me permettent de mettre en place
des briques, qui vont me permettre de gérer du déploiement sans couper le service. Et évidemment,
pour faire ça, j'ai besoin de gérer les serveurs. Donc, j'ai besoin de gérer les nukes.
Donc évidemment, je ne suis pas un spécialiste de chaque brique, mais j'arrive à gérer seul
tous ces métiers-là. Du coup, je suis un ops. Et je ne suis pas spécialement de non-specifiques.
C'est pour ça que je me présente comme consultant en transition des ops et expert en déploiement
continue. Mais la question à te poser, c'est qu'est-ce que tu peux faire ? En fait,
si tu commences, il n'y a pas de question vraiment trop complexe à te poser. Il va faire que tu
commences par l'administration système. C'est la base. C'est vraiment la base, c'est-à-dire connaître
l'inux, connaître le bâche, connaître ta ligne de commande. C'est vraiment ce qui va faire de
toi un ops efficace. Quel que soit après le métier que tu vas choisir. Tu commences par l'inux,
puis après, tu vas aller dans le cloud ou le déploiement. Et après, tu peux faire le reste.
Mais il faut commencer par gérer Linux. Alors bien sûr, si tu es un développeur, tu peux devenir
ops. Moi, c'est ce que j'ai fait. J'étais développeur il y a 22 ans et puis je suis devenu petit à petit
ops parce que j'ai appris à utiliser Linux et les lignes de commande. Donc, citer développeur
et que tu as envie d'être ingénieur d'evox parce que ça te fait rêver. Tu sais ce que j'en pense,
mais bon, si ça te fait rêver, commence par virer ton Windows et install Linux. Et puis,
il commence à travailler dans ta ligne de commande. Tu fais tes commandes Git à la main et tu n'utilises
pas de gestionnaires graphiques de Git. Non, tu fais toi à la main. Tu peux même aller utiliser
Viyaille pour éditer tes fichiers. Enfin, Viim, mais Viim au moins. Il faut que tu maîtrises ta ligne
de commande. Il faut que tu maîtrises ton clavier. Quel que soit le métier que tu fais. Si t'écoutes
ce podcast, ce qui t'intéresse en fait, c'est le mouvement d'evox. C'est vraiment l'état d'esprit
que tu dois avoir. C'est celui du mouvement d'evox. Quel que soit le métier dans lequel tu vas,
il y a une base commune qui est le mouvement d'evox. Le mouvement d'evox, si tu le comprends bien,
tu vas pouvoir évoluer plus facilement parce que les completances techniques, c'est bien,
tu peux les apprendre facilement. Mais les soft skills, la connaissance du mouvement, la connaissance
de la philosophie de ce mouvement, c'est quelque chose qui va t'accompagner tout le long de ta carrière.
Et donc pour ça, et parce qu'on me pose souvent la question, pour bien comprendre d'où vient ce
mouvement, j'ai en train de préparer ma première formation qui parlera de ça, exclusivement du
mouvement d'evox. Elle sera en précommande vers la fin du mois et elle sortira en septembre. Et si
ça t'intéresse, si une telle formation t'intéresse, inscrit toi aux compagnons du
d'evox, rejoins-nous parce qu'il y aura une réduction spéciale pour les compagnons qui ne sera pas
publique et qui sera uniquement réservé aux membres de la communauté. Donc inscrit toi aux
compagnons du d'evox, c'est le premier lien en description. Et si jamais tu écoutes ce podcast dans
le futur et que la formation est déjà sortie, eh ben j'aurais remplacé le lien et ce sera l'accès
à la formation, ce sera le premier lien en description. Donc j'espère que cet épisode t'as plus,
que tu verras un peu plus clair dans ces métiers et si t'as envie que j'aborde d'autres métiers,
ben hésite pas à me poser la question sur question.compagnon-devox.fr. Pareil, le lien est
en description, il faut le chercher. Et je te dis à très bientôt. Merci d'avoir écouté Radio
DevOps. N'oublie pas de noter l'épisode, plus la note sera élevée et plus il sera mis en avant
dans les applications. Tu peux aussi le partager, ça nous aidera à le diffuser et à rendre le mouvement
plus visible. Si tu as envie de discuter du mouvement, alors rejoins-nous dans la communauté des compagnons
du DevOps. À bientôt. La baladeau diffusion des compagnons du DevOps est produite par l'Hydra.