L’émergence des plateformes
Quel est le point commun entre Deezer, EasyBourse, Spartoo, Photoweb ou Molotov ? Tous ces services (ou d’autres équivalents) font partie de notre vie quotidienne, mais nous ne nous demandons pas toujours comment ils fonctionnent. Chacune de ces applications repose sur une plateforme.
Une plateforme regroupe l’ensemble des ressources nécessaires au fonctionnement d’une application, notamment les ressources d’infrastructures (serveurs, stockage, réseau), les ressources système (système d’exploitation, langages et bibliothèques applicatives) et les ressources utiles à la supervision et à l’observabilité.
Pour mettre en œuvre ces plateformes, les équipes techniques des entreprises s’appuient sur les méthodes agiles et les outils DevOps. Ces outils permettent d’automatiser et d’industrialiser les chaînes de développement et de déploiement.
L’arrivée des fournisseurs de cloud a accéléré et simplifié la gestion des plateformes grâce à la disponibilité de services managés, ce qui permet aux équipes de se concentrer sur d’autres tâches que la gestion des couches basses.
Il y a quelques années, il fallait souvent attendre plusieurs mois entre chaque livraison de logiciels. Les logiciels étaient développés en mode “Projet”, d’un côté le code, de l’autre la mise en place d’une infrastructure complexe comprenant des ressources de calculs, du stockage et la partie réseau.
Aujourd’hui, grâce au DevOps, aux méthodes agiles et au cloud, les développeurs peuvent livrer plusieurs fois par mois, voire même plusieurs fois par jour dans certaines organisations. Dans la suite de l’article nous allons voir comment cela est possible.
Rapidité vs exactitude
La rapidité des déploiements est cruciale pour les produits à fort impact utilisateur tels que les applications SaaS, les plateformes de streaming vidéo ou musical et les plateformes mobiles. Les livraisons fréquentes permettent d’obtenir des retours immédiats sur l’utilisation des nouvelles fonctionnalités ou leur impact sur les performances globales, ainsi que de mettre à jour régulièrement la sécurité des applications.
Livrer vite et correctement lorsque les équipes techniques sont de petites tailles est réalisable. Maintenir la même rapidité de déploiement et de gestion des plateformes devient plus complexe lorsque les effectifs des entreprises augmentent :
Comment faire en sorte de garder la même célérité dans les déploiements et la gestion des plateformes lorsqu’il y a plusieurs équipes de développement ?
Ajouter plus de ressources humaines ne conduit pas nécessairement à une augmentation de la productivité moyenne. En effet, cela entraîne souvent une augmentation de la hiérarchie, une complexité des échanges, des dépendances entre les équipes et la mise en place de processus.
Le concept du Platform Engineering que de nombreuses “Scale-up” mettent en place va avec l’objectif de rendre la consommation des plateformes nécessaires aux applications beaucoup plus simple et en toute autonomie par les développeurs.
C’est là qu’intervient le concept du Platform Engineering, largement adopté par de nombreuses scale-up. Son objectif est de simplifier la consommation des plateformes nécessaires aux applications et de donner aux développeurs plus d’autonomie.
Le Platform Engineering permet de fluidifier les processus d’architecture, de design, de déploiement et de maintenance des plateformes au sein de l’écosystème de l’entreprise.
Les limites du DevOps
Dans un monde où les principes DevOps sont de plus en plus adoptés, il devient essentiel de faire face aux limites et aux défis associés à cette approche. L’utilisation croissante d’une multitude d’outils rend souvent difficile le choix de l’outil le plus adapté aux besoins spécifiques de l’organisation. L’intégration de ces nombreux outils nécessite de les lier via du code, des scripts ou au travers d’intégrations via des API. La tâche des équipes « Ops » est de maintenir ce ciment fonctionnel pour servir au mieux l’organisation.
Figure : travail des Ops aujourd’hui, peu souvent visible
Pour permettre aux équipes de développements de faire leur part du travail sur la partie infrastructure il est donc nécessaire de revoir les interactions entre les “Dev” et les “Ops”.
La clé réside dans la discipline de n’avoir que ce qui est strictement nécessaire au besoin de l’organisation. Il est crucial de ne proposer que ce que les utilisateurs, en l’occurrence les développeurs, attendent, sans tomber dans le piège de l’utilisation de nouveaux outils à la mode qui n’apportent aucune valeur réelle ou qui s’éloignent trop des besoins concrets.
Platform as a Product
Le concept de Platform Engineering repose sur l’approche produit, qui vise à proposer des outils et des plateformes offrant une valeur ajoutée aux utilisateurs (ici les développeurs) grâce à des boucles de rétroaction continues. Cette approche met l’accent sur la résolution des problèmes communs rencontrés par les développeurs, en se concentrant sur l’expérience développeur (DX) de manière similaire à l’expérience utilisateur (UX). Elle évite de se laisser distraire par l’arrivée de nouveaux outils qui suscitent l’attention mais n’apportent rien de concret. De plus, elle permet de mesurer l’efficacité et l’impact des plateformes mises à disposition des utilisateurs.
Pour concevoir et fournir facilement des plateformes prêtes à l’emploi aux développeurs, les Platform Engineers s’appuient sur un outil appelé Internal Developer Platform (IDP), qui permet aux développeurs de choisir parmi un catalogue de plateformes pré-définies. Les Platform Engineers jouent le rôle de Product Managers ou de Product Owners de leur produit et travaillent avec les développeurs pour faire en sorte que l’IDP correspondent à leurs besoins.
Ce mode de fonctionnement permet aux différents profils d’acquérir davantage d’autonomie et de liberté. Les développeurs peuvent consommer librement des ressources, tandis que les équipes opérationnelles restent sereines car les règles d’utilisation et de sécurité sont pré-définies et respectées via l’IDP. Les équipes « Ops » disposent de plus de temps pour aider et former les développeurs aux nouvelles fonctionnalités, et la conception de nouveaux produits au sein de l’entreprise peut être réalisée de manière plus sereine. L’IDP devient le centre des échanges entre Tech, et c’est un vrai produit qui vit et grandit avec le service Technique.
Quand s’intéresser au Platform Engineering ?
Il est essentiel de se poser la question de l’adoption du Platform Engineering lorsque l’organisation existante ne satisfait pas pleinement les différents acteurs de l’entreprise.
Certains signes indiquant ces problèmes peuvent inclure :
- Des frictions et des frustrations au sein des équipes techniques;
- Une latence dans les développements, avec des difficultés à respecter les engagements en termes de délais;
- L’accumulation d’une dette technique;
- Une baisse ou une stagnation de la productivité malgré l’augmentation des ressources;
- Tout signe révélant une faiblesse de l’organisation.
La mise en place d’indicateurs de performance et/ou de frustration au sein des différentes équipes constitue un moyen efficace de détecter les tensions et les problèmes d’organisation.
Ces difficultés d’organisation deviennent généralement visibles lorsque les équipes comptent entre 20 et 30 développeurs, bien que ce chiffre puisse varier en fonction de chaque équipe. Il convient de noter qu’un accompagnement adéquat des équipes est essentiel pour une adoption réussie de ce nouveau concept, surtout si les habitudes de travail sont davantage orientées vers une approche « projet » plutôt que « produit ».
Produit vs Projet
L’approche traditionnelle en mode « projet » repose sur une liste de tâches avec une estimation de charge et une échéance. Cette approche fonctionne, mais elle limite considérablement l’agilité et n’est pas la plus flexible. Les tensions et les frustrations rencontrées par les équipes sont souvent liées à la problématique des échéances.
À mesure que la date limite approche, les équipes se retrouvent souvent à devoir choisir entre :
- Livrer une fonctionnalité qui n’est pas totalement achevée, ce qui engendre de la frustration chez les développeurs et les utilisateurs.
- Livrer en retard, ce qui provoque la frustration du secteur commercial, de la direction et des clients.
A contrario, l’approche produit se concentre sur la résolution des problèmes des utilisateurs. La notion d’impact qu’un problème a sur le quotidien de l’utilisateur est donc plus importante que la date précise de livraison de la solution. L’approche produit planifie les développements en fonction de la stratégie de l’entreprise afin de maximiser l’impact sur l’utilisateur.
L’objectif est d’obtenir des résultats rapides, concrets et surtout de susciter une nouvelle utilisation du produit par l’utilisateur.
Si une fonctionnalité ne correspond pas à la stratégie de l’entreprise et/ou n’a pas un impact significatif sur la valeur offerte, elle ne sera pas priorisée. Bien sûr, il est important d’avoir une fourchette de temps pour la disponibilité d’une fonctionnalité, mais ne pas être contraint par des échéances strictes permet de réduire le stress au sein des équipes.
Afin de permettre la mise en œuvre du Platform Engineering au sein des organisations, il est crucial de démontrer l’intérêt de l’approche produit aux équipes chargées de l’infrastructure, ainsi qu’aux différentes parties prenantes de l’entreprise.
Quelques avantages de l’approche produit :
- Agilité améliorée : les équipes peuvent réagir rapidement aux évolutions du marché ou aux besoins des utilisateurs.
- Amélioration de la qualité : les fonctionnalités sont plus susceptibles d’être terminées et testées avant leur publication.
- Réduction du stress : les équipes ne sont pas sous pression pour respecter des délais irréalistes
- Satisfaction des utilisateurs : les utilisateurs sont susceptibles d’être satisfaits des produits livrés à temps et qui répondent à leurs besoins.
Cas d’usage
Pour déterminer si le Platform Engineering est utile dans votre cas, posez-vous les questions suivantes :
- Est-il possible de cataloguer les plateformes utilisées dans mon organisation ?
- Les phases de déploiement sont-elles fréquentes, voire continues, mais limitées par la disponibilité des équipes opérationnelles ?
- Mes applications sont-elles conçues pour le cloud (Cloud Native) avec une architecture microservices (conteneurisée) et des technologies récentes, ce qui facilite leur catalogage ?
Si vous ne répondez pas « oui » à au moins l’une de ces trois questions, le Platform Engineering et l’approche produit ne conviennent probablement pas à votre organisation, ou bien l’effort requis pour leur mise en place serait trop important.
Outils pour mettre en place un IDP
Comme c’est le cas pour tout ce qui concerne l’écosystème tech, il n’existe pas d’outils miracle répondant à tous les besoins. Chaque organisation devra donc concevoir sa propre méthode pour proposer un Internal Developer Platform (IDP) adapté à ses besoins.
L’un des outils les plus connus pour la création d’un IDP est Backstage.io. Cet outil, développé par Spotify et disponible sur GitHub, propose une interface permettant d’accéder à un catalogue de services définis par les équipes opérationnelles. L‘avantage de Backstage réside dans sa grande variété de plugins, ce qui facilite son intégration avec les outils déjà utilisés par les entreprises technologiques.
Pour les applications microservices utilisant Kubernetes, d’autres outils sont adaptés, tels que Capsule qui simplifie la création d’IDP en segmentant les ressources Kubernetes par « tenant », ou Qovery qui facilite la mise à disposition d’environnements de test (« preview environment ») à partir des environnements de production, tout en garantissant la sécurité. L’expérience développeur est ainsi grandement améliorée, avec des tests en conditions réelles sans perturber la production.
Intégrer ces outils dans son propre écosystème n’est pas toujours simple. Nos experts en gestion de plateforme peuvent vous accompagner si vous ne savez pas comment vous y prendre et pourront vous orienter dans votre réflexion 👉 contactez-nous.
Conclusion
L’émergence des plateformes SaaS a révolutionné notre vie quotidienne, mais maintenir un rythme de développement soutenu et efficace face à une croissance des effectifs est un défi.
Le Platform Engineering, avec son approche produit et ses outils comme l’Internal Developer Platform (IDP), simplifie la consommation des infrastructures utiles au fonctionnement des plateformes, favorise la collaboration entre les équipes et améliore la productivité. Cependant, cette transition nécessite une adoption progressive et des architectures modernes pour en tirer pleinement parti. En rééquilibrant les responsabilités, le Platform Engineering stimule l’innovation et la croissance de l’entreprise tout en améliorant la satisfaction des équipes techniques.
A retenir
Le platform engineering :
- A un intérêt dès lors qu’il y a contingences sur le delivery (effet entonnoir) : les équipes de devs attentent l’accès aux ressources pour tester / livrer.
- Discipliner l’utilisation des outils Devops pour améliorer l’expérience développeur (DX).
- S’appuie sur l’approche Produit pour proposer des Plateformes as a Product au travers d’Internal Developer Platforms
- Applicable sur des plateformes standardisables, notamment les plateformes Cloud Natives.