Backstage.io has made a name for itself as an extensible platform for building developer portals. If you're looking for alternatives to Backstage, you probably realize that you need a developer portal or a microservice catalog. You understand the benefits this tooling can provide your engineering teams, but you're not quite sure which route to take. And yes, Backstage has received a lot of hype—but are there alternatives that you should consider?
Perhaps you've realized that implementing Backstage fully will require an entire team just to get started with building out your own custom instance. After all, it's a platform, not a product. And even once you’re all set up for deployments, authorization, and authentication, adding plugins and defining workflows remains a heavy burden.
In this post, we'll look at four alternatives to using Backstage and consider when those tools may be right for you.
What problems does Backstage.io solve?
To begin, let's talk about why engineering teams consider Backstage in the first place.
As organizations grow, their service landscape becomes more complex. They slowly acquire dozens to hundreds of services and even more APIs—and each of those services and APIs has metadata and processes attached.
Backstage is an open source project organizations can use to build developer portals and service catalogs. It lets you build solutions that provide a central portal to view and manage services, infrastructure, documentation, deployment pipelines, metrics, monitoring, and more.
But with that flexibility, you also take on the burden of extending and building your portal solution from scratch. Unless you're staffed to host and maintain Backstage, while also customizing it using TypeScript, you may start growing wary of hidden costs. And when you begin to look at the work involved, you’ll likely start exploring alternatives that can provide the same benefits.
Backstage.io alternatives
We'll introduce four alternatives to Backstage. It's not an exhaustive list, but it will give you options and insight into how to evaluate alternatives.
Backstage.io is a platform for organizations to build developer portals and service catalogs.
1. Cloud-specific tools and portals
Your first step would be to utilize what your cloud provider gives you.
Whether it's AWS, GCP, or Azure, your provider will have dashboards, service catalogs, API listings, and more. For example, the AWS Service Catalog offers out-of-the-box solutions that provide a generic view of your services, with options to control access and build integrations using their APIs.
With the right access and knowledge, you can find your way around your organization without coding knowledge. You'll get features soon after your cloud provider makes them available, and you don't have to work to maintain any custom code.
However, tools like this have drawbacks.
- They create a reliance on a particular cloud provider. You can't take them with you if you decide to change platforms. Or if you work in a multi-cloud environment, they don't provide the high-level visibility you need across all environments.
- They're not always intuitive. They will require that your teams learn and understand cloud-specific categorization and workflows. Additionally, access may not be fine-grained enough to provide what you need or may be difficult to maintain as your organization and its permissions model grows.
- They often feel disjointed. All resources of similar types often get lumped together, and you don't have as much control over presenting the information in an easily digestible way for non-developers.
Overall, using what you have from your cloud provider gives you a great start when you have a small organization with only a few dozen microservices. At this point, you don't necessarily need the weight of a full platform and can use what's already there. But once your organization and microservice ecosystem start to grow, you'll want another solution and that will most likely lead you down the DIY path first.
2. Do-it-yourself
In the past, we've written about how a DIY solution is possible for building a microservice catalog or portal. To recap, companies often go the DIY route to begin. They start with spreadsheets containing services, links to wikis, and contact information. Later they expand to a small service or two that provides a better UI for viewing and updating services across the org. Next, they'll begin building additional integrations and functionality into the CI/CD pipelines or monitoring solutions.
This could work for your organization, but you want to consider a few things. The DIY route can be extremely flexible and customizable—your development teams will be able to choose the languages and frameworks they're most comfortable with, which should improve their ability to ship features.
However, that work takes effort and dedicated teams to build and maintain. For many product organizations, an internally built microservice catalog or portal will not drive the product. This type of work isn't your main product differentiator, and spending developer resources on building your own developer platform is time and effort not spent on driving product features.
A DIY approach can get you started and help visualize the need for more robust tools. However, you need to consider whether having an internal team build an internal product to manage your service ecosystem will give you a competitive advantage in the market. Our bet? It won’t, and your product teams’ time is better spent shipping new features and applications.
3. Lyft's Clutch platform
A few years ago, Lyft created Clutch to solve these exact types of problems. They felt the need to create a platform to serve their development teams and improve the org's collective ability to ship and operate code in production.
Clutch provides an open-source platform that you can extend and customize. In this way, it's similar to Backstage. It allows your organization to customize and build on top of Clutch to get the benefits you need, and out of the box, it includes simple, predefined workflows to get started.
Clutch is built utilizing Golang, React, and protobufs for API serialization, and it provides solid developer docs and APIs. If you need to customize or extend your Clutch instance, having knowledge in those languages and frameworks will be critical. Similar to Backstage, Clutch will also require a development team for customizations and plugins.
Clutch and its default workflows may be enough to get you started if you're looking for something simple.
4. OpsLevel
Last, but certainly not least, is OpsLevel.
With OpsLevel, you're not actually getting a Backstage alternative, but a fully supported SaaS solution. That means you get the flexibility and functionality of Backstage but without the hosting and maintenance burden—or the risk of an abandoned platform long-term. You'll be able to focus your efforts where you need, prioritize product differentiating development cycles, and turn to a full team of support and success professionals whenever you have a feature request or question.
OpsLevel, by design, is opinionated. So your team does not have to carry the mental burden of defining what workflows to support, how to piece things together, and what customizations or plugins are most critical. Plus, your team won’t have to learn TypeScript or other new languages to put this all together.
You’ll see from exploring the OpsLevel blog that the team is continually releasing new features—so you're gaining functionality over time without putting in the development effort.
In addition to the software catalog and templates from Backstage.io, with OpsLevel you'll get features like quality and maturity checks, simple CI/CD integrations, service creation, and custom actions that enable developers to self-serve key operational tasks.
OpsLevel continually releases new features, so you're gaining functionality over time without putting in the development effort.
Summarizing your options
The developer portal and microservice catalog world includes a growing list of options. Some of those options are open source projects, others are fully supported SaaS solutions. While each engineering team’s needs are different, there are a few key considerations to keep in mind while you make your choice:
- How complex is your environment?
- What level of control or flexibility do you need?
- Where should your teams focus their time and energy?
These will guide you in choosing the Backstage alternative for you right now. And depending on your choice, that should set you up for future growth and functionality.
Ready to learn more about how OpsLevel stands out from the competition? Sign up for a demo, or check things out on your own with a free trial.
This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.