What exactly is an Internal Developer Portal (IDP) and how does it relate to Platform as a Service (PaaS)? Perhaps more importantly, why would I use one or the other? Are these offerings contradictory or complementary?

We believe that, in most cases, large teams will benefit from using both of these capabilities together.

The most common example of an IDP is Backstage, which is also what our product is built on so we will focus there. It is worth noting that most offerings in this space have similar baseline capabilities. A typical internal developer portal offers these core features, and primarily caters to software developers:

• A catalog of all software components
• Documentation
• Project or Service templates
• Plugins for extensibility

Internal developer portals provide a view of all of the entities that comprise the software estate. This includes the people, software, and systems that are necessary to efficiently ship software to production. What an IDP doesn’t do is directly manage infrastructure or middleware. 

That is where Platform as a Service (PaaS) comes into the mix. There are a few notable PaaS providers out there with Heroku being the most recognizable public offering, OpenShift being common for on-premise/hybrid, and cloud-specific providers have their own unique offerings (Elastic Beanstalk at AWS, App Engine at GCP, etc). These platforms typically offer these core features:

• Abstraction of infrastructure
• Application runtime(s) and middleware
• Rigid or semi-rigid standards
• Defined security boundaries

From a developers point of view a PaaS makes deploying and running software faster and easier provided the PaaS, associated tools, and standards work for a given use case. Often this is where PaaS has struggled. When the requirements for a given service, application or project require more than the PaaS can natively support, developers are left to find alternative deployment solutions.  Most PaaS initiatives were deeply rooted in a “push” mentality, which as we spoke about in a previous blog post, and this can quickly lead to a fragmented developer experience.

An internal developer portal helps in scenarios such as this by providing an additional layer of abstraction for developer workflows. Engineering teams, including Site  Reliability Engineers, DevOps practitioners, and the application developers themselves can standardize alternative production platforms for consumption. The software, despite a degree of heterogeneity, still gets cataloged, documented and standardized through the IDP. 

Remember, platform engineering, at its core, is really an exercise in pattern matching and prioritization. Efficient organizations are able to identify and codify these patterns irrespective of the technology in play. An effective internal developer platform is technology agnostic. It serves as the central repository for communicating the established patterns and provides the automation necessary for a development team to take advantage of the efficiency the platform affords.

In this scenario, all golden paths regardless of production platform are available for a developer to use from the Arctir IDP. They may be deployed onto Kubernetes or Virtual Machines, our IDP doesn’t have strong opinions. It simply shifts the standardization of software further to the left.

This is a major difference from a standalone PaaS, and the other similar platforms. Most of those platforms attempt to provide and manage a software catalog but are often ignorant to the software that exists elsewhere, creating major gaps for SREs and other Ops teams who don’t have a real understanding of what is running, who created it, or where it came from.

We believe the IDP should be the heart of modern software development AND operations teams, so we are working to make that a reality. You won’t be replacing a PaaS with an IDP, but you can take a step closer to making the PaaS (or any production platform, for that matter) a pattern for successful deployment by codifying and enabling it within your internal developer portal.

For most organizations this raises the complicated question of how to structure and integrate a comprehensive Developer Platform, which includes an IDP and potentially several runtime platforms including PaaS providers. We will be covering this in an upcoming blog/video series, and as always if you are looking for a quick and easy IDP register for our Beta, we are adding capacity weekly:

arctir.com/register