Platform engineering : optimiser la productivité des développeurs

Ces dernières années, la transformation digitale des entreprises s'est accélérée entraînant une généralisation du cloud dans la plupart des entreprises. Cette évolution s’accompagne de nouveaux défis : sécurité, IA, standardisation, mais aussi gestion des talents. Selon Gartner, d’ici à 2026, 80 % des entreprises d’ingénierie logicielle mettront en place des équipes de plateforme en tant que fournisseurs internes de services, de composants et d’outils réutilisables pour la distribution d’applications. Quid de ce qui se cache réellement derrière le platform engineering ?

Les défis des entreprises

Le cloud a mis en exergue la  nécessité d'aligner le développement d'applications aux contraintes de déploiement pour aller chercher plus d'efficience opérationnelle et plus de performance applicative. Les Dev et les Ops doivent travailler de concert tout au long du cycle de vie de l’application. C’est le grand principe du Devops.

Pour autant, l’adoption d’un cloud public encourage une autonomie très forte des équipes projets. En partant de cinq à dix Business Unit pre-cloud, on peut arriver à une bonne centaine de projets, chacun évoluant sur des environnements dev / staging / prod cloisonnés, soit au final 300 comptes ou groupes sur un clouder.

Autre difficulté : les plateformes Cloud public proposent une galaxie de services spécialisés, qui doivent être agrégés pour fournir une solution utilisable pour un projet ; calcul, Load balancing, serverless, DNS, Certificats, stockage, base de données, IAM, administration, observabilité, tracing… Le nombre de services que les équipes doivent configurer explose et en devient contre productif. Quelques initiatives sont lancées pour proposer des modules inter projets, mais dans les faits ils ne sont que peu utilisés, souvent par manque de diffusion “organique”.

Et côté sécurité, lorsqu’un projet doit passer une validation cyber-sécurité avant une mise en ligne, les voyants rouges s’allument : failles dans le code, gestion défaillante des mécanismes d’authentification, dépendances obsolètes, gestion de données personnelles hasardeuse… Il faut revoir sa copie. Et pendant ce temps le compteur défile : budget, ressources, planning s’envolent. 

Autre constat, certaines tâches paraissent insurmontables. L'authentification des APIs en interne ou encore le changement de configuration TLS est une véritable épreuve pour l’équipe cloud/devops.

Dans ce contexte, vouloir proposer une plateforme commune qui implémente les standards de l’entreprise prend du sens avec à la clé de belles promesses pour les équipes de développement mais plus globalement pour l’entreprise avec un delivery plus fluide et des « produits » à meilleure valeur ajoutée commerciale.

Le platform engineering à la rescousse

Et si la solution tenait au platform engineering ? C’est à dire : 

• offrir aux équipes une ou, des plateformes internes en libre-service
• dédier une équipe produit pour la développer et la maintenir 
• répondre aux besoins des utilisateurs en s’interfaçant avec les outils et les processus existants. 

Les équipes plateform n’ont alors qu’un seul objectif : délivrer un socle plate-forme utilisable par l’ensemble des développeurs pour moderniser les applications métiers.

 On parle d’une approche “Platform-as-a-Product”.

Les utilisateurs de la plateforme sont divers, à la fois clients mais aussi designers :

• Les développeurs représentent la plus grande partie des utilisateurs. La plateforme met à leur disposition des modèles pré-construits qui sont approuvés, maintenus et supportés. Ces “golden path” sont instanciés au travers d’un portail, d’une CLI ou d’API pour piloter les pipelines, la gestion d’environnements, la création de composants techniques (file de messages, stockage persistent disque/objets, caches, LB) ou encore la gestion de secrets,
  
  
• Le pôle sécurité va pouvoir élever le niveau de sécurité globale en intervenant de manière centralisée sur 
  • la validation des artefacts logiciels (scan de dépendances, analyse de code),
  • le run en lui même (exposition / sécurisation des services, scan des images, design),
  • les contrôles de conformité à différents niveaux
    
    
• Les opérations vont pouvoir intervenir dans le maintien des configurations des golden paths, en particulier sur la gestion du monitoring (logs, métriques, tracing, alarmes) mais aussi des procédures via des runbooks,
  
  
• Les architectes vont pouvoir intervenir dans la définition et l’évolution des golden paths. Ils vont aussi suivre les données de références: listing de projets, typologies d’environnements,  classification des données.
  
  
• Le pôle finops va définir la politique de tags liée aux coûts et aura accès aux données de consommation/coûts pour procéder aux optimisations, comme à une éventuelle re-facturation.
  
  
• Les équipes Data vont bénéficier de la plateforme pour gagner en autonomie par exemple : exécuter leurs notebook Jupyter, accéder facilement à la données et la valoriser.

Cette pratique permet d’optimiser l’expérience des développeurs et d’accélérer la création de valeur commerciale. Elle améliore l’expérience et  la productivité des développeurs et leur capacité à exécuter, gérer et développer des applications de manière indépendante, tout en garantissant fiabilité et sécurité. C’est  aussi un facteur de rétention des talents clés, un point hautement stratégique quand on sait combien il est complexe aujourd’hui de consolider les équipes face à la multiplication des projets.

Le temps de la mise en œuvre

Le  but est de construire un PaaS basé sur des technologies non propriétaires. Aujourd’hui, les implémentations sont principalement centrées autour de Kubernetes avec une intégration de projets OpenSource de l’éco-système CNCF auxquels s'ajoutent souvent des services Cloud. Il est indispensable de choisir les bonnes briques, de les intégrer entre elles, de les maintenir et proposer les golden paths qui permettront une “autonomie contrôlée”.

Voici  un panorama des technologies applicables :

https://platformengineering.org/platform-tooling

Platform engineering oui, mais jamais sans gouvernance

Qui dit plateforme dit souvent ressources partagées. Il est important de pouvoir rapprocher des ressources technologiques d’entités organisationnelles, à des fins d’optimisation, de sécurisation, voire de rationalisation.

L’une des solutions à ce type de problème est de mettre en place une politique de tags. Nous ne reviendrons pas sur l'intérêt des tags ; tout est dit dans cet article.

En revanche, nous constatons fréquemment que les politiques de tags sont rarement appliquées sur les ressources créées ou de manière inefficace (casse non respectée, valeurs multiples non tolérées, défaut de mise à jour…). 

Le taggage des ressources de facto, le contrôle de conformité a priori, associé à un contrôle en temps réel permettent aux équipes projet de constater et mesurer leur impact propre sur la plateforme et les coûts inhérents. Les pilotes disposent ainsi d'une vision centralisée pour définir et mettre en place une politique de gouvernance forte et efficace.

Conclusion

La construction d’une plateforme est un enjeu majeur qui, au-delà de structurer votre SI, va offrir à votre entreprise les moyens des ses ambitions ! Car au final, c’est bien de la valeur commerciale ou valeur d’usage dont il s’agit !

Récemment, WeScale a accompagné le ministère de l’Intérieur et des outre-mer dans son projet de platform engineering. Dans chaque projet, il est essentiel de prendre en considération les métriques en lien avec la valeur que doit apporter la plateforme mais aussi de porter une attention particulière  à l’approche produit, pour une parfaite adoption par les utilisateurs et au succès de la plateforme.

Pour aller plus loin sur les  pratiques pour adopter le platform engineering, indiquons le modèle de maturité platform engineering de la CNCF.