Backstage vs Archium

Looking for a Service Catalog and thinking about introducing Backstage to your dev team?

Here’s some reasons you might want to consider trying out Archium as an alternative instead.

Why You Might Want Backstage or Archium

Most teams building a distributed system quickly realise that it’s hard to keep track of all the components that make up their system. But they also realise very quickly that it’s very important! This discovery usually leads to an initial effort to list out what’s in the system, and who’s responsible for which parts of it. There are also usually heartfelt promises to keep this list up to date forever.

This simple idea of keeping a list of everything in a system has come to be called a Service Catalog. Once teams have this initial list of services and teams, they soon realise it’s a great place to start connecting all kinds of information about their system’s components.

A few years ago, the engineering team at Spotify decided to start tackling this problem not with a wiki page, but by building their own app. They called it Backstage, and in recent years they’ve open sourced it, and donated it to the Cloud Native Computing Foundation (CNCF). It’s currently in CNCF’s Incubator stage (August 2022).

But Backstage is not the only way to get a Service Catalog app for your team. The universal need for a solution to track all the moving parts of a distributed system has led to the emergence of a growing range of products, including Archium. All of these applications aim to help technology teams record, analyse, and manage their system. But let’s take a look at how these two are different…

Archium and Backstage Compared

There’s of course many different angles we could use to compare two Service Catalog products.

We think the biggest differentiators between Archium and Backstage are:

1. Catalog Automation
2. Software Architecture Model Detail
3. Hosting & Cost of Ownership

Let’s look at each one a little closer…

1. Catalog Automation

A Service Catalog is only as good as the information that’s in it. At their heart, Service Catalogs are just a specialised form of documentation. A key issue when it comes to documenting systems is that it’s really hard to get docs comprehensive and then keep them up to date.

Archium’s Automation

Archium places a high priority on automating the population of your Service Catalog.

Archium connects to your system’s distributing tracing and reverse engineers the structure of your system. It finds all the Components in your system, the APIs they expose. It also analyses the interactions between Components that are actually happening in your production environment. This makes getting your Service Catalog built, and keeping it up to date, as simple as accepting Archium’s suggestions for additions to your catalog.

Automation in Backstage

Backstage doesn’t automatically discover your system’s components and APIs. While its docs talk about automatically populating its catalog, that automation refers to reading files from version control and copying the information in them into Backstage. The information in those files, though, is still expected to be written by the team managing the service. What if they forget to add the file, or forget to tell Backstage about it, or forget to keep it up to date? Then you’re going to be living with an incomplete and out of date service catalog.

If you want a Service Catalog that can keep itself up to date with minimal documentation effort from your developers, Backstage is not going to offer you that. If you really wanted to, you could probably make a big investment into building that automation for yourself. Alternatively, you can check out Archium, where that level of automation is included as a core feature.

2. Software Architecture Model Detail

The thing about collecting information automatically (rather than asking people to type it up) is that you can collect a lot more information.

Archium’s Data Model

As well as building a Service Catalog from your distributed tracing data, Archium builds a detailed software architecture model. So on top of the list of Components in your system, it will also detect and record:

• the API Entrypoints each Component has;
• the features of the system that use each API;
• the Trigger Events that kick off scheduled processes in your software;
• the causal relationships between APIs as requests and data flow through your system; and even
• whether messages between Components are synchronous or asynchronous.

Archium’s detailed architecture model allows you to answer very specific questions about the system like:

Which services must be available in order for someone to complete checkout?

Which features of the system make use of this API Entrypoint we want to deprecate?

When we send a message to this Kafka topic, where does the data end up?

Archium’s architecture model means you can answer these questions instantly. It also allows you to generate detailed diagrams, like the one above, of how the different parts of your system interact with each other to implement the system’s features.

Backstage’s Data Model

While Backstage has a concept of an API as part of its data model. However, there’s two big limitations to their usefulness. Unfortunately, these limitations prevent the data model from offering any insight beyond what developers would already know.

Firstly, APIs in Backstage are not automatically detected, but are read from a YAML file. In most organisations, that file will probably be a document updated manually by developers. That means having up-to-date API information in Backstage will rely on developers keeping their API documentation up-to-date.

Secondly, Backstage’s model can’t record causality between APIs, or links between API usage and system features. (In fact, Backstage’s current model has no concept of a system having features.) The model has the simple notion of a Component consuming a certain type of API (e.g. REST) of another Component. However, there’s not even a simple way to record which parts of the API a Component does and doesn’t use. And there’s nothing like a causality chain explaining why a Component uses an API. That means Backstage’s model is incapable of answering the questions Archium can answer.

If you just want a place to store data that your developers already know so that other people can look it up, Backstage may suit your purposes. (But so would any wiki.) If you’d instead like to have a detailed architecture model of your system, that can reveal insights about your system that no one in your organisation knew before, you’ll need to get yourself an Archium account.

3. Hosting & Cost of Ownership

Hosting is the most obvious difference between Archium and Backstage, which is why we didn’t put it at the top. But, for some, it may be the biggest differentiator.

Archium is offered as Software as a Service (SaaS). That means that Archium takes care of almost everything to do with getting your Service Catalog set up and keeping it running. From building the code and provisioning the database and infrastructure, through to upgrading the software and maintaining its security, Archium takes care of everything around running its Service Catalog so that you can just use it. We even secure your account with Single Sign-On at no extra cost.

Backstage, on the other hand, is open source software that your technology team will need to customise, build, deploy, upgrade, and manage themselves. You’ll need to create a custom Backstage app unique to your org. Yes, you read that right: The first step of setting up Backstage is not “download the software” but “create your own fork of the software”. You’ll need to choose, provision, and maintain a database. You’ll need to decide how to host the Backstage software, and who’s going to be responsible for maintaining it.

Want your Backstage app to be secured? First you’ll need to edit the source code to add in a (provided) sign-in page component. But that alone won’t prevent anonymous users from accessing it. If you don’t want unauthenticated users accessing your Backstage app, you’ll need to set up extra security infrastructure in front of it. Backstage itself doesn’t prevent anonymous users from browsing around and taking actions.

While the cost of acquiring Backstage is impossible to beat, running it within your org is not as simple as spinning up some software. It’s a significant, ongoing technology investment. It will require a non-trivial contribution of precious time from your technology team – those hard-to-find people who you’d probably prefer to be doing something innovative that’s going to push your company forward.

Wrapping Up

So, that’s the three big items that distinguish Archium as an alternative to Backstage: Automation, Architecture Model Detail, and Cost of Ownership.

There’s certainly a few benefits to Backstage, and some product features that differ from what Archium offers. Which one you’ll choose depends on what you’re looking for, and how much maintenance you’re prepared to take on.

Do you want to understand your software architecture like never before? Do you want an architecture model that can surface insights that nobody in your team will find themselves? Do you want to have your technologists focused on pushing your company forwards while someone else looks after your Service Catalog? If these sound like your priorities, you should definitely give Archium a try.

Get in touch today and we’ll get you set up with a free one month trial.