Service catalog and developer portals have recently emerged as the hot new tools within the DevOps world. Why? Because developers want to build faster and platform teams want them to have some semblance of standards. At the end of the day better builds mean better products and better products mean happier customers (and more revenue).
The build fast and break things mantra of the previous decade led to a world where a “service catalog” was usually a poorly maintained spreadsheet and your “developer portal” was a collection of those spreadsheets in a misc. notion doc. However, companies that were serious about growth started to develop their own internal tooling to manage internal chaos—enter Spotify’s open source project, Backstage.
We’ll explore Backstage, the problems it attempts to solve, and considerations to make before bringing it into your organization. Full transparency: Backstage is a competitor of OpsLevel so we obviously have a bias in terms of quality and effectiveness, but we will give Backstage credit where it’s due.
What is Spotify Backstage?
In short, Backstage is an open source developer portal platform. When built out effectively, it provides the ability to abstract away a lot of the infrastructure, CI/CD, and operational knowledge needed to run an application or product. It can also provide a central hub of information for your company’s services. In these ways, Backstage solves very similar problems to OpsLevel.
What problems does Backstage solve?
A lot is required to ship new products and build applications from scratch. Let’s consider the developer experience at companies that don’t use a tool like OpsLevel or Backstage. They likely deal with siloed information and little automation or integration between tools, which slows down speed to market and hampers the developer experience.
Creating a new service
Creating a new service or application depends on a lot more than just writing code. Engineering teams in these organizations spend a lot of time learning and navigating the infrastructure ecosystem before they even start translating business logic into code.
First, teams may need to go to a siloed infrastructure org to provision and configure the necessary infrastructure. To set up CI/CD, they’ll either need to provision their own pipeline or wait for another team altogether.
To operationalize their application, they’ll need to go to different systems, enter various tickets, and fill out multiple forms to ensure that they have the proper logging, monitoring, and alerting systems set up. And this is just the bare minimum. To ship new software, developers need to consider the problem they’re solving as well as the siloed and disparate systems they need to integrate with.
Integrating with an existing service
Let’s say our hypothetical team also wants to integrate with an existing internal service. First, 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 are usually sent via email.
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 ad hoc documentation or wiki to keep it 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?
How an IDP can help
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. When we give engineering teams the tools—like an IDP—to build faster, we give our customers more robust products and services, less outages, and smooth and fast rollout of new features.
Backstage solves this by providing a platform to design your developer portal in a way that fits your software engineering ecosystem.
Teams that choose Backstage get the source code with which to build their own custom developer portal from scratch. While the customization and flexibility of Backstage can help engineering teams build the perfect IDP, this build > buy decision demands countless hours to build and maintain a tool—time that’s typically better spent on high-impact projects.
Now that we understand the motivation behind Backstage, let’s look a bit further into the product itself. Backstage offers an open-source developer portal platform. It gives you the building blocks to create a platform yourself that manages your complex software development ecosystem. The great thing about open source is the low barrier to entry—you can 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 catalog. This allows you to track and manage all of your services, apps, pipelines, and more all in one place. A service catalog makes it easy to see and update service ownership, and discover services within your organization.
With Backstage you can 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.
Backstage provides out-of-the-box management for your technical documentation. It makes it easy for your teams to keep documentation up to date, by managing it all from their code repositories.
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. In late 2022, they also launched paid-for plugins of their own that Backstage users can now purchase.
What does it take to run Backstage?
As with many open-source products, Backstage is not a silver bullet you can deploy and forget.
You need a team to build out and own your Backstage developer portal with a mix of skills revolving around operating, upgrading, patching, customizing, extending, and driving adoption of the platform.
Once your team has built out your Backstage instance, they’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.
Build your product, not tools
See OpsLevel in action. Then get your service catalog up and running in minutes, not weeks!Request a Demo
Prioritizing eng resources
The maintenance costs involved in a DIY solution don’t mean that you can’t use Backstage—but you should take the time to assess whether you’re really saving money when compared to a SaaS solution like OpsLevel that doesn’t demand the same internal development hours. Companies that we’ve seen be successful with Backstage usually have a team of 5–7 engineers fully dedicated to updating and maintaining the platform.
And don’t forget the opportunity cost of your team’s focus. 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. For some companies, that’s fine. They know where the product is lacking and have the capacity to build it out to suit their specific needs. But others know that self-managed open-source solutions aren’t always the best answer. Though the software is free, customizations, maintenance, and operations are not.
Choosing a SaaS alternative
OpsLevel takes a different approach to solving the developer experience problem. In addition to managing and operating the infrastructure and application of our IDP, we take an opinionated stance on how to build out your developer portal to drive ownership, service maturity, and developer self-service.
With features designed specifically to empower day 2 operational tasks among developers, OpsLevel improves developers’ day-to-day experience and allow them to get more done, faster, without sacrificing standards.
Specific features aside, the key difference between OpsLevel and Backstage is that Backstage is not a SaaS solution. That means that organizations looking to implement Backstage must staff entire teams dedicated to building and maintaining their Backstage instance. In contrast, our Support and Customer Success teams can guide you through the complex change management required to successfully implement an org-wide DevOps tool, to ensure you get value right out of the gates—in days, not months. And, as a focused enterprise solution instead of an open source side project, OpsLevel customers have the confidence to know that we’re around for the long haul.
If your goal is to give your team a tool—not another project—the build vs. buy scale nearly always tips towards investing in a SaaS solution.
Final Backstage takeaways
Overall, Spotify’s Backstage 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.