Within devtools, the service catalog and developer portal category has emerged recently. Why? Because industry trends have shown that improving developer experience and efficiency is ultimately beneficial to the customer.
Today we’ll explore Spotify Backstage, one of the tools in this category. We’ll look at the problems it solves, and whether you should bring Backstage into your organization.
What Is Spotify Backstage?
First, let’s do a quick intro. In short, Backstage, or backstage.io, is a developer portal platform. It provides the ability to abstract away a lot of the infrastructure, CI/CD, and operational knowledge needed to run an application or product. Also, it can establish the foundation of your developer experience to provide a central hub of information for your company’s services.
To further the discussion, let’s move into the problems that Backstage solves.
What Problems Does Backstage Solve?
Now, let’s consider the developer experience at companies that don’t use a tool like Backstage. For that, I’ll ask that you sit back and picture what may be required at many companies to ship new products and build applications from scratch.
Setting the Scene
Let’s imagine that we’re working in a large enterprise, perhaps one that didn’t start as a software company and one that is still working through its digital transformation. The company has silos of information and not a lot of automation or integration between tools.
At this enterprise, our goal involves creating a new service or application. What do we need to get that done? If you were to say that we need to just write the application, you may be considering only a small percentage of the actual work that’s required. Oftentimes application teams in these types of organizations spend a lot of time learning and navigating the infrastructure ecosystem before they even start translating business logic into code.
For example, first, teams may need to go to a siloed infrastructure org and use their portal to provision and configure the necessary infrastructure. To set up CI/CD, the team might need to go to another team to provision pipelines, or sometimes even set up their own.
And then to operationalize their application, they’ll need to go to different systems, enter various tickets, and fill out various forms to ensure that they have the proper logging, monitoring, and alerting systems set up. And this is just the bare minimum.
In order to ship and software, the developer needs to keep in mind not only the problem they’re solving but also the siloed and disparate systems they need to integrate with.
Building the Story
Looking at another scenario, let’s say our hypothetical team also wants to integrate with an existing internal service. First, to simply find the service or API, they need to talk to their architect or leadership, search Slack or GitHub, wade through out-of-date documentation, or dig through Excel spreadsheets to find who owns the service and what the integration process involves.
To get more detailed information on how the service works, they might repeat the previous process. Often, they make their biggest breakthroughs when they know someone who knows someone on the application team they need to connect with in order to unblock their progress. And if any of that information changes, they may not find out until it’s too late. Changes in the SLOs/SLAs, support, and upgrades usually get sent out via email–hopefully someone is watching out for relevant changes.
Oftentimes the data or knowledge necessary to build anything in large organizations is siloed and segregated in different systems. Whether they use GitHub for source code, LogDNA for logging, Datadog for monitoring, or PagerDuty for alerting, the development teams often have to piece the information together and then create their own adhoc documentation or wiki to keep that information close at hand.
All of this adds toil, knowledge silos, and complexity. Nothing is ever in one place and easy to use. Most large companies have at least some of these problems. And many have a lot of these. Perhaps some of these points feel familiar to you. So what do we do now that we understand the problem?
Our industry has become much more aware of the customer experience and how our software affects it. But we’ve paid less attention to the developer experience.
Backstage solves this by providing a platform to design your developer portal in a way that fits your software engineering ecosystem.
In prioritizing the customer, we forget that a solid developer experience ensures that our customers receive better products and services, smooth and fast rollout of new features, and much more.
Backstage solves this by providing a platform to design your developer portal in a way that fits your software engineering ecosystem. And it leverages Spotify’s software development know-how and the years they’ve spent solving this problem internally.
So now that we understand the motivation behind Backstage, let’s look a bit further into the product itself. First, Backstage offers an open-source developer portal platform. It gives you the building blocks to create a platform to manage your complex software development ecosystem. The wonderful thing about open source is the low barrier to entry–get started whenever, wherever, and however you want. Now let’s break Backstage down a bit further.
At the center of it all, Backstage’s foundation is a service or software catalog. It allows you to track and manage all of your services, apps, pipelines, and more all in one place. And it makes service ownership clear and easily updated by the development teams. Additionally, it makes services discoverable within your organization, making reuse easier and more efficient.
Additionally, Backstage has made it easy to create software product templates specific to your company. You get to define the standards and tooling needed by application services or components, and the templates allow you to make it easy for others to use. This provides a simple way for your teams to get new projects set up quickly and easily.
You get to define the standards and tooling needed by application services or components, and the templates allow you to make it easy for others to use.
Next, Backstage provides out-of-the-box management for your technical documentation. And to make it easy for your teams to keep documentation up to date, it allows teams to manage it all from their code repositories. No need to go elsewhere!
And finally, Backstage has opened up the platform for plugins created both externally by the open-source community and by your teams. Through these plugins, you’re able to integrate with more systems that your development teams might use to build, deploy, and operate their applications.
What Does It Take to Run Backstage?
So as with many open-source products like this, Backstage is not a silver bullet you can deploy and forget.
You need a team to own and build out your Backstage developer portal or service ownership catalog. This team will need a mix of skills revolving around operating, upgrading, patching, customizing, extending, and driving adoption of the platform.
First, you need a team to own and build out your Backstage developer portal or service ownership catalog. This team will need a mix of skills revolving around operating, upgrading, patching, customizing, extending, and driving adoption of the platform.
From a setup perspective, you’ll need to configure the infrastructure and add the right integrations and plugins that work for your organization. And from an operational aspect, you’ll eventually need end-user and on-call support.
Though many of your integrations will use available plugins or other open-source plugins, your team may also have to build plugins for integrations that currently don’t exist. This also provides an opportunity to contribute back to the open-source community.
Now, lacking any of the above doesn’t mean that you can’t use Backstage. In fact, if you already have a central developer experience or platform enablement group, you may already have the team to put this in place.
However, you must decide where your development hours are best spent. Maintaining a product like Backstage will require time and effort on tasks that probably aren’t your main product differentiators.
Backstage itself brings on its own complexity and operational needs. And for some companies, that’s OK. They know where the product is lacking and have the capacity to build it out to suit their specific needs.
But other companies know that self-managed open-source solutions aren’t always the best answer. Though the software is free, customizations, maintenance, and operations are not. And this takes time from your developers that they could better spend on building core competencies and product differentiators.
A SaaS Alternative
OpsLevel takes a different approach to solving the developer experience problem than Backstage. First, OpsLevel provides a hosted alternative to Spotify Backstage. In addition to managing and operating the infrastructure and application, they take an opinionated stance on how to build out your developer portal to drive service ownership. Although Backstage supports your ability to create developer portals, OpsLevel specializes in taking the non-differentiated, tedious tasks off your plate.
Bringing It All Together
Overall, backstage.io can help your organization manage the complex developer ecosystem. It will improve the efficiency of your development teams, help them build products faster, and centralize information. However, there’s a cost to deploying and managing all of this yourself. OpsLevel can provide all the same benefits, without the hassle and hidden costs of running an open source project like Backstage.