DevOps, SRE, ingénieur plateforme, explication du rôle cloud

Comment en sommes-nous arrivés là ? Quelles sont les vraies différences (le cas échéant) entre ces rôles ?

L'émergence de nouveaux rôles informatiques

À mesure que le DevOps gagne du terrain, les rôles et les responsabilités dans l'écosystème DevOps deviennent de plus en plus flous. Cette ambiguïté a conduit à l'émergence de rôles connexes tels que celui d'ingénieur en fiabilité de site (SRE), d'ingénieur cloud et d'ingénieur plateforme. Chaque personnage a sa propre concentration et ses propres compétences.

Inspiré par l'approche de Google en matière de gestion des grands systèmes, SRE combine les pratiques d'ingénierie logicielle avec les opérations pour garantir la fiabilité et les performances du service. Les ingénieurs cloud se concentrent sur le déploiement et la gestion de l'infrastructure cloud, en tirant parti de plates-formes telles qu'AWS, Azure ou Google Cloud pour optimiser l'évolutivité et l'efficacité. Les ingénieurs de plate-forme, quant à eux, se concentrent sur la conception et la maintenance d'une plate-forme de développement interne qui offre aux développeurs des fonctionnalités en libre-service pour gérer les aspects opérationnels du cycle de vie des applications.

Bien qu'il y ait un chevauchement entre ces rôles, ils ont chacun des domaines d'expertise et d'intérêt différents. Les SRE donnent la priorité à la fiabilité et à la résilience, les ingénieurs cloud se concentrent sur la gestion de l'infrastructure cloud et les ingénieurs de plate-forme se concentrent sur la création de plates-formes centrées sur les développeurs. Comprendre les nuances de ces rôles est essentiel pour que les organisations puissent structurer efficacement leurs équipes et exploiter tout le potentiel des principes DevOps dans leurs pipelines de livraison de logiciels.

Résistance et confusion DevOps

D'après mon expérience, réaliser la vision originale du DevOps, c'est-à-dire atteindre un équilibre optimal entre spécialisation, collaboration et partage, a été un défi pour de nombreuses organisations.

Le rapport 2021 sur l'état du DevOps de Puppet a révélé que seulement 18 % des personnes interrogées se considéraient comme des praticiens DevOps « hautement développés ». Comme le décrit l’équipe DevOps Topologies, certains de ces avantages proviennent de circonstances particulières. Par exemple, des organisations comme Netflix et Facebook disposent sans doute d’un seul produit basé sur le Web, ce qui réduit les différences entre les flux de produits et impose ainsi une séparation accrue entre les développeurs et le personnel opérationnel.

D’autres imposent des conditions et des normes de collaboration strictes, comme l’équipe SRE de Google (nous en parlerons plus tard !), qui a également le pouvoir de rejeter les logiciels qui compromettent les performances du système.

De nombreuses personnes aux niveaux inférieurs de développement DevOps ont du mal à réaliser pleinement les promesses de DevOps en raison de la résistance organisationnelle au changement, du manque de compétences, du manque d'automatisation ou de l'architecture existante. Par conséquent, le groupe emploiera diverses approches différentes pour la mise en œuvre de DevOps, y compris certains des « anti-types » DevOps décrits dans Topologies DevOps.

Pour de nombreuses personnes, le développement et les opérations sont encore cloisonnés. Pour d'autres, DevOps sera une équipe d'outils qui fait partie du développement et est responsable des pipelines de déploiement, de la gestion de la configuration, etc., mais reste isolée des opérations. Pour d’autres, DevOps sera une simple réinvention de SysAdmin, avec des ingénieurs DevOps embauchés dans les équipes opérationnelles et leurs attentes en matière de compétences élargies, mais aucun véritable changement culturel ne se produit.

L'adoption rapide de l'utilisation du cloud public a également renforcé la confiance dans les perspectives d'une approche DevOps en libre-service. Mais être capable de fournir et de provisionner une infrastructure à la demande est loin de permettre aux développeurs de déployer et d'exécuter des applications et des services de bout en bout. Malheureusement, toutes les organisations ne le comprennent pas, c'est pourquoi l'automatisation dans de nombreuses organisations se bloque au niveau de l'automatisation de l'infrastructure et de la gestion de la configuration.

