What if I told you that Backstage is NOT an internal developer portal?
And why you need to rethink how you see Backstage
What are Internal Developer Portals?
They are a tool that provides an overview of all your services and the relationships between them. In addition they also help you see who owns those services and other helpful information about them.
Developer portals integrate well with other tools such as your CI tool, repository, infrastructure, security and others to provide an up to date view of the latest status of the service in a single pane of glass.
So for example a developer can go into the portal, look at a service and instantly see the latest deployments, documentation, related infrastructure, message the owner, see who is on call, etc.
This is far better than having to maintain a wiki page to provide all of this information as it usually goes stale very quickly and you need to ensure it is well structured and free of duplicates so it’s easy to find. It's also better than having to scour Slack channels to get context about services or asking the same question to other colleagues and teams, breaking their flow.
Internal developer portals can also provide other helpful functionalities, for example they enable you to define quality checks for services to see which ones meet company standards (bronze, silver, gold, etc). This ensures that your teams have standards to strive towards to help reduce technical debt and remain compliant.
Finally, developer portals also let you define self-service actions, for example to create infrastructure, trigger lambdas or whatever you can think of, effectively abstracting away the need for developers to fiddle with scripts provided by a platform team.
Backstage is not exactly a developer portal, it's a framework to build one
It may sound like a small semantic difference but it’s huge in practice. It's the difference between installing and configuring vs creating, fine tuning and maintaining. Backstage is very powerful and would allow you to build the portal of your dreams but that also means a lot of work and you most likely will require a team creating and maintaining it, so you need to factor in that cost.
This is why so many people who come to Backstage thinking it's going to be like installing Kubernetes end up balking at how incredibly complex and difficult to set up it can get, and yes, I am aware that Kubernetes is already very complex, that's why I am using it as an example.
In that sense, a commercial alternative such as OpsLevel or others may be a lot easier to manage and cheaper in the long run, because you won’t have to spend nearly as much maintaining, creating and updating the developer portal as you would with Backstage.
Backstage is still the most flexible and comprehensive choice if you have the engineering resources and time to invest your time in creating a developer portal with it, but you should always bear in mind that it isn’t a ready baked portal and you will need to spend the time to develop and maintain it.
About the Author
Fernando Villalba is a Developer Relations at OpsLevel, he has over a decade of miscellaneous IT experience. He started in IT support ("Have you tried turning it on and off?"), veered to become a SysAdmin ("Don't you dare turn it off") and later segued into DevOps type of roles ("Destroy and replace!"). He has been a consultant for various multi-billion dollar organizations helping them achieve their highest potential with their DevOps processes. Now he is passionate about platform engineering, developer portals and DevEx, which he feels is where the future of software delivery shines brightest.