Recherche de conseils pour se lancer dans le devops en tant qu'indépendant

Salut et bienvenue,

Merci pour cette présentation qui nous permet de réagir.

Question : Pour toi, c'est quoi le DevOps ? As-tu déjà pratiqué ?

OK, merci pour ta réponse, je comprends mieux le contexte.

Tout ce que tu viens de décrire fait effectivement partie du DevOps. Je vais essayer de donner des pistes de réflexion.

Une startup naissante préfèrera prendre des solutions toutes packagées pour son cycle de développement :

• AWS codebuild, codecommit, codedeploy...

• Azure DevOps

Tu as à peu près 10% de chances de tomber sur un tel outillage, parce que ça implique des startups très récentes avec une volonté politique forte d'être en IaaS/PaaS.

Dans les 90% restants, tu vas te confronter à du legacy avec des repositories GitHub/GitLab, des workers éparpillés dans la nature, des déploiements pilotés par Jenkins, ou d'autres trucs assez baroques. En fait, une fois qu'un dev s'est approprié un outil, il veut tout faire à partir du même outil. Donc, ça donne des choses quelquefois inattendues. Je ne me remettrai jamais de voir des scripts destinés aux OPS écrits en Groovy, alors que je n'ai strictement jamais vu un OPS travailler en Groovy.

Il y a 2 technos assez répandues qui viennent complémenter tout ça : Terraform et Ansible. Pour faire un raccourci :

• Terraform sert à déployer des VM / Réseaux / règles de FW.... donc des trucs qui se passent à l'extérieur du serveur.

• Ansible sert à déployer Apache, NginX, des librairies..... donc des trucs qui se passent à l'intérieur du serveur.

J'entends d'ici les objections qui vont dire, oui, mais "Terraform peut aussi aller à l'intérieur du serveur". Oui, sauf que c'est encore assez peu utilisé voire assez peu performant.

L'énorme avantage de terraform, c'est d'avoir un "state", c'est à dire un "état" qui "sait ce que tu as déjà déployé". Donc, Terraform a une grosse longueur d'avance sur ses concurrents.

J'ajoute, et c'est un point absolument crucial : tu ne peux pas faire de DevOps sans une gouvernance stricte. Appuyer sur le bouton "deploy" est un acte qui a de graves conséquences immédiates et futures. Je peux donner un exemple simple : j'ai vu une boite déployer un réseau 10.0.0.0/8. C'est très vite devenu très compliqué. 😁 😁 😁

Tout ça fait partie d'une Usine logicielle, sensible au vieil adage : Shit In... Shit Out.

====

Pour pouvoir prétendre à candidater dans le monde DevOps, il faut avoir expérimenté de nombreux laboratoires et avoir des certitudes bien ancrées:

• Construire une landing zone de A à Z, et surtout, savoir pourquoi on a utilisé tel ou tel principe. Je donne des pistes : Réseau public, réseau privé, bastion, internet gateway, résilience, multi-zone, multi-région, DRP, VPN, Direct-Connect, etc...

• Usine logicielle permettant la construction d'une "golden image". Cette Golden Image finira dans un repository et tu pourras ensuite la déployer et la paramétrer. Là encore, le pourquoi et le comment ont beaucoup d'importance.

• Evidemment, CI et CD, avec une batterie de tests au milieu. Pourquoi... comment....

• savoir faire toutes les manips sur GIT : pull, clone, push, commit, etc.... (évidemment).... mais aussi, merge requests, releases, patching d'urgence sur une release existante etc...

• Tout ce qui tourne autour des bases de données SQL/NoSQL et de leur scalabilité.

• Tout ce qui tourne autour de la performance : type de disques, accès à du S3 et pourquoi tu le fais, orchestrateurs de type kubernetes, fonctions/lambdas.

====

Si tout ce que je viens de raconter te semble lointain, il va être difficile d'entrer sur le marché freelance au titre du "DevOps" et de prétendre à des TJM au prix du marché. Le freelancing, c'est "proposer une expertise sur un marché". Ce n'est pas "venir pour apprendre". D'ailleurs, en fonction de ton niveau, les entretiens techniques peuvent être assez sanglants. 😬

Cependant, je ne peux que te souhaiter bonne chance et t'encourager à préparer le grand saut vers le DevOps. 👍👍