“DevOps est mort, vive le Platform Engineering” disent certains articles. Pourtant, passer d’une culture DevOps à cette “nouvelle” pratique n’est pas facile. Mais de quoi parle-t-on exactement ? Comment éviter les écueils des implémentations “de la vraie vie” ? Découvrez ces leçons que tout le monde devrait connaître avant de se lancer.
Qu’est-ce que le Platform Engineering ?
Le Platform Engineering est l’art de construire et de maintenir des infrastructures, des services et des outils qui permettent l’autonomie des équipes pour le dev et le run des briques logicielles quelles qu’elles soient.
L’objectif est de rendre plus simple, rapide et sûre la livraison de fonctionnalités aux utilisateurs.
L’offre de self-service qui en découle donne naissance à une plateforme, d’où le titre de Platform Engineering.
#1 DevOps est un prérequis au Platform Engineering
La construction d’une plateforme embrasse les principes portés par une culture DevOps. Elle peut être vue comme son aboutissement naturel. L’offre de services doit être construite en visant l’amélioration de la Developer Experience. N’oubliez jamais qu’elle doit servir principalement les équipes de développement.
La collaboration et les canons du DevOps sont des prérequis nécessaires à la réalisation d’une plateforme utile et efficace. Dit autrement, ne vous lancez pas sur cette route sans avoir un minimum de collaboration, de culture de l’automatisation et de recherche partagée d’amélioration continue.
L’aspect Self-Service est très important. La plateforme doit-être activable, actionnable et pilotable par chacune des équipes en autonomie complète. Dépendre d’un SRE ou d’un ingénieur externe pour l’utilisation de la plateforme est un non-sens. L’équipe cliente doit-être autonome.
#2 La plateforme n’est pas une somme d’outils
Le but est de construire un produit pour les ingénieurs et data scientists principalement. Il doit être adapté au contexte humain et technologique de l’entreprise.
Comme n’importe quel produit, il doit bénéficier des meilleures pratiques en la matière.
Les rôles de product manager et de product owner sont nécessaires à la cohérence de l’ensemble.
Il s’agit donc de s’appuyer sur les principes du product management. Par exemple, posez-vous les bonnes questions : Pourquoi fait-on ce produit ? Comment allons-nous le faire adopter ? Qui sont nos utilisateurs ?
Les méthodes produit mettent l’accent sur la recherche des besoins utilisateurs. Elles visent aussi à intégrer ces derniers dans la construction de la roadmap. Attention, un produit ne se construit pas en best-effort.
Cherchez à maintenir et à développer le lien avec les utilisateurs, tout au long de la vie du produit platform. Pensez, par exemple, à communiquer sur les évolutions, fournir des changelogs, rédiger et enrichir la documentation. Bien que cela puisse paraître contre-intuitif, il est important de chercher à favoriser son adoption. On préfère avoir des utilisateurs qui ont soif d’utiliser le produit plutôt que de l’imposer. Le marketing est une bonne solution pour adresser ce besoin.
Tous ces travaux vous permettront de réaliser un produit qui rencontre le succès ; sauf si le service rendu n’est pas d’une qualité irréprochable. Un service ou une fonctionnalité défaillante est synonyme d’utilisateurs perdus.
Pour en finir avec cette vision produit, la plateforme est par nature assez tentaculaire. Dans l’idéal, chacun de ses éléments doit être géré par un owner très clair, connu de tous. Cette personne est responsable de son service et le mène en pleine conscience. Il encourage une évolution saine du service et permet une bien meilleure gestion des dépendances.
#3 Le Platform Engineering impose de se réinventer
Pour commencer la transformation, prenez le temps d’une réflexion libre. Imaginez que, demain, les équipes dev et data doivent pouvoir se passer dans leur quotidien d’Ops ou de SRE. Demandez-leur : “De quoi avez-vous besoin ?”
La technique des 5 pourquoi est particulièrement utile pour découvrir les besoins profonds. Essayez de ne pas vous contenter des remontées de surface.
Pour éviter le poids de l’histoire et construire le futur, il faut :
- Limiter le périmètre de la plateforme.
- Construire peu de services, mais les faire bien.
- Ne pas intégrer le legacy, mais l’honorer.
- Accepter les usages hors de la plateforme.
Un biais dans la technique est, bien souvent, de mettre de côté l’organisation. Pourtant l’adoption du Platform Engineering l’impacte forcément. Si ce n’est pas le cas, vous êtes probablement sur une mauvaise route. N’hésitez pas trop à rebattre les cartes des rôles et des responsabilités.
#4 Le périmètre de la plateforme doit-être clairement défini
La plateforme embrasse un périmètre technique couvrant l’ensemble des capacités nécessaires au delivery et au run.
Elle doit offrir en self-service des capacités :
- d’opérations (CI/CD, Middleware, Run, …)
- de sécurité (Scans, Patchs, IAM, Hardening, Chiffrement, Secrets management, …)
- de scalabilité et de résilience (Infrastructure HA, Backup, Recovery, Élasticité)
- de data (services de traitement des données : ingestion, transformation et consommation)
- d'observabilité (Monitoring, Alerting, Tracing, Performance, Debug, Log management, gestion des coûts, …)
L’intégration et la durabilité en sont des facteurs clé. Les outils de la plateforme ont besoin d’être facilement intégrables et interopérables. Mais il faut aussi construire une solution durable d’un point de vue environnemental, tout en étant évolutive et maintenable. La plateforme doit durer dans le temps. Elle gagnera donc à pouvoir évoluer simplement sans avoir à passer par une refonte complète.
Attention, on parle ici de périmètre et non d’équipe. La plateforme est potentiellement construite par plusieurs équipes en fonction de leurs compétences.
#5 Adoptez le vrai “You build it, you run it”, pas le faux
Si vous croyez que cette phrase signifie que le développeur doit-être un super héros, qu’il doit à la fois coder et opérer, par pitié, réfléchissez-y à nouveau. Les super-héros à la fois dev et ops sont rares, ils émergent parfois naturellement et c’est très bien. Vouloir former ce genre super profil finit toujours mal comme dans les films.
Le Platform Engineering cherche à fluidifier le delivery. Il s’agit de supprimer les goulets d’étranglement, en apportant comme solution l’autonomie des équipes. Les équipes devraient gérer l’ensemble de leur cycle de création et en porter la responsabilité.
Le développeur n'est pas ou plus seulement producteur de code source. Il travaille dans une équipe propriétaire d’un domaine clair. Sur ce domaine fonctionnel ou technique, l’équipe est responsable de nombreux chantiers, comme :
- L’Architecture
- La CI/CD
- La QA
- La Sécurité
- La Data
- L’Observabilité
- Le Run
Attention, être responsable ne signifie pas tout faire seul. La responsabilité implique l’équipe. Elle doit s’assurer que l’ensemble de ces travaux sont adressés. Certaines compétences peuvent être internes à l’équipe, d’autres, sollicitées à la demande ou encore disponibles en self-service.
#6 Sans observabilité, la plateforme n’est rien
Vous ne pourrez améliorer que ce qui est mesuré. Le produit plateforme doit-être intégralement observable. En la matière, il vaut mieux avoir trop de métriques que pas assez.
Il est essentiel de rendre lisible et compréhensible :
- L’état de santé des applications
- La conformité
- Le monitoring, l’alerting, les logs et les performances
- Les tendances de fond
- Le niveau de risque cyber
- Les coûts d’opérations
Mesurez l’augmentation de valeur qu’apporte la plateforme. L’exercice est compliqué, mais essentiel.
Chaque organisation aura sa propre lecture de cette amélioration. Prenez du temps pour résoudre ce problème. L’apport de la plateforme doit être lisible pour les utilisateurs, le métier et les décideurs.
Vous garderez ainsi l'alignement et l’engagement de tous les acteurs. Le fun et les technologies sexys peuvent parfaitement être des valeurs ajoutées. En mesurant, vous construirez de réels succès clairs et factuels.
#7 La solution magique n’existe pas
Comme toujours en IT, ce qui fonctionne dans une entreprise ne fonctionnera pas dans une autre.
Chaque organisation est unique et aura sa propre solution. Évitez donc l’écueil du copier/coller, prenez du recul dans votre veille et multipliez vos sources. Soyez particulièrement attentifs à ne pas verser dans l’auto-centrage et dans l’entre-soi.
La perfection n’est pas de ce monde, restez pragmatique dans vos choix. Acceptez de faire du quick and dirty à l’occasion. Ces raccourcis utiles doivent être parfaitement documentés et maîtrisés. Le refactoring et l’évolution du produit pourront les adresser par la suite.
Définissez une stratégie make or buy claire, pour guider la construction de votre plateforme. Et pour finir, gardez en tête de rester simple, Keep It Simple Stupid.
Cet article est inspiré de la conférence Ops & Platform Engineering donnée par A Jacoutot à visionner sur notre chaine YouTube.
Cloud Native
Cloud Native
