TLDR: This isn’t a hot take blog post. I spent some time evaluating the internal developer portal trend, as well as Backstage and Port. My conclusion on whether you need one… it depends on your organization.
This post is part 3 of a series where I explore internal developer portals, specifically Backstage and Port. To this point, the series has mostly been focused on my journey doing a proof of concept with each solution.
I outlined what an internal developer portal is and what problems they attempt to solve in part 1 of the series. In short, an internal developer portal tries to improve the developer experience, making them more productive in their day to day work, and ultimately more satisfied with their job. Long term this investment should lead to better business outcomes as developers deliver more quickly, with higher quality, and with less bugs.
You need something. At a bare minimum you need to be considering developer experience. That means listening to feedback from your developers, and taking action to address their concerns when warranted.
There are several ways to do this:
As a general rule I would recommend each of these approaches depending on organization size. With grass roots being the best approach for smaller companies, and dedicating a platform team being best for larger companies. But there are other factors at play such as company culture, tech stack, and developer personalities.
As far as internal developer portals, I wouldn’t recommend adopting one until you have reached the decision to create a dedicated platform team. As we saw in my proof of concepts, there can be a steep learning curve, and there is quite a bit to manage. You need to have clear ownership for the portal.
It’s also important to understand that developer portals are not a silver bullet.
They won’t solve cultural or people problems. If you have pull requests that take on average 5 days to turn around, releases that constantly have bugs, or really long cycle times, implementing a developer portal isn’t going to fix it.
You also have the problem of too much abstraction that developer portals can create. I’m a firm believer that the best organizations are full of developers that understand how software is delivered and operated from beginning to end. I’m concerned the developer portal trend may reinforce a siloed culture where developers do not learn how the process works outside their bubble of the portal.
The cool factor is there for sure, I just haven’t had the opportunity to see how this plays out in larger organizations yet. Consequently, I would proceed cautiously with any implementations, and encourage a pilot program instead of a full scale adoption to start. I suspect many organizations would be better served trying to instill a stronger software engineering culture before considering taking on a developer portal implementation. Although, taking on an effort like this would likely pull any cultural problems you have to the forefront.
In this section I will declare my winner in each category after doing a small proof of concept on both platforms. Check out parts 1 and 2 of this series to see my experience.
Port wins this one hands down for me. It was incredibly evident that Port has dedicated a significant amount of effort to making sure the onboarding process is top notch. Features such as auto importing service repositories from Github, embedding next step instructions into the portal, and the Guides & tutorials sections were great experiences. Port does the things you’d expect from a paid SaaS product and also has an interactive demo.
Backstage on the other hand had decent documentation as well. But the nature of Backstage being a self hosted product with the ability to customize infinitely, lead to some clunky experiences. When doing my proof of concepts I would say I spent at least four times as long on average with the Backstage implementation vs Port. There is no doubt there is a significant difference in learning curve between these two products.
This one didn’t have a clear winner for me. I thought both products did a good job. Backstage’s configuration approach is easy to wrap your head around and allows you to define attributes of services within the repository itself. Port took a point and click approach to adding services but also allows for auto importing via a Github integration.
Both products also allowed for rich relationship building between different entities within the service catalog. Again, Backstage does this with configuration and Port with a point and click approach. You are able to create systems composed of smaller services, assign ownership in the form of individuals or groups, and view properties about a service like programming language.
Backstage has first class support for this and is a core part of the product. You point Backstage to a location your documentation exists, and Backstage renders it within the portal. Port on the other hand does support adding free form text or architecture diagrams, but you have to set up relationships within the builder to do this. It wasn’t as straightforward and I only discovered the capability by playing with Port’s demo.
This is a core feature of Port and they do it well. The goal is to score quality of a service based on predefined thresholds. This score can alert development teams that they are not adhering to the standards of the organization. You can create custom properties to score on anything from approved programming language to whether the repository has a README. Backstage has this capability via a plugin maintained by Cortex. Check out part 2 of this series for more details.
Backstage software templates are robust and provide a built in templating and repository generation solution. Backstage allows you to define locations for template repositories, which are then transformed into complete repositories after user input is substituted into the template.
Port by contrast relies on the user choosing a ‘backend’ to perform any actions needed. For example you can choose Github Actions, GitLab, Jenkins, etc. to perform the task. This is the same pattern Port uses for all self-service actions, so there isn’t anything special here, or an opinionated approach to templating. You can still define what inputs you want the user to provide, but in terms of templating and resolution, you’d be on your own for that.
Backstage integrated directly with Github Actions, which is my CI tool of choice. Port does as well and I thought the integration was high quality. The presence of Github Action logs in Backstage gave it a slight edge but not enough for me to declare Backstage the clear winner.
Port also has a cool approach for setting up self-service actions like rolling back a service to a previous version, or restarting it. Port does this by allowing you to hook up any self-service action to a ‘backend’. The backend can be your automation tool of choice. In my case I hooked up the backend to Github Actions to allow kicking off a build just to test it out.
Check out part 2 for a more in depth analysis of the integration.
Port won this one by default because it took my a while to get Backstage to connect with my local minikube cluster due to ssl configuration issues. I eventually had to disable tls verification. Backstage took a ‘query the cluster’ approach while Port took an approach that involved installing a service into the cluster. After following Port’s instructions things just worked. I could see my services and associate them with the appropriate entries in my software catalog.
Port appeared to have more robust customization options here. With Port I can decide exactly what kubernetes resource types I care about, and which attributes. I can then assign those to any blueprint property I’d like. Backstage, on the other hand, had pre-configured information that it would display about a given resource type.
Based on my limited experience with these tools I would choose Port until I found a reason to switch to Backstage, assuming the SaaS cost isn’t prohibitive. I’m a sucker for good experiences and quick ramp up time and Port seems to have thought this product through. I found myself wanting to play around in Port and see what was possible. I had several, “this is awesome” moments, and every time I went back to Backstage I found myself missing the nice UI and documentation from Port. The nail in the coffin is that it took me 4–5 times as long to do the same things on Backstage I was trying to do with Port.
This decision will be heavily dependent on your organization. I’ll outline circumstances I would choose one over the other. However, as I mentioned above, Port would be my starting point.
If you are on the fence with whether or not you want to adopt internal developer portals in your organization, I would start with Port. The ease of onboarding and superior documentation can have you up and running much more quickly than the same proof of concept with Backstage. If you like the concept but need more customization, or you don’t like the Port price, you can always move to Backstage.
Port lends itself more to a click-ops environment. While Backstage does much of its configuration through source code, Port handles almost everything via its SaaS web interface.
The learning curve and maintenance required for Backstage will require a team of significant size. Not to mention you have to host Backstage yourself, unless you went with a hosted solution like Roadie. Port will definitely be less work to maintain.
Backstage is an app with an Angular frontend and a Node backend, and you own all of it. You can customize it as much as you’d like.
Backstage is an open source project and has a rich ecosystem around it. Consequently you can expect a vast array of plugins and extensions available for the platform from the community, instead of having to wait for a company like Port to implement something. Also, Backstage is free, except that you’ll have to pay any hosting costs yourself.
You prefer that all changes to the configuration of your developer portal, as well as the services within it, are done via a typical development workflow. This means pull requests and reviews before changes take place.
I enjoyed exploring the internal developer portal trend and hope this series provided some value for you. If you have more in depth experience with these products, I’d love to connect to hear how implementations have gone at a larger scale than my proof of concept was able to provide. Please reach out on LinkedIn or leave a comment!
To learn more about how Callibrity can help your organization, email us at contactus@callibrity.com to schedule a time to connect.
