Les grands groupes embourbés dans l'approche DevOps

Les plateformes DevOps permettent aux équipes de s’en sortir

De nombreuses entreprises ont atteint ce que le compte rendu décrit comme une phase intermédiaire de l’exécution d’une feuille de route DevOps : une phase dans laquelle des problèmes organisationnels entravent l’objectif ultime de déploiements rapides d’applications et de boucles de rétroaction efficaces qui créent une amélioration continue. Pour les équipes qui se trouvent dans le haut du panier, ces obstacles sont entièrement non techniques. Par exemple, elles sont dans l’incapacité à établir des mécanismes de retour d’information suffisants ou le manque de clarté des rôles et responsabilités DevOps, selon le rapport.

C’est là que les plateformes DevOps entrent en jeu, suggèrent les auteurs du document. Les équipes d’ingénieurs construisent de telles « plateformes numériques » pour les entreprises. Ici, le rapport cite une définition de 2018 de l’expression plateforme numérique (digital platform en VO) formulée par Evan Bottcher, directeur de l’ingénierie chez le consultant IT ThoughtWorks : « Une fondation d’API en libre-service, d’outils, de services, de connaissances et de support qui sont agencés comme un produit interne convaincant. »

Certaines entreprises font référence à ces plateformes numériques internes comme étant « la route pavée » pour les équipes de développeurs. Il n’est pas obligatoire de les utiliser, mais c’est le moyen le plus facile de pousser le code vers la production. Les ingénieurs assignés à cette plateforme, souvent des responsables Site Reliability Engineers (SRE), sont chargés de maintenir une forge logicielle et de la penser comme un produit employé en interne.

Acquérir une « mentalité produit » et un état d’esprit axé sur la fourniture de services aux clients est également une partie importante de la construction d’une plateforme DevOps réussie, déclarent les auteurs du rapport lors d’une table ronde virtuelle.

« Vous pouvez donner aux développeurs un ensemble de choses à assembler afin qu’ils puissent se différencier où cela compte », explique Michael Stahnke, vice-président de la plateforme chez le spécialiste de la CI/CD CircleCI. « Nous fabriquons essentiellement des produits pour que les programmeurs puissent aller plus vite ».

Faire des ingénieurs DevOps des product owners

Toutefois, les entreprises doivent éviter de tomber dans des schémas contre-productifs consistant à exiger que les développeurs utilisent en permanence des plateformes DevOps centralisées ou à laisser une équipe éloignée des opérations quotidiennes dicter les décisions relatives aux chaînes d'outils sans aucune flexibilité. Ces ingénieurs doivent réellement commercialiser ces produits auprès des développeurs, et évaluer la qualité de leurs services à l’aide de mesures telles que le net promoter score, plutôt que les données traditionnelles de performance de l’infrastructure.

Les panélistes ont reconnu que peu d’ingénieurs assignés à la conception d’une plateforme DevOps ont une expérience de responsable produit.

« Ma génération d’ingénieurs en infrastructure faits des pieds et des mains pour rattraper son retard, car pour être une équipe logicielle moderne, il faut traiter l’infrastructure comme un produit », assure Charity Majors, cofondatrice de Honeycomb.io, un éditeur spécialisé dans l’observabilité.

Cet aspect du rapport a trouvé un écho chez Andy Domeier, directeur principal des opérations technologiques chez SPS Commerce, un éditeur de solutions analytiques basé à Minneapolis ciblant les entreprises de la supply chain et de la logistique.

Il y a environ 18 mois, l'éditeur a créé un rôle de responsable de produit technique (Technical Product Owner ou TPO) spécifiquement pour inculquer cette mentalité produit, et pour agir comme une sorte de gestionnaire de compte technique pour les équipes DevOps après que SPS ait rencontré des difficultés avec certains aspects de la communication sur sa forge logicielle.

Au départ, les développeurs devaient contacter des ingénieurs responsables de la plateforme DevOps pour faire part de leurs commentaires, en fonction du composant d’infrastructure avec lequel ils travaillaient. Cela s’est avéré être un obstacle à la transmission entre les équipes de développeurs et les équipes SRE, puisque des modules tels que les passerelles API peuvent couvrir plusieurs disciplines.

