Ingénierie de plateforme et plateformes internes de développement

Le problème que résolvent les plateformes

En 2006, le directeur technique d’Amazon, Werner Vogels, a résumé le modèle de fonctionnement de son entreprise par you build it, you run it (vous le construisez, vous l’exploitez) : l’équipe qui écrit un service le déploie, le supervise et le corrige aussi. L’idée est devenue centrale pour le DevOps et pour les microservices, et elle fonctionne : les équipes qui exploitent leur propre logiciel subissent les conséquences de leurs choix de conception et les corrigent. Mais l’outillage cloud native décrit dans ce chapitre est vaste. Une équipe produit qui doit aujourd’hui construire, exploiter et sécuriser un service peut avoir besoin de comprendre les images de conteneurs, les objets Kubernetes, l’infrastructure en tant que code, les pipelines, l’observabilité, la gestion des secrets, les politiques réseau, l’analyse de la chaîne d’approvisionnement et le contrôle des coûts, avant d’écrire la moindre ligne de logique métier.

Lorsque chaque équipe résout tout cela seule, trois choses se produisent. Les efforts sont dupliqués : dix équipes écrivent dix pipelines légèrement différents. La qualité varie : certaines équipes chiffrent leurs bases de données et configurent des sauvegardes, d’autres oublient. Et le temps que les équipes produit consacrent à l’infrastructure est du temps qu’elles ne consacrent pas au produit. L’ingénierie de plateforme (platform engineering) est la réponse : une équipe dédiée construit une plateforme interne de développement (IDP) qui regroupe ces capacités pour que les équipes produit puissent les utiliser en libre-service.

L’article d’Evan Bottcher publié en 2018 sur martinfowler.com en donne une description très citée : une plateforme numérique est un socle d’API, d’outils, de services, de connaissances et de support en libre-service, organisés comme un produit interne convaincant. Chaque élément de cette description compte. En libre-service signifie pas de tickets pour les besoins courants. Connaissances et support signifie de la documentation et des personnes, pas seulement du logiciel. Convaincant signifie que les équipes choisissent de l’utiliser parce que c’est mieux que de faire le travail elles-mêmes. Produit interne signifie qu’elle est gérée comme un produit, avec des clients, plutôt que comme un projet ou un centre de coûts.

Une IDP n’est pas un produit unique. C’est généralement une intégration d’outils existants (un système de CI, un contrôleur GitOps, les services managés d’un fournisseur cloud, une pile d’observabilité, un coffre de secrets) derrière des interfaces cohérentes et des valeurs par défaut raisonnables. Le travail propre à l’équipe plateforme consiste à les choisir, les intégrer, les documenter et les prendre en charge, et à concevoir l’expérience de leur utilisation, pas à écrire un nouvel orchestrateur.

Golden paths et paved roads

Ce qu’une jeune plateforme peut offrir de plus précieux est un golden path (chemin balisé) : une manière prescriptive, prise en charge et documentée d’accomplir de bout en bout une tâche courante, comme créer un nouveau service et le mettre en production. Spotify a popularisé le terme (son blog d’ingénierie a décrit ses golden paths en 2020) ; Netflix parle de paved road (route goudronnée). La métaphore est précise. Une route goudronnée est l’itinéraire le plus facile, et elle est entretenue, mais vous pouvez toujours partir hors piste si vous avez une bonne raison ; vous ne bénéficiez simplement plus du soutien de la route.

Un bon golden path a cinq propriétés. Il est de bout en bout : il mène une équipe d’un dépôt vide à un service supervisé en production, et pas seulement à travers une étape. Il est prescriptif : il fait les choix courants (versions de langage, format de journalisation, stratégie de déploiement, réglages par défaut de la base de données) pour que les équipes n’aient pas à les faire. Il est facultatif : les équipes aux besoins inhabituels peuvent le quitter, ce qui oblige l’équipe plateforme à rester honnête sur la question de savoir si le chemin est vraiment meilleur. Il est pris en charge : quand il casse, l’équipe plateforme le répare. Et il est évolutif : les services créés à partir du modèle de l’an dernier reçoivent des mises à jour, au lieu de rester figés dans leur version de départ.

Backstage et les portails des développeurs

