Why you should start using Backstage in your company
Everything that Sofware Engineers need in one place?
Recently, I had the opportunity to set up a Backstage instance in my company. It is a POC but comes from a real problem to solve and I want to share it with all of you.
In today’s issue, I cover
What is Backstage
The problem I want to solve with Backstage
Experience putting in place a Proof Of Concept
What is Backstage
For me, Backstage is a web portal on which a developer will find all needed for the daily work.
However, on their webpage they say:
An open platform for building developer portals. Powered by a centralized software catalog, Backstage restores order to your infrastructure and enables your product teams to ship high-quality code quickly — without compromising autonomy.
This is a tool that original was created by the Spotify team. On September 23, 2020, Backstage has been accepted into the CNCF Sandbox, and moved to the Incubating maturity level on March 15, 2022.
The CNCF shares a couple of case studies that might be of interest to you.
The problem I want to solve with Backstage
This comes because of a problem to solve, and let me know if this sounds familiar to you.
You are working on a microservice/app in your editor (tool 1), like IntelliJ for example.
You create a Pull Request in Github or Bitbucket (tool 2) so your teammates can review it, provide feedback, and at some point approve it to be merged.
Those teammates will get an email (tool 3), as a notification, that they have a Pull Request to be reviewed.
In the meanwhile, you want to see if your build, which automatically runs when you create a Pull Request (thank God!), is already green or is having issues with the component tests. For this, you go to Jenkins (tool 4).
All green, it’s being deployed in the dev Kubernetes cluster, so let’s take a look using K9S (tool 5). But first, you have to log into AWS (tool 6) since the dev Kubernetes cluster is in AWS EKS.
Humph… it’s properly deployed, but you see in the Pod logs that your service is responding with some HTTP 404. Let’s take a look into the observability tool, Datadog for example (tool 7) so I can see more details.
Right, I can see another microservice “Y” that is making calls to my microservice API, and this is the one that is getting HTTP 404… but “who” is this? Let’s go to the documentation tool, Confluence for example (tool 8), and search by the name of the microservice.
After several minutes, you find the microservice “Y”, and also the architecture diagram that says that such microservice will call yours… but not clear why to an API endpoint that you have not implemented. So, let’s ask the team responsible… go to the “magic” MS Excel (tool 9) where the map between teams, developers, and microservices lives.
Ok, I found the Tech Lead, let’s go to Slack (tool 10) and send her a message to start the conversation.
Yeah, I hope you see my point.
I’ve enumerated 10 tools (and most likely could be more) just for dealing with a code change that Software Engineers are doing or should do, plenty of times per day.
Do you know how much cognitive load and effort takes for your Software Engineers to do this all day every day?
Experience putting in place a Proof Of Concept for Backstage
At the end of 2023, I had the opportunity to put in place a Proof of Concept for Backstage. Fortunately, it was not only me, I had the pleasure of doing this with 3 more peers. Our goal: Understand if this tool might help us to solve the problem I’ve described above.
We just jumped into the Getting Started and installed it in a Virtual Machine (Linux Debian). We decided to install it using the Yarn way.
Note: By the way, are you aware that Yarn downloads “half of the whole internet” every time you install something with it? Damm, we set up 20GB of disk for the Virtual Machine and, after installing 4 plugins, the disk was out! I might dedicate a specific issue for complaining about this 😅.
Once we had the Backstage installed, the first thing we did was to set up some repositories. This is very easy because you have to
Add a YAML file to your repo in Github/Bitbucket.
Add this a new “component”, via Backstage UI, including the Github repo URL on which the YAML file was created before.
As Software Engineers, we were used to typing YAML files, so this was pretty natural for us. From here, our job was to install plugins to cover all the tools we used to use daily, pretty similar to what I described in the previous section.
The plugins I found interesting from the official plugin directory were:
Backstage Software Catalog
Backstage Software Templates
Backstage TechDocs
Backstage Kubernetes (*)
GitHub Pull Requests
Jenkins
Datadog
ArgoCD
Kafka
The majority of the plugins were straightforward to install, at least the ones created by Backstage directly. However, others took a while to make them work.
The documentation for setting up some plugins is not so clear and usually is outdated. The community is there, but still not many people on it, since the problems we faced in a simple POC, were not solved by the community yet, which makes me think that not so many people are using it.
Once all set up, I could see the value of this tool, and why it was created. In one single place, I could find documentation, service mapping and API links, monitoring, code changes, continuous integration, and more. No more back and forth between links and tools, all in one place. We reduced the usage of tools from 10 to 2: the editor and Backstage.
I talked to some people that already put in place this Backstage tool and they told me:
[…] basically, if you have more than 10/20 repos of code, the improvement should be noticeable, finding things easier. […]
Interesting links
Final words
In my opinion, yes, this Backstage can help to solve the problem I have. Nowadays I indeed see 2 major challenges, that will make this tool difficult to use:
Adoption. We will need to put in place a proper adoption strategy, so the rest of the developer teams adopt it
Have to work the good plugins. For example, one useful plugin to me it’s the one about Kubernetes, and we were not able to make it work.
There is a company, that I don’t know personally, that its business is based on the setup of Backstage and its plugins. I would recommend either you use a company like that for setting up and maintaining the Backstage or you hire some profiles that are used to configure and maintain this tool. A DevEx team, who has already done this in the past, could be an option for this ownership. Otherwise, you will waste too much time and, probably, give up before being able to try properly this tool.
Do you use Backstage.IO in your company? Any other similar tool? I would love to her from you about this, drop a message!
Best wishes,
Marcos