De manière générale apprendre de nouveaux trucs est toujours intéressant. Je pense personnellement que les meilleurs profils du marché sont des profils ayant une forte expertise dans plusieurs domaines, ce qui leur permet d’avoir une vue d’ensemble des problématiques de l’entreprise. Cela facilite également grandement la capacité à proposer puis implémenter une vision technique et à faire le pont entre différentes équipes. C’est un peu mon cas où j’ai toujours travaillé à la frontière du dev et de l’ops et donc suis capable d’intervenir et accompagner sur les deux tableaux selon les besoins.

Par exemple, je considère aujourd’hui qu’il est important qu’un Sysadmin/DevOps/SRE (le nom du job est un détail) doit savoir coder. Quand je dis doit savoir coder, je ne dis pas être capable de faire du shell dégueulasse, je dis être en capacité d’être mis dans une équipe de dev et de s’en sortir dans un temps raisonnable, et donc de maîtriser à minima les bases de l’ingéniérie logicielle (design patterns, concurrence et parallélisme, tests et mocks, maîtrise basique du DDD). Soyez rassuré si vous êtes dans ces métiers mais manquez de compétences en développement: cela s’apprend. Dans mon entreprise nous formons en interne au développement par exemple. C’est aussi là que l’on se rend compte qu’avoir des équipes avec des profils venant des deux mondes est intéressant (nous recrutons également des profils purs dev que nous formons à l’infrastructure).

Mais revenons aux développeurs. Apprendre l’infra sera donc en effet un gros plus pour eux. J’adore personnellement ce genre de profils. Mais apprendre la data (analyse, machine learning, stockage…​) serait également un gros plus, ou bien apprendre la programmation système ou kernel, ou le réseau…​ La connaissance n’est jamais perdue et on ne peut de toute façon pas être expert en tout.
Donc apprendre l’infrastructure est intéressant mais ce n’est pas obligatoire. Il y a pourtant certaines bases à maîtriser.

Je suis convaincu qu’une entreprise produisant du logiciel (je parle du type d’entreprise que je connais: services en ligne, sites web, solutions SaaS, services Cloud, logiciels édveloppés et utilisés en interne type SI grands groupes…​) ne peut être efficace que si les développeurs peuvent travailler en autonomie du développement à la production jusqu’à l’exploitation. Qu’est ce que cela veut dire ?

Les équipes infrastructure ne doivent pas être un point de blocage ou de friction lorsqu’un développeur doit déployer en production. Une mise en prod doit devenir quelque chose de simple à réaliser, qui peut être fait de manière répétable et à tout moment. Cela ne veut pas dire qu’on va donner les accès admin de la production aux dev: on va au contraire faire en sorte qu’un déploiement soit une procédure standard et automatisée. Dans ma boîte actuelle on déploie ~80 fois en production par jour, heureusement que je ne suis pas contacté à chaque fois pour valider le déploiement, hein ?
Par exemple, à chaque fois qu’une nouvelle release est réalisée pour une application, ou qu’un commit est merge sur la branche principale, la plateforme d’intégration continue peut lancer automatiquement (ou via un action manuelle d’un dev comme cliquer sur un bouton) le déploiement. Ici, les dev n’ont pas accès à la prod: ils ont accès à une abstraction permettant de déclencher l’action de mise en production de manière fiable. De la même manière un rollback doit être une simple action accessible également aux dev.

Il est également important ici pour les dev de connaître la façon dont le déploiement va se réaliser, notamment son déroulement, quel que soit le type d’infrastructure utilisé (PaaS, Kubernetes…​):

On voit dans ces quelques exemples que l’infrastructure a un impact sur la conception de l’application et que cette dernière doit avoir un certain comportement pour fonctionner sans problème. Il est extrêmement courant d’avoir des applications perdant des requêtes HTTP (donc retournant des erreurs aux clients finaux) during les mises à jour par exemple car les contraintes infrastructures ne sont pas comprises.

De même, si l’application a un problème en production (par exemple une application HTTP commence à retourner des erreurs 500), ce ne sont pas les équipes infrastructure qui doivent être alertées en premier. Pourquoi ? Car ce sont les équipes de dev qui ont la connaissance de l’application.
En tant que SRE, que puis-je faire si un bug applicatif cause un problème dans une application sur lequel je n’ai jamais travaillé, voir dont je ne connais ni le langage ni le métier ? Il n’y a donc aucun intêret à avoir un intermédiaire "ops" qui se contentera de toute façon de retransmettre l’alerte aux équipes dev concernées, cela fera perdre du temps à tout le monde.

Cela veut dire que les dev doivent aussi maîtriser la partie observability de leurs applications:

Cela ne veut pas dire qu’il n’y a pas des équipes ops/SRE en support, qui seront là pour mettre en place les outils nécessaires pour rendre cela possible et accompagner si besoin les équipes sur ces bonnes pratiques.

Bref, on voit que de nombreuses choses liées à l’infrastructures doivent être compréhensibles pour les développeurs. J’aurai également pu parler de pipelines de CI où là aussi une certaine autonomie est attendue pour définir les étapes de tests, lint, build et pour investiguer des jobs en echec.

Bien sûr, un dev junior ne peut pas maitrîser tout ça. Mais au bout de plusieurs années de dev maîtriser ces sujets devient essentiel. Au délà de la partie métier (compréhension du besoin du client, organisation…​) et technique pure dev (architecture logicielle), les profils senior et plus doivent élargir leurs horizons et comprendre comment les applications s’intègrent dans le SI au sens large. Travailler sur des architectures orientées service ou des systèmes distribués que l’on retrouve de plus en plus (message bus, base de données NoSQL, ou même sur les communications inter services) demandent d’avoir des compétences transverses. J’aurai également pu citer une maitrîse basique du réseau (HTTP/gRPC, TCP, TLS, UDP, DNS, base du routage, load balancing…​) comme autre compétences importantes, voir des compétences systèmes ou hardware sur des applications demandant de très hautes performances (pattern d’accès au disque, epoll…​).

Je pense que ce sont les équipes qui ont intégrées ces éléments dans les compétences des développeurs qui travaillent le plus efficacement aujourd’hui.
Mais je le répète, les dev ne remplacent pas les ops, on ne demande pas aux dev ici de déployer des clusters Kubernetes ou de configurer des machines virtuelles, mais d’avoir la maîtrise totale de leurs applications.

J’ai déjà produit pas mal de contenu sur le sujet que je repartage ici:

Avoir certaines compétences infra est non seulement utile mais indispensable. Pas besoin d’être un expert de Linux, du cloud ou de l’orchestration de conteneurs pour être développeur, mais des bases sont attendues et si des gens veulent aller plus loin c’est très bien aussi: l’industrie a besoin de ces profils hybrides ayants des expertises variées.