Matthew Liste, vice-président exécutif et responsable mondial de l’infrastructure chez American Express, estime qu’une plateforme technique performante ne se mesure pas au nombre de ses composants, mais à sa capacité à dissimuler la complexité et à offrir aux développeurs une expérience stable et claire. Lors de sa présentation à QCon San Francisco, Liste s’est appuyé sur plus de 20 années consacrées à la construction de plateformes et d’infrastructures pour des systèmes critiques chez Goldman Sachs, JPMorgan Chase et American Express.
Les plateformes évoquées par Liste servent un grand nombre de développeurs internes : environ 20 000 utilisateurs chez American Express et environ 60 000 chez JPMorgan Chase. Malgré la différence d’échelle avec les fournisseurs de services cloud, il estime que les mêmes principes fondamentaux s’appliquent à toute équipe qui construit une couche dont d’autres dépendent.
Une bonne plateforme dissimule la complexité sans dissimuler ce qui se passe
Liste commence par définir la plateforme comme un ensemble de technologies intégrées qui constitue une base pour construire des applications. Il la compare aux services d’eau et d’assainissement : l’utilisateur ne pense pas à l’infrastructure qui les sous-tend tant qu’elle fonctionne, mais la remarque immédiatement lorsqu’elle tombe en panne.
L’expérience de la plateforme doit donc être intuitive et utiliser des composants communs et interchangeables, tels que des fondations unifiées pour la supervision, l’identité et les espaces de noms. Cette composabilité rapproche la plateforme de briques Lego, plutôt que d’un ensemble de services distincts qui ne fonctionnent ensemble qu’au prix d’efforts supplémentaires.
La stabilité, la sécurité et l’évolutivité ne sont pas facultatives
Liste définit ce qu’il appelle les « trois piliers » : la stabilité, la sécurité et l’évolutivité. Le niveau de disponibilité requis varie selon la valeur du système ; les systèmes d’autorisation des cartes de crédit d’American Express fonctionnent, selon sa présentation, à des niveaux pouvant atteindre six neuf, tandis que d’autres systèmes peuvent tolérer davantage d’interruptions.
Il souligne également que le succès initial peut dissimuler des problèmes d’évolutivité. Une plateforme qui fonctionne bien à ses débuts peut rencontrer des goulots d’étranglement lorsque son utilisation augmente, ce qui affecte directement sa stabilité. Il faut donc définir les objectifs de niveau de service (SLO) avec les consommateurs et les respecter dans la durée, et pas seulement le jour du lancement.
La mise à jour continue et la réduction du travail sans valeur distinctive
Liste considère que maintenir la plateforme à jour est l’une des tâches les plus difficiles et les plus susceptibles d’être repoussées. L’accumulation de mises à niveau différées peut rendre le passage à une version plus récente coûteux et affecter les clients. Il propose un critère interne qu’il appelle 0114 : zéro personne pour la maintenance régulière grâce à l’automatisation, la capacité à mettre à niveau tous les composants du parc, l’achèvement de la mise à niveau en moins d’une journée et l’exécution d’un cycle de mise à jour tous les 14 jours ou moins.
Il préconise également de ne pas reconstruire ce qui est déjà disponible avec une qualité suffisante. Au lieu d’écrire un nouveau moteur PostgreSQL, il donne l’exemple de la construction d’une couche de contrôle qui effectue une sauvegarde quotidienne vers un stockage objet, ce qui correspond à la partie nécessaire pour satisfaire les exigences réglementaires. L’idée est de se concentrer sur la valeur dont l’entreprise a besoin, et non sur la tâche la plus intéressante sur le plan de l’ingénierie.
Des décisions claires et une relation contractuelle avec les consommateurs
Les responsables des plateformes doivent écouter leurs clients, mais pas exécuter chaque demande. Les ressources sont limitées et le maintien de fonctionnalités anciennes sans retrait accumule la dette technique et empêche de développer ce qui est plus important. La plateforme doit donc avoir une « position » claire : définir ce qu’elle prendra en charge, ce à quoi elle mettra fin et ce qui sert la majorité des utilisateurs.
Cela comprend la définition de limites formelles des responsabilités au moyen des interfaces de programmation, des accords de niveau de service et des processus. Il ne suffit pas que l’équipe sache ce qu’elle fournit ; le consommateur doit également savoir ce qui lui incombe et quelles limites la plateforme ne franchit pas. Liste compare les plateformes à des composants aux formes fixes : une équipe limitée ne peut pas construire un produit personnalisé pour chaque client.
L’expérience pratique : expérimenter tôt et utiliser l’abstraction sans masquer les détails
Liste conseille d’échouer rapidement et fréquemment après avoir décidé de construire, tout en protégeant les clients pendant la transition. Il cite les premières expériences menées avec les conteneurs Linux et différents outils d’orchestration, qui ont finalement conduit à une transition vers Kubernetes ; l’expérimentation précoce a permis à l’équipe d’apprendre avant d’attendre la maturité d’une solution unique.
En revanche, les couches d’abstraction ne doivent pas masquer ce qui se passe en dessous. Il est possible de fournir une interface utilisateur, des interfaces de programmation et de l’Infrastructure as Code, comme Terraform, mais il faut offrir suffisamment de visibilité et de détails pour comprendre les pannes et modifier le comportement lorsque cela est nécessaire. Liste conclut en insistant sur la construction au-dessus de l’open source et des standards ouverts, afin que l’équipe de la plateforme se concentre sur l’intégration et la valeur ajoutée plutôt que de recréer chaque couche à partir de zéro.
Pourquoi ces principes sont-ils importants ?
La valeur fondamentale de la proposition de Liste est qu’elle fait passer la construction de plateformes du statut de projet visant à lancer un ensemble d’outils à celui d’un engagement opérationnel à long terme. Une fois adoptée, la plateforme affecte de nombreuses équipes ; sa capacité à être mise à jour, la clarté des responsabilités et la gestion des retraits deviennent donc plus importantes que l’ajout rapide d’une nouvelle fonctionnalité. Ces principes restent des recommandations issues de l’expérience pratique, et non une norme unifiée garantissant le succès ; le niveau de disponibilité, l’étendue de l’automatisation et les choix d’abstraction restent liés à la nature du système et aux besoins de ses utilisateurs.