Hier soir, j’ai eu la chance de pouvoir assister a un meetup de la CNCF Bordeaux, organisé par Denis Germain (entre autre) avec deux REX.
- REX sur Backstage chez Back Market : Le premier de Guillaume Chenuet de Back Market pour une présentation captivante sur leur implémentation et l’adoption de Backstage.
- REX sur les Sécurity Champions par Deezer
Cette sketchnote (que vous pouvez voir ci-dessous !) résume les points saillants de cette aventure.
💖 Au Cœur du Sujet : Backstage
L’adoption de Backstage chez Back Market est centrée sur la création d’une Platforme Développeur Unifiée et Efficace.
1. Le Contexte Initial
Le paysage technique de l’entreprise est complexe et en pleine croissance :
- Technologies initiale d’un gros monolite : Python, Django, Flask.
- L’Enjeu : Maîtriser cette complexité et fournir un point d’entrée unique et standardisé pour les développeurs dans le cadre de la migration vers une architecture plus modulaire de micro-services dans un environnement cloud natif (avec Kubernetes, Terraform, etc.) sur Google Cloud Platform (GCP).
2. L’Équipe et l’Objectif
- Taille de l’Équipe Tech : Environ 300 à 400 personnes.
- Objectif Principal : Scale Onboard - Standardiser et accélérer l’intégration des nouveaux développeurs ainsi que l’adoption des bonnes pratiques (via la Score Card) par les équipes existantes.
🏗 Les 4 Piliers du Déploiement
L’implémentation de Backstage a été structurée autour de 4 besoins fondamentaux pour bâtir une fondation solide :
- Catalogue (#1) : La “Truth” (source de vérité) pour tous les composants, services, et documentations.
- Template (#2) : Fournir des templates de projets standards (via le Scaffolder) pour démarrer rapidement et de manière conforme.
- Score Card (#3) : Un outil essentiel pour mesurer la maturité et la conformité des services aux standards internes.
- Plugins (#4) : Intégrer les outils existants (monitoring, CI/CD, sécurité…) pour centraliser l’expérience.
⚙️ Le Workflow de la Plateforme
Le schéma montre comment Backstage lie ces éléments dans le cycle de vie du développeur :
- Création : Un développeur utilise un Template (via Scaffolder) pour générer un nouveau service, qui est immédiatement enregistré dans le Catalogue.
- Déploiement et Opérations :
- Le processus utilise Terraform (TF) et des mécanismes de Pull Request (PR) basés sur un SKEL (squelette standard) pour garantir la cohérence.
- Conformité (La Score Card) :
- La Score Card évalue chaque service selon des KPIs (indicateurs clés de performance).
- Les niveaux vont de L1 (non conforme, nécessite des actions) à L4 (excellence/conformité totale). C’est un outil clé pour le “Scaling Quality”.
- Catalogue as a Source of Truth : Le catalogue permet l’Export de données vers des Third Parties (outils externes) et s’intègre au CICD.
✅ Les Victoires (WIN) et les Défis
L’adoption de Backstage est clairement un WIN pour Back Market, avec des bénéfices sur :
- L’Expérience Développeur (DX) : Amélioration de l’onboarding et réduction de la friction.
- La Qualité et la Santé de la Plateforme (PHA) : Assurer un niveau de standard élevé.
Les Défis de la Plateforme Engineering
Guillaume a également soulevé les enjeux de la maintenance :
- Friction : Gérer les Bugs et les le temps a passé a mettre a jour initialement
- L’Investissement : La question soulevée : combien de temps et de personnes sont nécessaires ? (Estimation à 2 ans d’effort à 2-3 personnes à Temps Plein pour maintenir la plateforme). Cela souligne que la Platform Engineering est un produit à part entière qui demande un investissement continu.
Conclusion
Le cas d’étude de Back Market est un exemple remarquable de la manière dont une Platform Team peut transformer un environnement technique en centralisant les outils et les standards via Backstage, ils facilitent l’onboarding et garantissent la qualité des développements à l’échelle.
Un grand merci à Guillaume Chenuet pour ce partage d’expérience très instructif !
[]