Platform Engineering : juste une énième brique dans le mur (de confusion) ?

“Le Platform Engineering est la discipline de conception d’outils en self-service minimisant la charge cognitive des développeurs et permettant un flux de livraison de software rapide.”

— State of DevOps 2023

Au cours de votre veille technologique, vous êtes sûrement tombés sur des articles au titre bien “mesurés” comme ceux-ci :

Aussi, vous avez peut-être vu fleurir de nouveaux postes intitulés Platform Engineer aux descriptions plus ou moins nébuleuses :

Nous pouvons ajouter à cela les entreprises de conseil de référence telles que le Gartner qui place le Platform Engineering comme une des tendances des années à venir :

Gartner predicts that by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery.

Source: gartner.com

Nous avons là tous les ingrédients pour créer un cocktail savoureux de hype technologique.

Sommes-nous face à un énième buzzword ou bien y a-t-il une réelle raison de s’intéresser à ce sujet ? Aussi et avant tout, à quels problèmes le Platform Engineering ambitionne-t-il d’apporter des solutions ?

Au regard des investissements techniques et organisationnels nécessaires à la mise en place d’une plate-forme, il est nécessaire de ne pas succomber trop rapidement à l’engouement entourant le sujet. Cet article souhaite offrir des clés de compréhension afin de démystifier cette nouvelle discipline et vous aider à l’aborder de manière éclairée.

Le Platform Engineering se veut être une évolution au DevOps, ce qui sous-entend qu’il y a quelque chose de pourri au royaume du Delivery.

Les dérives du DevOps

Une trop grande responsabilité donnée aux développeurs

Les compétences demandées aux développeurs aujourd’hui ne se limitent plus au monde du développement (qui au passage se complexifie tout autant).

Il leur est ainsi demandé de plus en plus prendre à leur compte des sujets de déploiement (comme la mise en place de la pipeline de delivery avec les outils de CI/CD, configuration des machines en Ansible, conteneurisation des projets sous docker, configuration des pods Kubernetes, etc.), sujets devenus plus accessibles (mais pas plus facile) grâce à l’avènement de l’infra as code (IaC).

Lien reddit

Dans ce contexte, on note deux comportements chez les développeurs face à une tâche Ops :

• soit, ils prennent la tâche à leur compte pour un résultat souvent mitigé (ce ne sont pas des experts et ce n’est pas le cœur de leur mission) et les Ops de l’équipe doivent repasser derrière leur travail.

• soit, ils ne la font pas (par manque de temps ou d’intérêt) et là encore, la responsabilité retombe chez les experts Ops de l’équipe.

De plus, peu de développeurs pensent que l’infrastructure est une partie de la solution et n’en tire pas de réels bénéfices. Ils le voient plus comme un mal nécessaire.

OPS : entre commodité et complexité

“You build it you run it” est une idée alléchante sur le papier, mais mise en pratique, elle se confronte à des obstacles :

• Au moment de l’apparition du DevOps, l’environnement était relativement “simple” : quelques machines virtuelles, éventuellement des buckets S3 et la gestion de quelques pipelines, tout ceci restait relativement gérable. (Cette vision est elle-même intentionnellement simpliste : gérer les pipelines sur gitlab CI est aujourd’hui plus simple qu’il n’a jamais été sur Jenkins et c’est quand même agréable de ne pas avoir à se soucier des DNS ou firewall et laisser la main à Vercel 😇) Ce qui a porté un coup au modèle, c’est la complexité croissante des systèmes, le foisonnement de l’outillage, ainsi que la charge opérationnelle tout aussi grandissante pour les faire évoluer et maintenir.