« Nous avons un TPO qui joue l’office d’un point de contact unique, de sorte que l’équipe de développement n’a plus besoin de savoir à qui envoyer ses commentaires », témoigne Andy Domeier.

SPS a pourvu ce rôle en puisant dans les rangs de ses développeurs. Un ancien développeur senior souhaitait accéder à un rôle d’administration. Il supervise désormais une petite équipe « TPO ». Cette équipe conduit la gestion du cycle de vie des produits, tant pour les services destinés aux clients que pour les services internes.

L’expérience de SPS met en évidence un autre élément clé pour sortir du plateau DevOps cité par le rapport State of DevOps : l’adhésion au niveau le plus élevé de la hiérarchie.

« Nous avons demandé à la direction si elle était prête à financer ce rôle et elle a accepté notre requête », déclare Andy Domeier.

« Avant cela, les responsables des différentes équipes chargées de la plateforme faisaient ce travail… une grande partie de tout cela se résume à [prioriser] l’expérience des développeurs. »

Des plateformes aux flux de valeur

Le rapport State of DevOps mentionne que la plupart des équipes qu’il qualifie de très évoluées – celles qui livrent le code le plus rapidement et le plus fréquemment, avec les boucles de retour d’information les plus étroites pour les développeurs – font le plus grand usage de plateformes internes pour leurs équipes pour des fonctions telles que l’authentification des utilisateurs et des services et l’orchestration des conteneurs.

Le rapport ne cite pas Capital One en exemple, mais la banque est largement considérée comme une organisation technique très évoluée. Cette année, l’entreprise a fermé son dernier centre de données sur site, et base désormais toutes ses opérations informatiques dans le cloud.

La société maintient une plateforme d’API « fiables » pour les partenaires, appelée Capital One DevExchange, mais dans l’ensemble, elle a dépassé la centralisation de fonctions IT spécifiques pour penser en termes de domaines de produits, affirme Mindy Ferguson, vice-présidente chez Capital One.

« Nous nous approchons le plus possible de la full-stack », déclare-t-elle. « Mais nous définissons la plateforme un peu différemment ».

Au lieu de séparer les équipes DevOps et ceux responsables de la forge, les ingénieurs de Capital One travaillent sur tous les aspects des applications et de l’infrastructure, alignés sur les défis commerciaux tels que la lutte contre la fraude, plutôt que sur les domaines d’expertise technique, selon Mindy Ferguson.

Cela peut être la marque d’une organisation très perfectionnée, selon le rapport State of DevOps.

« Les équipes très évoluées ont tendance à limiter la charge cognitive superflue des équipes de livraison (grâce à de bonnes pratiques, à l’automatisation et au soutien d’autres équipes), ce qui leur permet de se concentrer sur les besoins de l’entreprise », indique le rapport.

Selon le document, au stade hautement évolué, les principaux défis consistent à gérer les applications existantes et à maintenir les compétences des membres de l’équipe à mesure que la technologie évolue. Si Capital One a relevé le premier défi grâce à sa migration vers le cloud, le recrutement d’employés IT plus qualifiés figure parmi ses objectifs majeurs pour 2021.

Capital One prévoit d’embaucher 3 000 collaborateurs IT supplémentaires avant la fin de l’année pour soutenir les efforts en matière d’intelligence artificielle et d’apprentissage automatique, ainsi que pour développer ses équipes d’ingénierie du cloud.

Bien que les acteurs du secteur aient souvent mentionné une pénurie de compétences informatiques ces dernières années, Mindy Ferguson est convaincu que Capital One peut attirer des candidats qualifiés. L’entreprise dispose de plusieurs programmes de certification technique pour les nouveaux employés, ainsi que d’un programme de formation continue pour tout le personnel appelé Tech College. Elle a également établi des partenariats avec des collèges, des universités et des associations telles que Women Who Code pour l’aider à atteindre ses objectifs en matière de diversité et d’inclusion.

« Nous avons un objectif audacieux », assure Mindy Ferguson. « Le défi concerne moins le nombre de personnes que la façon dont nous continuons à accomplir les tâches que nous exécutons aujourd’hui à l’échelle… ouvrir notre culture, aider les gens à comprendre notre mission, au cours d’une période un peu différente à cause de cette organisation hybride du travail. »