Les promesses du Platform engineering sont nombreuses et alléchantes : un socle plate-forme utilisable par l’ensemble des développeurs, une meilleure productivité, une rationalisation des outils et des processus de delivery plus fluides et des « produits » à meilleure valeur ajoutée commerciale. Mais comment mettre en place cette nouvelle plateforme sans perturber le run de l’entreprise et mettre en péril l’existant ?
Définition des pré-requis
La première des étapes tient à la formalisation de l’objectif. Puis rapidement vient la question de la rentabilité ! Si vous êtes dans une structure de taille conséquente (disons au moins 20 développeurs, dans 3 équipes projets), le jeu en vaut probablement la chandelle. Pour les entités de plus petite taille, les offres PaaS applicatives existantes comme https://www.heroku.com/ ou https://platform.sh/ proposent une alternative clé en main intéressante.
Gestion des identités
La mise en place d’une plateforme va passer par une gestion des rôles/permissions dans chacun des composants mis en œuvre, ainsi que par l’automatisation de la création de groupes. Il est fréquent de voir des clients au milieu du gué entre deux migrations de référentiels utilisateurs. Si c’est le cas, terminez votre migration pour avoir un seul système de gestion d’identités et groupes.
Un pied dans le Cloud Native
Si vous en êtes à déployer des applications monolithes sur des VMs, la marche est sans doute trop haute pour passer à une plateforme. Il est nécessaire que vous ayez déjà une expérience avec le socle Kubernetes on-premise ou managé par une plateforme cloud. Cela se traduit par l’existence de plusieurs applications conteneurisées et orchestrées en prod. Si un move to cloud est prévu dans les prochains mois, il est sans doute judicieux de profiter des capacités du fournisseur cloud pour construire la plateforme dessus et articuler finement les deux chantiers.
Une offre pour les bases de données
Corollaire du point précédent, vous devez être capable de provisionner en self-service des bases de données. Qu’elle soit adossée à un service managé fourni par un éditeur (par exemple mongo atlas), un cloud provider ou une infrastructure maintenue en interne, la finalité de l’offre DB est la même. Les équipes projets doivent pouvoir accéder à une solution de gestion de données résiliente, monitorée et éventuellement scalable.
La préparation du projet
La première étape consiste à préparer les référentiels de données.
On parle ici de la mise au propre des différents environnements, d’établir la liste des projets, de définir les domaines métiers, de valider la classification de données, d’anticiper les tags... De même, la vue sur les technologies utilisées en interne sera plus dans la définition des “golden path” proposés par la plateforme.
Dans la phase amont du projet, les indicateurs d’impact de la plateforme peuvent être aussi définis. Cette étape est cruciale puisque les investissements liés à la mise en œuvre de la plateforme seront conséquents. On parle d’une équipe d’environ 5 profils Devops expérimentés uniquement sur la partie réalisation. Outre la mise en œuvre, la plateforme devra être maintenue dans le temps ; environ 8 ans en cible. Et viendra le temps où il faudra rendre des comptes. Autant donc poser le cadre du ROI dès le départ avec des éléments mesurés sur l’apport rendu par les fonctionnalités de la plateforme : TTM, productivité des développeurs, nombre d’incidents, satisfaction (dev, ops, sécurité), indicateurs de conformité. Pour cela, les frameworks DORA | SPACE | ou les recommandations McKinsey fournissent une bonne base de départ.
Le lancement de la démarche produit
Considérer la plateforme comme produit est vital pour deux raisons :
- Il est impensable de livrer une plateforme complète à la première itération. Si le périmètre est trop important, vous aurez à faire des choix assumés de fonctionnalités.
- Une plateforme est avant tout technique. Or les équipes techniques/ops ont tendance à se faire plaisir avant de penser plus-value. On ne compte plus les projets “tech 4 tech” abandonnés au bout de quelques mois, faute de valeur délivrée.
Cela suppose d’identifier et prioriser les vrais besoins, de communiquer sur la roadmap, les releases et nouvelles fonctionnalités, de récolter les feedbacks utilisateurs. Comment remonter les besoins utilisateurs ? Faut-il faire des interviews ? Comment améliorer la documentation ?
Sur l’aspect réalisation, la mise en place de tests automatisés est un passage obligé. Là encore, les équipes techniques/ops ne font pas référence. Pour ces questions un accompagnement peut être nécessaire.
Enfin, la définition des “golden path” proposés par la plateforme doit coller aux attentes. Qui va trouver les implémentations, rationaliser les attentes des différents projets qui peuvent être très hétérogènes ? Pour cela, embarquez dans le projet plateforme une équipe de profils techniques reconnus (architectes, devops, développeurs senior) qui ont la légitimité de proposer des design qui ne seront pas remis en question. Si ce n’est pas le cas, communiquez sur ce nouveau rôle de Staff engineer.
Conclusion
Le platform engineering est le sujet du moment. Mais avant de se lancer dans la construction d’une plateforme, il faut en mesurer l’impact.
C'est un projet d’entreprise qui va structurer votre SI pour de nombreuses années. Pour ceux qui veulent aller plus loin sur les pratiques pour adopter le platform engineering, indiquons le modèle de maturité platform engineering de la CNCF.
Liens utiles
Pour aller plus loin
Actualités
Cloud Native