Un portail des développeurs est la porte d’entrée de nombreuses plateformes. Le plus connu est Backstage, construit en interne chez Spotify, passé en open source en mars 2020, accepté par la Cloud Native Computing Foundation (CNCF) comme projet sandbox en septembre 2020 et promu au stade d’incubation en mars 2022. Ses fonctions principales sont un catalogue logiciel, dans lequel chaque service, site web, bibliothèque, API et ressource est enregistré avec son propriétaire et ses relations ; des modèles logiciels, qui génèrent de nouveaux projets à partir des modèles des golden paths ; TechDocs, qui publie la documentation écrite en Markdown à côté du code ; et un vaste écosystème de plug-ins qui affichent les pipelines, l’état Kubernetes, les coûts et les incidents à côté de chaque entrée du catalogue.

Chaque composant se décrit lui-même dans un petit fichier conservé dans son propre dépôt, de sorte que les informations de propriété vivent avec le code et sont relues comme du code :

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: restaurant-ratings
  description: Stores and serves customer ratings of restaurants
  tags: [python, http]
spec:
  type: service
  lifecycle: production
  owner: team-restaurants
  system: restaurant-discovery
  providesApis: [ratings-api]
  dependsOn: [resource:ratings-db]

Deux mises en garde. Backstage est un framework qu’une organisation assemble et exploite, ce qui exige généralement des ingénieurs qui maîtrisent TypeScript et React, et ses plug-ins sont de qualité variable ; des services Backstage managés et des portails commerciaux existent pour les équipes qui ne veulent pas l’exploiter elles-mêmes. Plus important encore, un portail n’est pas une plateforme. Un beau portail placé devant des processus manuels pilotés par les tickets ne fait qu’afficher la file d’attente de façon plus attrayante. Commencez par les capacités et le golden path ; ajoutez un portail quand il y a derrière assez de choses qui valent la peine d’être trouvées.

La plateforme en tant que produit

L’idée la plus importante de l’ingénierie de plateforme est que la plateforme est un produit et que les développeurs qui l’utilisent sont ses clients. Cela suppose un responsable produit ou un responsable de la plateforme qui porte la feuille de route ; de la recherche utilisateur (entretiens, observation d’une équipe qui crée un service, enquêtes) avant de construire ; une documentation et une prise en main traitées comme des fonctionnalités ; des objectifs de niveau de service publiés pour la plateforme elle-même ; des politiques de versionnement et de dépréciation pour que les équipes puissent planifier ; et, surtout, une adoption méritée plutôt qu’imposée. Si les équipes évitent la plateforme, c’est un retour du marché, pas de l’insubordination.

Team Topologies (Matthew Skelton et Manuel Pais, 2019), présenté à la section 11.5, fournit le modèle organisationnel. Une équipe plateforme existe pour alléger la charge des équipes orientées flux, celles qui sont alignées sur un flux de changements métier comme la commande ou l’affectation des livreurs, et interagit avec elles principalement en mode X-as-a-Service : une offre claire, en libre-service, qui demande peu de collaboration. Le mode collaboration est utilisé délibérément et brièvement, par exemple pour concevoir une nouvelle capacité avec une ou deux équipes pionnières. Skelton et Pais ont aussi forgé la notion de plateforme viable la plus fine (thinnest viable platform) : la plus petite plateforme qui aide réellement, et qui, pour une petite organisation, peut se résumer à une page de wiki bien écrite listant les services approuvés et à un modèle de pipeline partagé.

Cela signifie aussi que la plateforme doit faire jouer la loi de Conway en sa faveur : les interfaces de la plateforme deviennent les frontières entre l’équipe plateforme et chaque équipe produit ; elles doivent donc être stables, documentées et étroites, comme toute bonne abstraction.

Le libre-service avec garde-fous

Le libre-service supprime la file d’attente ; les garde-fous le rendent sûr. La différence avec les contrôles traditionnels tient à l’endroit où la vérification a lieu. Un point de validation (gate) est une personne qui doit approuver une demande, comme un comité consultatif des changements ou un administrateur de bases de données qui examine un ticket. Un garde-fou (guardrail) est une limite automatique qui laisse passer tout ce qui respecte la politique et bloque ou signale ce qui ne la respecte pas, au moment même de la demande. Les garde-fous sont généralement écrits sous forme de politique en tant que code (policy as code, présentée à la section 10.4) et appliqués dans les pipelines, les contrôleurs d’admission et les politiques d’organisation du cloud.

Les bons garde-fous partagent trois propriétés : ils donnent un message clair qui explique ce qui a été bloqué et comment corriger le problème ; ils sont versionnés et testés comme du code, avec une période d’avertissements avant qu’une nouvelle règle ne commence à bloquer ; et ils s’accompagnent d’une procédure documentée pour les exceptions justifiées, car un garde-fou sans procédure d’exception redevient un point de validation dès la première fois qu’il se trompe.

