Sommaire
4ème tendance technologique pour 2024 d’après le Gartner, le platform engineering est le sujet à la mode dans les conférences techniques, Après vous avoir exposé les principaux écueils du plateform engineering dans un précédent article, nous vous proposons de revenir sur ses intérêts et de répondre à la question: par où commencer ?
Les raisons de mettre en place le Platform Engineering
Le platform engineering permet de proposer une solution qui simplifie le cycle de vie des différentes applications que vous construisez: de la création du projet aux déploiements sur différents environnements, en passant par le build, en respectant les standards, mais en laissant une certaine autonomie aux équipes.
Les utilisateurs de la plateforme sont divers. Il sont à la fois clients mais aussi designers:
- Les développeurs représentent la plus grande partie des utilisateurs. La plateforme doit mettre à 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 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 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.
Concrètement, le but est de construire votre 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. Le sujet est donc de choisir les bonnes briques, de les intégrer entre elles, de les maintenir et proposer les golden paths qui vont permettre une “autonomie contrôlée”.
Voici un panorama des technologies applicables:
https://platformengineering.org/platform-tooling
Les cas d'usage pour le Platform Engineering
Vous êtes un directeur informatique qui avez bataillé depuis dix années pour moderniser votre SI. Vous avez mené avec succès d’importants projets. Les plus visibles d’entre eux sont notamment le move to cloud de l’ensemble du SI, accompagné d’une transformation Devops. Après avoir sué sang et eau, vous pensiez avoir une infrastructure et des pratiques à l’état de l’art qui vous permettent de libérer la pleine puissance des équipes projet. Pourtant, les plaintes continuent, voire augmentent, que ce soit côté produit concernant les TTM ou encore côté finance avec des coûts qui s’envolent. Que se passe-t-il ?
La mise à l'échelle Devops pose problème
Les profils Devops sont rares. Ils combinent connaissances des principaux services clouds, maîtrise de solutions d’Infra as Code, capacité à challenger des choix techniques, automatisation des tâches de production, monitoring, application des recommandations de sécurité … La liste pourrait encore s’allonger. Demander à des développeurs de mettre en place de l’Infra as Code et de penser opérations ne fonctionne pas car les appétences et les priorités entre Dev et Devops ne sont pas les mêmes. L’adoption des principes Devops est un processus long puisque l’on parle de faire changer les pratiques. Elle se traduit par différents schémas d’organisation qui se suivent au sein d’une même entreprise (indiquons le synthétique devopstologies).
Quelle que soit votre maturité Devops, du “il me faut 50 Devops pour mes 50 équipes projets” au plus rassurant, “nous avons besoin de renforts Devops”, adapter le nombre de profils Devops aux besoins projets est un problème récurrent. Dans ce contexte, vouloir proposer une solution self-service aux équipes projet prend du sens. L’objectif avoué est de réduire la dépendance aux personnes clé en proposant, sur étagère, des modules qui respectent les bonnes pratiques et poussent à directement “bien faire”.
Vos équipes réinventent la roue
Il est très fréquent que l’adoption d’un cloud public se traduise par une autonomie très forte des équipes projets. Ainsi, 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 des autres, soit 300 comptes ou groupes sur votre clouder. Si votre équipe “Cloud” a bien travaillé, la gestion de tous ces comptes a nécessité de nombreuses automatisations qui gèrent plus ou moins l’entièreté des opérations de provisioning ; on parle d’”account factory”. Par ailleurs, après de longues discussions entre les équipes Innovation, Ops et sécurité, la politique d’autorisation de services cloud a évolué. Pour ne pas bloquer l’innovation, vous êtes passés d’une politique restrictive (whitelist) à une politique contrôlée (blacklist). Pour finir, les équipes projets choisissent leur infra, leur techno, leurs services cloud, et le besoin de cellule d’architecture transverse disparaît progressivement. Tout va bien.
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… avez-vous compté le nombre de services que vos équipes doivent configurer? Cette autonomie très forte des projets mènent à des pratiques Devops locales avec par exemple autant de types de pipelines CI/CD que de projets. Il en est de même des logs émis, des métriques, des alarmes ou encore de l’Infra as Code. 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”.
Lorsqu’un projet doit passer une validation cyber-sécurité avant une mise en ligne, les voyants rouges s’allument: des failles dans le code, une gestion défaillante des mécanismes d’authentification, des dépendances obsolètes, une gestion de données personnelles hasardeuse … il faut revoir la copie, vous avez perdu plusieurs semaines.
Lorsque vous souhaitez faire évoluer le socle technique à l'échelle de l’entreprise (par exemple: authentification des APIs en interne, changement de configuration TLS), c’est un travail de longue haleine ; une épreuve pour l’équipe cloud/devops qui doit faire prioriser ces sujets par les équipes projets, qui sont souvent orientées “feature” et qui ne disposent que de peu de temps pour traiter ces problématiques techniques.
Dans ce contexte, vouloir proposer une plateforme commune qui implémente les standards de l’entreprise prend du sens. Les écarts au standards doivent être justifiés, et peuvent facilement être audités, limitant les dérives et les chantiers pharaoniques de remise en conformité.
Vous souhaitez appliquer une gouvernance rigoureuse
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. Vous avez sans doute une politique de tags. Nous ne reviendrons pas sur l'intérêt des tags ; tout est dit dans cet article. Ce que nous constatons fréquemment, c’est que les politiques de tags se traduisent par une nomenclature répertoriant une dizaine de clés sur un wiki d’entreprise. Elles sont rarement appliquées sur les ressources créées car elles appartiennent aux bonnes pratiques. Or les projets ont d’autres priorités que d’appliquer ce genre de règles. Quand elles sont appliquées, c’est rarement de manière efficace: casse non respectée, valeurs multiples qui ne sont pas tolérées. Ajoutez une mise à jour de la politique de tags, et là vous êtes sûrs d’ouvrir un sujet qui va durer plusieurs mois.
Dans ce contexte, vouloir en finir des recommandations et bonnes pratiques pour avoir un contrôle de conformité, le tout sur une plateforme optimisée en termes de coûts prend du sens. 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 leur impact propre sur la plateforme et ses coûts, et donnent aux pilotes une vision centralisée qui permet de mettre en place une politique de gouvernance forte et efficace.
Conclusion
Si vous vous reconnaissez dans les cas d'usage ci-dessus, le platform engineering est une peut être une solution à vos maux. Nos experts WeScale peuvent vous accompagner pour la construction et la mise en place de votre platform.
Rendez-vous la semaine prochaine pour la seconde partie de l'article qui présentera les étapes clés de la création d'une platform.
