Internal Developer Portal: What It Is and Why You Need One
In this post, we'll take an in-depth look at Internal Developer Portals including what they are, what they do, and a tool that can help.
One main advantage of the cloud is that it offers developers flexibility and a self-service solution. Instead of having to contact the central infrastructure team whenever a dev team needs a new server or a cluster, the dev team can do it themselves through a simple web UI. This change drastically improves productivity. But there’s a caveat: Most companies don’t actually want to use the default portals provided by cloud providers. There are a few reasons for this: security, simplicity, or the need for custom, company-specific options, to name a few. That’s why we now see a move toward Internal Developer Portals. In this post, you’ll learn what Internal Developer Portals are exactly and how they can make your developers’ lives easier.
An Internal Developer Portal is a self-service application and data store that lets developers and managers track and organize everything their engineering teams build and operate.
Imagine that you need a new microservice to be created. Your developers will first need to provision infrastructure for it; for that, they’ll use a cloud-provider portal. Next, they’ll need to create new CI/CD pipelines or modify existing ones. Then, they’ll probably need to implement some changes to existing components like API gateway and database. Lastly, they’ll probably need to add some documentation or make their new microservice visible to the rest of the company.
Overall, they’ll need to touch a few different UIs or portals. Now, imagine they can do all of that from one place. That’s what we call an Internal Developer Portal. It’s a self-service type portal that lets them catalog and understand relationships, ownership, resources, external service data, and anything else they need to understand and operate their software.
Now that we know what an Internal Developer Portal is, let’s take a step back and discuss why Internal Developer Platforms (IDPs) are on the rise nowadays. The main reason is simply because of the increased complexity of both software and infrastructure. Especially when we’re talking about cloud-based, microservices environments, it’s challenging even for senior engineers to keep track of all dependencies and things that need to happen every time changes are needed. Microservices architectures are heavily decentralized. Although you’ll still see the typical three-tier software architecture in most cases, it’s no longer easy to tell just by looking at a random component where it fits in the bigger picture just by its name or server location.
The second reason is that it’s simply a natural next step in the evolutionary process for self-service type portals. Old-school, on-prem-based environments barely had any self-service capabilities. Do you remember how difficult that was? To request a new server, you had to email the central infrastructure team. If you were lucky, you’d get it in a matter of hours or days. But often, it took more like a week or two. And if you made some mistake in the initial request? That would cost you an extra week of waiting. More advanced companies? Even when they created some custom self-service solutions, these were limited. Often, it wasn’t much more than an online form to be processed by the infrastructure team, which was often a bottleneck for all dev teams.
Then, when most companies started moving to the cloud, they started to see the benefits of self-service platforms. The ability to create servers ad hoc within a matter of minutes led to increased developer productivity, faster time to market, and better quality software. But again, cloud-provider platforms are suitable for managing cloud infrastructure, but you need more than that for a complete solution. Your developers can be more effective at creating and changing cloud infrastructure, but all the rest of the things that need to happen were still done separately. And that’s how we naturally evolve into Internal Developer Portals. Simply, to bring even more flexibility and clarity while increasing your dev teams’ productivity, you need to take the next step in the self-service platform evolution and combine all the things developers need into one Internal Developer Portal.
Also, from a business perspective, Internal Developer Portals bring clarity and offer a good overview of your whole infrastructure and software development efforts. Even if you’re in the cloud and your dev teams can manage the infrastructure as they choose, you still need some control and oversight—for example, to avoid wasting money on forgotten test servers that developers forgot to delete. Sure, you can get simple reporting from your standard cloud-provider portal, but what if you’re using multiple cloud providers or have a hybrid-cloud environment? Internal Developer Portal can benefit both developers and their managers. Long story short: IDP portals are the future of software development.
How do you create an IDP for your company? You can build your own from scratch, use some OSS offerings, or go for ready-to-use products like configure8.
The first option would give you the most flexibility and ability to perfectly tailor the solution to your needs. However, building your own IDP from scratch is almost like building your own operating system from scratch. It requires a lot of work, which could offset the main benefits that IDP is supposed to bring. You want to implement IDP to increase developer productivity and decrease time to market. But it would take you months to build it and then years to maintain it to keep it working properly with constantly changing cloud APIs.
The next option is open source IDPs. Since IDPs are, in general, quite complicated pieces of software, there aren’t many options to choose from. The two most popular are Backstage and Gimlet. The first one, however, is more of a DIY platform for building developer portals, which means you’ll still need to spend quite a lot of time getting something that actually benefits your company. Gimlet is quite popular too, but it focuses on Kubernetes-based environments. Both are great tools—don’t get me wrong—but if you’re looking for something ready to use and feature rich, consider the 3rd option.
The last option is to use a ready-to-use product like configure8. It’s a real powerhouse that combines the IDP functionality with Incident Response capabilities and things like easy metrics, dependencies visualization, and filtering across multiple clouds. All of configure8’s functionality falls into three categories:
Internal Developer Portals are gaining popularity for good reasons. In fact, many companies have been trying to build IDPs for years without even knowing about it. This is because an IDP-like solution will naturally evolve in any company that cares about developer experience and moving faster. The problem is that it usually takes years to come up with a single solution that fulfills all their needs. Another problem is that most of these “naturally” created Internal Developer Portals focus only on the tech side and skip the business needs. That’s why a tool like configure8, which was built from scratch as a dedicated IDP solution, can be much easier and faster to implement while also doing its job much better.
This post was written by Dawid Ziolkowski. Dawid has 10 years of experience as a Network/System Engineer at the beginning, DevOps in between, Cloud Native Engineer recently. He’s worked for an IT outsourcing company, a research institute, telco, a hosting company, and a consultancy company, so he’s gathered a lot of knowledge from different perspectives. Nowadays he’s helping companies move to cloud and/or redesign their infrastructure for a more Cloud Native approach.