DevOps a tellement d'incarnations différentes qu'il n'est pas surprenant que les spécifications des rôles DevOps ne soient pas clairement définies. Pour une organisation, cela pourrait être synonyme d'ingénierie de déploiement au sens le plus étroit (peut-être simplement la création d'un pipeline CI/CD), tandis que d'un autre côté, cela pourrait essentiellement être une réinvention des opérations, avec la possibilité d'écrire une infrastructure. Compétences supplémentaires pour le codage , automatisation du déploiement et outils internes. Pour d’autres, il peut s’agir de n’importe quelle nuance de gris, nous avons donc ici une liste vertigineuse d’offres d’emploi DevOps.

Rôles SRE, Cloud Engineer et Platform Engineer

Ainsi, selon l'organisation qui recrute, un ingénieur DevOps peut être un ingénieur entièrement axé sur le déploiement ou un administrateur système plus moderne.

Qu'en est-il des autres rôles connexes : SRE, ingénieur cloud et ingénieur plateforme ? Voici mes réflexions sur chaque question :

Site Reliability Engineer

Le concept de SRE a été introduit par Ben Traynor chez Google, qui l'a décrit comme "Lorsque vous traitez les opérations comme un problème logiciel et que vous les employez avec des ingénieurs logiciels, que faire tu comprends quand tu fais ça ? L’idée est d’amener les gens à combiner leurs compétences opérationnelles et celles en développement logiciel pour concevoir et exécuter des systèmes de production.

Les ingénieurs en fiabilité de site (SRE) combinent des pratiques d'ingénierie logicielle avec des responsabilités opérationnelles pour garantir la fiabilité, l'évolutivité et les performances des systèmes et des services. Ils se spécialisent dans la conception et la mise en œuvre de solutions automatisées pour gérer et surveiller l'infrastructure, déployer des logiciels et répondre de manière proactive aux incidents. Les SRE travaillent en étroite collaboration avec les équipes de développement pour établir et appliquer des normes de fiabilité, définir des objectifs de niveau de service (SLO) et mettre en œuvre des pratiques telles que la budgétisation des erreurs pour équilibrer l'innovation et la stabilité du système. Leur objectif est de maintenir les environnements de production hautement disponibles et résilients grâce à une amélioration et une itération continues.

Fiabilité du service La définition d'un accord de niveau de service (SLA) est essentielle pour garantir que les équipes de développement fournissent la preuve initiale que le logiciel répond à des normes opérationnelles strictes avant d'être accepté pour le déploiement. De plus, les SRE s'efforcent de rendre les systèmes d'infrastructure plus évolutifs et maintenables, notamment en concevant et en exploitant des pipelines CI/CD standardisés et des plates-formes d'infrastructure cloud que les développeurs peuvent utiliser à cette fin.

Comme vous pouvez le constater, cela recoupe considérablement la définition que certaines personnes donnent d'un ingénieur DevOps. Alors peut-être qu’une façon de penser à la différence est la suivante. En revanche, l’objectif initial du DevOps était d’augmenter la vitesse de publication, tandis que l’objectif du SRE est de créer des systèmes plus fiables dans un contexte de taille croissante des systèmes et de complexité des produits. D’une certaine manière, les deux se sont rencontrés au milieu.

Ingénieur Cloud

À mesure que les capacités du cloud continuent de croître, certaines organisations ont créé des rôles dédiés aux ingénieurs cloud. De même, bien qu’il n’existe pas de règles strictes, les ingénieurs cloud se concentrent généralement sur le déploiement et la gestion de l’infrastructure cloud et savent comment créer des environnements pour les applications cloud natives. Ils deviendront experts en AWS/Azure/Google Cloud Platform. Selon le degré de chevauchement avec les responsabilités d'ingénieur DevOps, ils peuvent également maîtriser Terraform, Kubernetes, etc.

De plus, les ingénieurs cloud utilisent leur expertise dans les technologies cloud pour concevoir, mettre en œuvre et maintenir des architectures cloud évolutives et élastiques, garantissant que les applications et les systèmes fonctionnent efficacement et en toute sécurité dans les environnements cloud. Les ingénieurs cloud peuvent également travailler sur des stratégies d'automatisation, de surveillance et d'optimisation des coûts afin de maximiser les avantages du cloud computing pour leur organisation.

À mesure que l'adoption du cloud continue de progresser, le rôle d'ingénieur cloud englobe ce qui était auparavant connu sous le nom d'ingénieur d'infrastructure, avec un accent initial sur la gestion de l'infrastructure cloud et sur site.

Ingénieurs de plate-forme

Les plates-formes de développement internes (IDP) sont apparues comme la dernière solution au défi consistant à équilibrer la productivité des développeurs avec le contrôle et la stabilité du système. Les ingénieurs de plate-forme conçoivent et maintiennent les IDP pour fournir aux développeurs des capacités en libre-service leur permettant de gérer de manière indépendante les aspects opérationnels de l'ensemble du cycle de vie des applications : des flux de travail CI/CD ; le provisionnement de l'infrastructure et l'orchestration des conteneurs, la surveillance, les alertes et l'observabilité.

De nombreux développeurs ne veulent tout simplement pas effectuer d’opérations – du moins pas au sens traditionnel du terme. En tant qu'artiste créatif, un développeur ne veut pas se soucier du fonctionnement de l'infrastructure. Il est donc essentiel que la plateforme soit considérée comme un produit permettant le contrôle en créant une expérience de développement en libre-service convaincante, plutôt qu'en appliquant des normes et des processus.

Désambiguïsation : clarifier les attentes en matière de rôle

Alors, où sont les candidats pour tous ces différents rôles ? Peut-être que pour l'instant (au moins jusqu'à ce que les méthodes de mise en œuvre DevOps deviennent plus courantes), la seule réponse réaliste est de vous assurer de demander tout ce dont vous avez besoin lors de l'entretien, en étant clair sur les attentes du rôle et le contexte organisationnel dans lequel vous serez embauché.

Pour les recruteurs, vous pouvez décider de ratisser large et de remplir vos offres d'emploi avec des mots-clés populaires pour diverses raisons. Mais en fin de compte, les détails sur l'expérience et les capacités du candidat doivent émerger au cours du processus d'entretien et des conversations avec les références.

À mon avis, que vous soyez DevOps, ingénieur de plateforme, ingénieur cloud ou même SRE, veiller à répondre à tous les besoins opérationnels de vos développeurs les aidera à se concentrer sur la création du prochain meilleur produit.