• Pour beaucoup d’organisations, cela s’est traduit par la création de garde-fous, validant chaque étape de la boucle DevOps. (https://cloudify.co/blog/you-build-it-you-run-it/)

• Être compétent à la fois sur les sujets DEV et OPS n’est pas à la portée (ni de l'envie) de tous, les deux domaines évoluant constamment il est difficile de maîtriser l’ensemble de la chaîne de production de bout en bout. Le mot de "silo" est péjoratif dans un monde Agile et une des raisons principales de la création du DevOps, mais factuellement le besoin d’expertise amène à leur réapparition.

Nous recréons les silos de compétences que le DevOps était censé casser

“Boring technology”

Le travail du quotidien demandé aux Ops dans les équipes projets n’est pas des plus challengeant : mise en place de pipeline CI/CD, de provisioning des machines et potentiellement un peu de monitoring, et ce autant de fois qu’il y a de projets. Pour des experts du domaine, ces tâches sont de l’ordre de la commodité et disons-le, une corvée.

L’organisation a de moins en moins de maîtrise de ce qu’il se passe

La connaissance de l’organisation de l’activité de ses équipes est de plus en plus morcelée, constat renforcé depuis la popularisation des architectures en micro-services, amenant à un manque de contrôle et de rationalisation (multiplication des services pour lesquels les choix techniques sont au bon vouloir des équipes évoluant en autonomie et qui perdent le lien avec l’écosystème global) dans le budget, les pratiques et les technologies utilisées au sein d’une organisation.

Le Platform Engineering est une réponse possible à ces différentes problématiques.

Elle passe avant tout par une réorganisation des équipes et la création d’une équipe dédiée au développement et la gestion d’une plate-forme ayant pour objectif de proposer aux développeurs et autres parties prenantes un point d’accès global à l’ensemble des projets d’une organisation. Sur ces projets sont appliquées toutes les règles et bonnes pratiques validées par l’organisation.

Pour schématiser, il s’agit de permettre aux développeurs en quelques clics sur une interface dédiée de pouvoir rapidement initialiser des projets en ayant l’assurance de respecter les normes et les technologies adéquates et de ne pas avoir à se soucier de la mise en place du workflow de delivery. Ainsi, par cette économie de temps, d’énergie et de charge cognitive, il peut mieux se focaliser sur son objectif principal : développer.

Qu’est-ce qu’il y a dans les tuyaux ?

Comme évoqué précédemment, l’enjeu se situe avant tout au niveau de l’organisation des équipes, en prenant le parti de regrouper des experts sous une même unité. Cette décision semble aller à contre-courant de l’idée de casser le fameux “wall of confusion” entre les DEV et les OPS non ?

Penser cela serait justement se tromper sur la nature de la plate-forme. Il ne s’agit pas ici d’un regroupement par compétences, mais plutôt un conglomérat d’experts multidisciplinaires :

Certes, l’équipe a ainsi besoin de membres qui comprennent l’intégration, l’automatisation, l’intégration et développement continu : des OPS, mais, au-delà de cette population, elle engage différents types d’expertises :

• Product Owner, comme développer la plate-forme tel un produit : backlog, priorisation, cycle de développement

• UI/UX pour offrir la meilleure expérience aux développeurs

• Devs pour développer l’outillage nécessaire à l’interfaçage avec les éléments opérationnels et d’infrastructure

• Des experts sécurité, SRE, etc. selon les enjeux auxquels l’organisation souhaite répondre

La plate-forme ou Internal Developer Platform (IDP) génère un changement culturel profond dans l’organisation : le but de cette équipe est de créer ensemble un produit à destination de ses clients : les développeurs internes de l’organisation (à noter que “développeur” est un raccourci intentionnel : par la mouvance gitops, les Ops tendent à utiliser de plus en plus leur infra “comme des devs” et peuvent aussi bénéficier notamment des templates Infra as Code mise à disposition sur la plate-forme). Ainsi, les développeurs se retrouvent au cœur des priorités de l’activité de l’organisation, les libérant des tâches annexes à leur savoir-faire et leur permettant de se focaliser dans la réalisation d’outils répondant aux enjeux business de l’organisation.

IDP : Un produit self-service

Nous pourrions être amenés à penser que l’équipe plate-forme devient la clé de voûte des choix techniques de l’organisation, c’est en partie vraie (ce sont des experts et sont garants de la cohérence globale du produit), mais nous ne sommes pas non plus dans un mode de fonctionnement “ante-DevOps”, avec des choix unilatéraux.

La force des IDP réside dans leur nature “self-service” :

• La plate-forme met à disposition un panel d’outils dans lequel les développeurs peuvent piocher pour composer leur solution sur-mesure

• Si l’outil dont ils ont besoin n’existe pas sur la plate-forme, en tant que clients, les développeurs peuvent soumettre leur besoin à l’équipe

Gains attendus

La mise en place d’une plateforme interne pour les développeurs (IDP) offre de nombreux avantages aux équipes-projets et aux organisations.

Alignement dans les pratiques

L’IDP fournit un ensemble standardisé d’outils et de services pour toutes les équipes, réduisant ainsi le risque d’incohérences et d’erreurs. Les pratiques de développement sont harmonisées, ce qui facilite la collaboration et la compréhension mutuelle entre les équipes.

Facilitation de l’on-boarding

L’IDP automatise la configuration initiale et la gestion des environnements de développement. Les nouveaux développeurs peuvent rapidement devenir productifs en utilisant les outils appropriés, améliorant ainsi leur expérience et réduisant le temps nécessaire pour créer de la valeur.

Switch rapide entre projets internes

Parce que l’organisation fournit une plate-forme cohérente et partagée, les développeurs peuvent facilement passer d’un projet à l’autre, favorisant la flexibilité et la mobilité au sein de l’organisation.

Focalisation des OPS sur des tâches plus challengeantes

En automatisant les tâches courantes, l’IDP permet aux opérations (OPS) de se concentrer sur des problèmes plus complexes et stratégiques. Les OPS peuvent ainsi contribuer davantage à l’innovation et à l’amélioration continue.

Centralisation de la connaissance et meilleure vision des coûts

L’IDP rassemble les connaissances et les bonnes pratiques au sein d’une plateforme unique. L’organisation peut mieux évaluer les coûts liés au développement, à la maintenance et à l’évolution de la stack technique.

Responsabilisation de l’équipe pour l’évolution de la stack technique

Enfin, la plate-forme est un outil dédié aux développeurs de l’organisation. Comme tout produit, il est amené à évoluer selon les besoins de ses utilisateurs. Les développeurs ont donc un rôle actif dans la sélection et l’évolution des technologies utilisées. Par le mode de fonctionnement en self-service, iIls sont invités et responsabilisés de manière induite dans la maintenance de la stack technique à jour et à garantir son évolution.

C’est là un enjeu crucial conditionnant le succès d’une plate-forme dans une organisation

Points d'attention

La mise en place d’une plateforme interne pour les développeurs (IDP) est un processus possédant des atouts intéressants, mais il nécessite une attention particulière pour garantir son succès.

Savoir communiquer

L’importance de la communication est cruciale lors de la mise en place d’une plateforme interne pour les développeurs (IDP) au sein d’une organisation. Si l’IDP n’est pas activement promue et comprise, elle risque de passer inaperçue et de ne pas être pleinement utilisée par les équipes. Il est essentiel d’impliquer les parties prenantes, de recueillir leurs retours et d’établir des relais internes pour résoudre rapidement les problèmes. Leur expliquer l’approche plate-forme est essentiel, afin qu’elles comprennent les avantages et les objectifs de la plateforme, favorisant ainsi leur soutien et leur engagement. En impliquant les utilisateurs dès le début et en tenant compte de leurs besoins, l’adoption réussie de l’IDP dépend souvent de leur satisfaction.

Ne pas voir trop gros trop vite

Commencer par des fonctionnalités essentielles et évoluer progressivement permet d’éviter de surcharger l’IDP dès le départ. Un projet pilote avec un petit groupe d’utilisateurs avant un déploiement complet permet d’identifier les problèmes et d’ajuster en conséquence et l’utilisation de technologies communes et éprouvées dans l’organisation facilitera aussi l’adoption et la maintenance de la plate-forme

Importance de la documentation et de l’approche self-service

La documentation des services de la plate-forme est un pilier fondamental. Elle permet aux utilisateurs de comprendre son fonctionnement, ses fonctionnalités et ses bonnes pratiques. Proposer une approche self-service via une API ou une interface utilisateur conviviale permet aux développeurs d’explorer rapidement les services disponibles, favorisant ainsi leur autonomie et leur productivité.

Platform as Product

Enfin, il est primordial de faire et d’assumer des choix, de prioriser les fonctionnalités et de justifier ces décisions. Utiliser les bons outils pour la gestion et la surveillance de l’IDP est également crucial, tout comme la documentation exhaustive et l’approche self-service pour les utilisateurs.

Lors de la mise en place de l’IDP, il est essentiel de prendre des décisions éclairées concernant les fonctionnalités à inclure et les priorités à définir. Ces choix doivent être justifiés et alignés sur les objectifs de l’organisation. Être prêt à expliquer ces décisions est crucial pour obtenir le soutien des parties prenantes.

Alors on en pense quoi finalement ?

Vous l’avez sûrement remarqué, nous avons traité d’un sujet qui peut sembler de prime abord technique (pas de Backstage, ni templates, ni platform orchestrator désolé 🙃), en parlant principalement d’organisation et de méthodologie Produit. Tout simplement parce que nous sommes convaincus que le succès de toute innovation dans un système réside avant tout dans la compréhension collective de son utilité et dans la mise en place d’une stratégie de groupe afin de favoriser son adoption.

Buzzword ou réelle évolution ? La frontière est finalement fine et dépend surtout de l’existence du besoin, des gains attendus et de l’effort qu’on est prêt à faire (et payer aussi) pour en réussir l’adoption dans l’organisation.

Pour plus d’informations, contactez-nous !

Auteur : Michael Akbaraly (Linkedin)