Ett år med Backstage — det här är väsentligt

Efter ett år med Backstage i produktion har jag hittat ett par saker som avgör om implementationen lyckas eller fastnar.

Daniel Fröding
Backstage developer portal med plugin-ekosystem och tjänstekatalog

Jag har arbetat med Backstage i snart ett år nu. Inte som en pilot eller ett sidoprojekt — utan som en central del av en riktig plattform för ett riktigt team. Under den tiden har jag lärt mig vad som faktiskt avgör om implementationen levererar värde eller bara blir ytterligare ett verktyg som ingen använder.

Värdet kom inte förrän CI/CD var automatiserat hela vägen

Det stora genombrottet kom inte när vi lanserade portalen. Det kom när vi hade automatiserat hela CI/CD-flödet från kod till produktion och kopplat det till Backstage.

Innan dess var portalen mest ett snyggt dashboard. Intressant att titta på, men inte särskilt användbart i det dagliga arbetet. När Backstage istället blev den naturliga ingångspunkten för hela leveranskedjan — när en utvecklare kunde gå in i portalen, se en tjänsts status, trigga en deployment och följa den hela vägen till produktion — då hände något. Adoptionen kom av sig själv.

Det handlar om att minimera kontextbyten. Om en utvecklare fortfarande måste hoppa mellan fem olika verktyg för att förstå statusen på sin tjänst spelar det ingen roll hur snygg portalen är. Men när flödet är sammanhängande och automatiserat från portalen, då är det där folk faktiskt jobbar.

Domänmodellen är grunden — och den är svårare än den ser ut

Den andra insikten handlar om hur man modellerar sin verksamhet i Backstage. Jag underskattade helt hur lång tid det tar att definiera en tydlig domänmodell — och hur stor skillnad det gör när man väl har en.

Backstages System, Component och Resource-entiteter är kraftfulla, men de tvingar dig att faktiskt tänka igenom frågor som organisationen kanske inte har svarat på tidigare:

Hos oss fastnade vi länge på relationen mellan komponenter, repositories och landing zones. Det är inte självklart, och det finns inget universellt rätt svar. Men det är avgörande att hela organisationen är överens — för det genomsyrar hela katalogen och i förlängningen all automation som bygger på den.

När vi väl hade en tydlig modell och dokumenterat hur system, komponenter och landing zones förhåller sig till varandra, blev allt lättare: onboarding av nya team, automation av infrastrukturprovisionering, och inte minst förståelsen för beroenden mellan tjänster.

Adoption kräver en ägare, inte bara en lansering

Den tredje insikten är den som jag tror de flesta missar: Backstage är en produkt, inte ett projekt. Du kan inte lansera det och gå vidare.

Under det senaste året har jag sett direkt korrelation mellan hur aktiv en “Developer Portal Product Owner” är och hur mycket portalen faktiskt används. Utan någon som aktivt samlar feedback, prioriterar förbättringar och kommunicerar nyheter till teams, dör adoptionen sakta ut — även om portalen tekniskt sett fungerar perfekt.

Det behöver inte vara en heltidstjänst, men det måste vara en namngiven person med mandat att prioritera arbetet.

Vanliga frågor

Hur lång tid tar det innan Backstage ger värde?

I min erfarenhet: om du gör det rätt ser teams värde inom 4–6 veckor efter lansering, primärt genom Software Catalog och TechDocs. Scaffoldern tar längre tid eftersom du behöver bygga ut Golden Paths.

Ska man använda managed Backstage (Roadie, Spotify-hosted) eller self-hosted?

Det beror på teamets storlek och kapacitet. Self-hosted ger fullständig kontroll men kräver dedikerat underhåll. Managed alternativ tar bort en del av underhållsbördan men begränsar flexibiliteten. För de flesta medelstora organisationer utan ett dedikerat plattformsteam är managed en bra start.

Vad är det vanligaste misstaget?

Att börja med för många plugins och för lite fokus på datakvaliteten i katalogen. En portal med 50 plugins och dålig metadata är sämre än en portal med 3 plugins och utmärkt metadata.

Har du påbörjat en Backstage-implementation och kört fast — eller funderar du på att sätta igång? Hör av dig → så pratar vi igenom det.