Backstage est un framework open source dédié à la création de Developer Portal. Développé et maintenu par Spotify, le projet fait aujourd'hui partie de la CNCF (Cloud Native Computing Foundation).
Depuis ses débuts en 2020, le projet n'a fait que grandir : plus de 1650 contributeurs, bientôt 30k stars sur Github, et même une journée de conférence dédiée, la BackstageCon, aux côtés d'évènements prestigieux comme la KubeCon et la CloudNativeCon.
Le framework est devenu une option incontournable pour toute organisation souhaitant se lancer dans la création d'un Developer Portal. Cependant, l'implémentation de Backstage peut se retrouver être très frustrante si l'on ne fait pas attention aux pièges se trouvant sur notre chemin.
1 - Ne pas réfléchir à une stratégie d'adoption
Pour commencer, parlons un peu de stratégie et plus particulièrement de celle dédiée à l'adoption de votre portail par vos équipes.
C'est l'une des premières pages de la documentation de Backstage que vous devriez lire avant même de vous lancer dans son usage. En effet, l'un de vos buts lors de la construction d'un Developer Portal est d'arriver à faire en sorte qu'il soit adopté par tout le monde. Dans le cas contraire, vous aurez juste perdu beaucoup de temps et d'argent.
L’équipe en charge de l'intégration de Backstage – ou plus largement de la plateforme – devra piloter la conduite du changement. Comme le décrit Spotify, si vos "clients" (= les équipes de développement) ne se sentent pas inclus et écoutés, vous n'arriverez probablement pas à co-construire votre portail. Workshop, pair/mob programming, tutoriels, démos, metrics et autres seront vos alliés.
2 - Vouloir tout faire en même temps
Dans une démarche de Platform Engineering, le chemin vers une plateforme stable et fonctionnelle est long. De la récolte du besoin à la mise en production en passant par une boucle de feedback, il va vous falloir du temps pour implémenter les bonnes solutions. Un Developer Portal n'est presque que la cerise sur le gâteau du Platform Engineering.
La plus grosse partie de la valeur ajoutée de votre plateforme se trouvera dans les services rendus par celle-ci ; le portail n'est là que pour les exposer de manière simple et intuitive. Bien sûr, certains éléments n'auront peut-être leur place que dans le portail, comme l'affichage de metrics.
D'après mon expérience, il est risqué de lancer conjointement le développement des services de la plateforme ET de votre portail. En effet, selon la configuration et la maturité de votre équipe, vous risquez de vous retrouver à toujours attendre soit le front soit le back pour avancer. Vous allez aussi peut-être perdre du temps lors de la récolte de feedback sur vos services. Si les fonctionnalités côté back-end/plateforme ne conviennent pas, alors vous allez sans doute devoir également modifier le front-end/Backstage.
Il existe bien d'autres moyens qu'un front-end pour exposer vos services, surtout si vos clients sont majoritairement des développeurs. Une CLI ou une API feront largement l'affaire dans un premier temps.
Si vous êtes familier avec les termes Day-0, Day-1 et Day-2 pour décrire le cycle de vie d'un logiciel, alors le portail devrait arriver lors du "Day-2" du cycle de vie de votre plateforme. J'ai l'occasion d'en parler lors d'un talk de présentation/REX de Backstage réalisé au Devfest Nantes 2024 : Platform Engineering Day-2: Unifier vos outils avec Backstage
3 - Les coûts cachés
Une autre chose à prendre en compte avant d'utiliser Backstage est la stack technique proposée par le framework. Vous n'aurez pas d'autre choix que d'utiliser React en mode SPA pour le front-end et Express.js pour le back-end.
Selon les compétences à votre disposition et pour un projet aussi structurant, des frais supplémentaires de recrutement d'une équipe expérimentée sont à prévoir.
Des développeurs connaissant d’autres frameworks peuvent intervenir sur Backstage, mais il est préférable d’avoir au moins un expert React pour éviter de tout remettre en question dans un an.
Pour faire le lien avec le piège précédent, si vous recrutez une équipe mais qu'elle ne peut pas être efficace parce que vous essayez de tout réaliser en même temps, vous allez inévitablement perdre de l'argent.
4 - Réinventer la roue
L'un des plus gros avantages de Backstage est l'aspect open source. Avec plus de 1650 contributeurs, l'écosystème de Backstage est une vraie mine d'or pour qui saura l'exploiter. La page dédiée aux plugins sur le site web de Backstage compte plus de 230 plugins dont seulement 5 ne sont pas communautaires.
Avant de développer votre propre plugin interne pour intégrer un de vos outils, il serait judicieux de jeter un œil à la liste des plugins. C'est là que réside toute la valeur ajoutée de Backstage, vous allez pouvoir expérimenter et avoir du feedback très rapidement. Bien sûr, vous n'atteindrez pas vos objectifs finaux en une semaine et vous aurez pour cela sûrement besoin de développer des fonctionnalités et des plugins qui vous sont propres. Cependant, il serait dommage de ne pas profiter d'une boucle de feedback très courte qui vous permettra d'affiner votre besoin et de mieux y répondre par la suite.
Attention tout de même avec les plugins open source, vérifiez bien qu'ils soient maintenus et à jour !
5 - Combattre le framework
Ce piège s'inscrit dans le même esprit que le fait de réinventer la roue. Si vous choisissez d'utiliser Backstage vous allez être contraint d'utiliser ses technologies et de vous plier à ses choix. Impossible d’utiliser un autre framework que React, de se passer d’Express.js ou d’intégrer votre Design System, et la liste continue...
J'exagère volontairement le trait car dans les faits, vous pourriez essayer de faire tout ça et vous y arriveriez peut-être, mais vous perdriez beaucoup de temps et d'argent à essayer de combattre un framework qui ne vous convient pas.
Quand ce comportement apparaît, il faut se poser les bonnes questions. Si vous en êtes à un état avancé dans l'usage de votre Developer Portal, peut-être est-ce le moment pour vous de vous éloigner de Backstage vers une solution qui vous convient mieux, et c'est tout à fait normal.
En revanche, si ce comportement apparait dès le début, deux cas sont possibles :
- Backstage n'est pas adapté à votre besoin/contexte
- Votre besoin n'est pas aussi spécifique que vous le pensez
Il est parfois difficile d'identifier dans lequel des deux cas vous vous trouvez. Il faut réussir à prendre du recul et parfois faire des compromis. Backstage est un très bon outil pour itérer rapidement, utilisez le en tant que tel et ne vous imposez pas de la complexité inutile en voulant aller trop vite et vers quelque chose de trop spécifique.
6 - Ne pas faire de plugin
J'ai parlé précédemment de la nécessité de s'intéresser aux plugins communautaires, car le système de plugin est au cœur de Backstage. L'ensemble des fonctionnalités fournies de base par Backstage sont en fait elles-mêmes des plugins. Cela signifie que vous allez devoir segmenter vos fonctionnalités en différents petits "modules" indépendants que vous allez ensuite pouvoir intégrer grâce aux APIs fournies par Backstage. Vous pourriez tout coder dans l'application principale et surcharger le front de Backstage mais je ne le recommanderais pas pour plusieurs raisons.
Comme mentionné plus haut, si à l'avenir vous souhaitez vous séparer de Backstage vous serez bien embêté au moment d'extraire vos fonctionnalités. À la manière de l'architecture hexagonale, dans une moindre mesure, ce système de plugin vous permettra d'isoler vos fonctionnalités.
L’isolation des fonctionnalités facilite également les tests.
Cette isolation à travers les plugins vous permettra également, dans des fonctionnalités plus avancée, de ne pas venir "polluer" un concept avec un autre et de vous retrouver avec un "big ball of mud". Par défaut, chaque plugin possède sa propre base de donnée, cela limitera également les possibilités de tout mélanger.
7 - Faire l'impasse sur l'inner-source
Cela est mentionné dans la documentation de Backstage : la collaboration des équipes et l'inner-source sont des caractéristiques de réussite d'un Developer Portal construit avec Backstage. Au-delà de profiter des plugins communautaires, vous devriez aussi profiter de votre communauté interne et de ce qu'elle peut vous apporter.
Le périmètre couvert par un bon Developer Portal est trop vaste pour être géré efficacement par une seule personne. Dans ce cas, pourquoi ne pas profiter de l'expertise de vos utilisateurs pour vous aider à construire la meilleure solution possible ?
Le système de plugin est également pensé pour cet usage. Par exemple, si une équipe souhaite retrouver dans votre portail des informations d'un outil qui lui est essentiel, mais qui ne l'est pas pour la majorité de l'entreprise, ce ne sera probablement pas votre priorité. Mais si cette équipe peut être autonome pour répondre à ce besoin, alors tout le monde est gagnant.
Bien évidemment, ce type d'organisation/contribution nécessite de poser un cadre et des règles pour rester maître de l'application.
Bonus : retour d'expérience
La première chose à faire avant d'utiliser un framework comme Backstage est d'établir un état des lieux de son SI. Vous ne vous en doutez peut-être pas, mais vous possédez peut-être déjà certaines briques indépendantes qui auraient leur place dans un Developer Portal. Tout dépend de la maturité de votre SI et de l'avancée de votre démarche de Platform Engineering.
Pour les identifier, il est nécessaire de savoir quel but vous souhaitez atteindre à travers la mise en place et l'usage d'un Developer Portal. Si cette vision cible croise les initiatives individuelles menées par vos équipes, alors il y a peut-être un sujet à creuser.
Récemment, j'ai accompagné un client dans sa volonté d'intégrer Backstage au sein de son SI et rapidement, nous avons été confronté à cette réalité. Ce client était déjà à un stade relativement avancé dans sa démarche de Platform Engineering mais souhaitait aller encore plus loin.
Un premier ensemble de besoins avait été identifié et le travail pour y répondre avait commencé. Quelques temps après mon arrivée et avec une compréhension plus claire du cap choisi, il a vite été évident que quelque chose allait coincer : les outils déjà en place. En effet, beaucoup d'outils développés en interne étaient déjà en place et fonctionnaient bien. Ces outils étaient utilisés par des centaines d'ingénieurs et des dizaines d'équipes. Il y avait donc un fort taux d'adoption et les équipes pouvaient difficilement se passer de ses outils. Pour autant, il y avait bien des choses à améliorer et c'était la raison d'être de ce souhait d'utiliser Backstage et de développer de nouveaux services.
Quelle stratégie adopter dans cette situation ?
Des outils sont déjà en place, les équipes qui les administrent et les développent sont devenues expertes de leur domaine, les services fournis facilitent la vie de leurs utilisateurs et réduisent la charge cognitive, les utilisateurs sont contents des services à leur disposition (bien que perfectibles) et présentent un fort taux d'engagement, ... Peut-être est-ce le signe que le combat n'est pas à mener à travers Backstage mais à travers l'évolution des outils en place, vers une démarche plus unifiée (tout comme celle prônée par Backstage mais sans avoir à tout recommencer)
Conclusion
Backstage est un très bon framework quand vous l'utilisez pour les bonnes raisons. Si vous en êtes au début de votre démarche de Platform Engineering, commencer par le Developer Portal n'est peut-être pas une bonne porte d'entrée. Concentrez-vous sur ce qui apporte de la valeur. Une fois les inconnues écartées, vous serez plus serein lors de l'intégration de votre portail.
Après avoir commencé votre travail sur Backstage, profitez de tout l'écosystème qu'il apporte. Explorez les plugins communautaires, développez vos propres plugins, contribuez vous aussi à améliorer Backstage à travers l'open source et intégrez vos équipes dans la co-construction de votre portail.
Pour terminer, faites attention à l'effet de mode (parfois appelé Hype Driven Development) et au Cargo Cult. Ne foncez pas tête baissée dans l'usage de Backstage, prenez du recul et déterminez avant toute chose si le framework peut répondre à vos besoins.
