Hey there! Welcome to Platform Weekly, your weekly scoop of platform engineering sorbet. Every Friday, we dive into another piece of the platform engineering universe and dissect best practices, lessons, and news.

This is going to be a big one. So suit up. We’re diving into one of the biggest topics in platform engineering.

Backstage: everything you need to know

There are few topics as pervasive in platform engineering as Spotify Backstage. It’s an almost unavoidable part of most platform engineering conversations. However, like most things in cloud native, there are some pretty huge misconceptions about it. Let’s solve that.

First, wtf actually is Backstage? 

It’s a surprisingly tough question to get an answer for. If you ask Spotify, they’ll tell you it’s “an open source framework for building developer portals”.

If you ask many engineers (and probably a good number of you reading this), many would probably answer “It’s a platform”🙃 

I don’t blame people for getting lost. Especially, since if Backstage IS the platform in platform engineering, then this new discipline is gonna be much easier to master than anticipated.

Unfortunately, that couldn’t be more wrong.

Simply, Backstage is the first (and by far most dominant) Developer Portal. It was built internally at Spotify with its core functionality intended as a software and service catalog and was later open-sourced in March 2020 and donated to the CNCF.

To set the stage for how dominant Backstage is, I helped write a collection of whitepapers last year with variations for the 7 primary Developer Portals. Those whitepapers were downloaded over 70,000 times in 2023, and still currently get 100s of downloads a month - over 95%+ of those downloads were the Backstage variation. The other Portals barely scrape 1% of downloads each.

For what it does, Backstage deserves this dominance as well. It was developed to improve developer onboarding and developer experience (DevEx) at Spotify. Their platform team wanted to give their engineers golden paths, while also getting a clearer overview of service ownership to improve auditability and reusability, and based on the stats shared by Spotify - it does this extremely well.

So, what’s the catch? Well, for Spotify it works amazingly. Spotify reports an over 99% adoption rate, but for companies that have implemented Backstage? It’s less than 10%.

The reason for this is simple.

Spotify uses Backstage the way it is supposed to be used. As the front end of their Internal Developer Platform (IDP) NOT as the platform itself. They have a clear understanding of what Backstage is good at, its limitations, and how they should be using it. And they’ve got a backend for their platform too.

They use it for its software or service catalog, templates, techDocs, search, and k8s plug-in for a few simple (but very useful) functions. 

They also understand that open source doesn’t mean free. You might not pay for the software itself, but the 2-3 FTEs required to implement and maintain Backstage do cost money - and it’s not long depending on their seniority, the size of your org, and the scope of your setup that you are running into the hundreds of thousands in spend.

Very far from simply putting the platform in platform engineering.

Does that mean I think there is no place for Backstage? Definitely not. It’s a super valuable piece of tech, and combined with a proper backend for your Internal Developer Platform - will deliver insane results.

But it’s important you understand what it is, what isn’t, and if you want to get to the true value of platform engineering, what it actually means to implement it.

Quick bites

Article of the week:

• Platform engineering: Best practices in “Vendor engineering”

From the community:

• Backstage is not enough to build your platform - If you want more on this topic - this is a must attend webinar