Réduire la charge cognitive, sans tout cacher

Team Topologies emprunte la notion de charge cognitive aux recherches en sciences de l’éducation de John Sweller et en distingue trois types. La charge intrinsèque est inhérente à la tâche, comme comprendre le fonctionnement des frais de livraison. La charge extrinsèque vient de l’environnement, comme se souvenir des douze étapes pour demander une base de données. La charge pertinente est l’effort d’apprentissage qui facilite le travail futur, comme comprendre le domaine plus en profondeur. Une plateforme doit éliminer la charge extrinsèque pour que les équipes puissent consacrer leur attention limitée à la charge intrinsèque et à la charge pertinente de leur propre domaine.

Cela ne veut pas dire tout cacher. Une équipe qui exploite son service doit toujours comprendre comment il se comporte en production : sa consommation de ressources, ses modes de défaillance, sa latence et ses coûts. Les abstractions qui cachent trop fuient au pire moment, pendant un incident, quand l’équipe découvre qu’elle ne peut pas voir les journaux ou ne sait pas sur quelle gamme de base de données elle tourne. Les bonnes plateformes sont transparentes : elles fournissent des valeurs par défaut raisonnables et des interfaces simples, tout en laissant les équipes regarder en dessous et modifier les réglages quand elles en ont besoin.

Mesurer si la plateforme fonctionne

La valeur d’une plateforme se manifeste dans les résultats des autres équipes : c’est donc là que ses mesures doivent porter. Les mesures utiles se répartissent en quatre groupes, et un ensemble équilibré en prend au moins une dans chacun.

Le cadre SPACE, publié dans ACM Queue en 2021 par Nicole Forsgren, Margaret-Anne Storey et des collègues de GitHub, de Microsoft Research et de l’Université de Victoria, avertit que la productivité des développeurs ne peut pas se résumer à un seul chiffre. Il nomme cinq dimensions : la satisfaction et le bien-être, la performance, l’activité, la communication et la collaboration, ainsi que l’efficacité et le flux. Il recommande de mesurer plusieurs dimensions à la fois, dont au moins une mesure perçue comme une enquête, et de ne jamais juger les individus sur des comptages d’activité comme le nombre de commits ou de lignes de code.

Les données sur les plateformes sont encourageantes, mais pas inconditionnelles. Le rapport DORA 2024 Accelerate State of DevOps a constaté que les utilisateurs de plateformes internes de développement déclaraient une productivité individuelle supérieure d’environ 8 % et une performance d’équipe supérieure de 10 %, mais que le débit de livraison logicielle et la stabilité des changements étaient inférieurs de 8 % et 14 %. Le rapport avance des explications possibles, comme des passages de relais supplémentaires et la couche de plateforme qui ajoute elle-même des étapes, et la leçon pour les architectes est de mesurer les résultats de livraison autant que la satisfaction, et de s’attendre à un creux pendant qu’une plateforme mûrit.

Risques et modes de défaillance

Les initiatives de plateforme échouent de manières reconnaissables. La plus courante consiste à construire une plateforme dont personne ne veut : une équipe passe un an à bâtir une plateforme généraliste ambitieuse, la lance, et découvre que les équipes produit ont déjà des solutions qui fonctionnent et pas de temps pour migrer. Commencer petit, avec de vrais utilisateurs et un seul golden path, en est l’antidote. La deuxième est l’équipe d’exploitation renommée : une équipe d’infrastructure est rebaptisée équipe plateforme mais travaille toujours à partir d’une file de tickets, si bien que rien ne change, sauf les intitulés de poste. Si les demandes courantes exigent encore un ticket et une personne, ce n’est pas encore une plateforme.

Les autres risques sont d’imposer l’adoption, ce qui supprime les retours qui maintiennent l’utilité d’une plateforme ; la sur-abstraction, où une couche maison masque si complètement les outils sous-jacents que les équipes ne peuvent ni la déboguer ni l’étendre, et où l’équipe plateforme devient un goulot d’étranglement pour chaque changement ; la négligence de la longue traîne des services créés à partir d’anciens modèles ; et une plateforme devenue point de défaillance unique, dont la panne arrête tous les déploiements. À l’inverse, une petite organisation peut n’avoir besoin d’aucune équipe plateforme : quelques modèles partagés, entretenus par des volontaires, peuvent constituer la plateforme viable la plus fine pendant des années.