Lessons from a Year with Backstage: What Worked, What Didn’t...
summary
Accidental adoption of Backstage scales to 40 teams and 350+ developers by shipping an end-to-end slice in a week then a four-week build and two-month onboarding, yielding 35 systems, 165 components and 404 APIs with four part-time maintainers. Wins: Azure DevOps/OpenShift integration, templates that automate repo/project provisioning, soundcheck dashboards for Helm rollouts, and linking Architecture/QA/Risk into a single catalog. Pains: long upgrade gaps that force a rebuild, persistent data-quality and modeling errors that break trust — mandate upgrade every 4–6 weeks and centralize entities.
AI-written summary · about
chapters (10)
- 0:00Backstage introduction and context
- 1:49Why we chose Backstage
- 5:05Iterative adoption approach
- 8:19Team champions for capacity
- 10:04Backstage as engineer product
- 13:12Extending beyond engineering
- 16:22Upgrade and data quality issues
- 20:35Standards and granularity challenges
- 23:44Future: notifications, templates, plugins
- 26:12Key lessons and summary
related talks
29mBackstage Revealed: Bright spots and dark corners
49mA Front Row Seat to Backstage Adoption
39mUnlocking Backstage's potential: insights and solutions for a smoother developer experience
22mUnlocking Backstage’s Potential: Driving Adoption and Maturity With Your Develope...
28mHow Did Backstage Make 500+ Developers Happy in a Highly Regulated Enterprise
29mHow We Made Backstage Improve Developer Efficiency of 1000+ En...
05mAdventures In Enterprise: Lessons Learned Promoting DevOps In A Legacy Organization
06mHow to Succeed with Backstage