What is an Internal Developer Platform?

An Internal Developer Platform (IDP) is the sum of all the tech and tools that a platform engineering team binds together to pave golden paths and enable self-service for developers. IDPs reduce ticket ops, standardize config setups, cut lead time and time to market and more. Well-designed IDPs follow a platform as a product approach, where a designated platform team builds, maintains, and continuously improves the IDP.

There are many solutions that get confused with IDPs, such as an end-to-end DevOps platform or a Heroku-like PaaS that try to cover the entire software lifecycle. Many people also get confused over the shared IDP acronym with internal developer portals (and service catalogs) like Backstage. The main difference is that portals act as an interface to an IDP, not as an IDP itself. There are also a whole host of other tools that also only cover single parts of the software delivery life cycle — all of which are not the same as an IDP. The Internal Developer Platform is the binding together of these all these different parts.

As IDPs are built out of different tools and technologies, an effective IDP won’t be available as an out-of-the-box solution. An effective IDP will be based on the needs of your software engineering organization and should be built based on those needs. When done well, an IDP will drive massive increases in developer productivity and velocity, and create a better and more effective working environment for developers and your operations teams.

An IDP will usually cover the following:

• Infrastructure orchestration
• Application configuration
• Deployment management
• Environment management
• RBAC

But why did teams start building IDPs in the first place, and why are more engineering organizations increasingly focussed on platform engineering? 

DevOps is born 

“You build it, you run it.” In 2006, Amazon’s CTO Werner Vogels changed everything when he described the company’s new approach to software engineering. Rather than developers throwing their code over the proverbial wall to operations to run in production, Amazon required them to deploy and run their applications and services end to end. Thought leaders then began stepping in and providing new metrics for organizations to gauge the success of their DevOps efforts. The term DevOps was officially coined in 2009 by Patrick Debois who founded the first DevOpsDays conference in Ghent, Belgium. However, we very soon began to slip away from this original promiseland. DevOps was supposed to be a culture, not a job title. And while the initial idea was for there to be better collaboration between developers and Ops, the reality was that many organizations decided to simply just shift as much load as possible onto their developers.

Core problem: cognitive load

While DevOps sounded great in theory, it was less consistent in practice. Alongside the shift towards DevOps were other trends that made the developers’ day-to-day more painful such as a sprawling tooling landscape (see below graphic), increasing cloud adoption, and the popularization of complex tools like container orchestration tool Kubernetes and Infrastructure as Code (IaC) tool Terraform.

All of a sudden developers needed to understand complex cloud native toolchains even for simple tasks like updating an environment variable, or debugging a basic database provisioning. This is insane and resulted in massively increased levels of cognitive load which ruined developer experience and crushed overall productivity. You can see below just how bad this situation has become over the last 20 years. And until now, there was nothing to suggest it would slow down or change.

Cue platform engineering

To solve this problem, in came platform engineering. Top tech companies everywhere started creating platform engineering teams and building platforms. These teams would work with a product mindset set with one major focus: building and maintaining IDPs for their “customers'', the developer. No longer would the developer need to master overly complicated and extensive toolchains. They could focus on what they do best - developing. We at last found a solution to this cognitive load crisis, and with platform engineering, the solution came without any sacrifices in velocity. As platform engineering improves developer experience and drives increased developer productivity.

Netflix quickly recognized this potential and started its platform engineering initiative in 2017. AirBnb then built its own platform on top of Kubernetes. 2017 was also the year that Thoughtworks Technology Radar article became the first to establish the need for platform product management. In 2019, Matthew Skelton and Manuel Pais unveiled "Team Topologies," often hailed as the definitive guide to platform engineering. This was the first book to speak about the platform team and its relationship with the rest of the engineering organization.

Key challenges solved by an IDP 

It’s clear that the purpose of an IDP is to solve problems. The IDP has the potential to reach every corner of an enterprise. IDPs can overcome slow time to market, slow innovation cycles, or a lack of standardization that leads to configuration drift and high volumes of static scripts that drown your developers and waste valuable time of your most expensive engineers.

From an operations perspective, key issues include a lack of standardization and automation, ticket-based workflows (ticket ops), and complicated infrastructure that’s difficult to setup and maintain. This all results in repetitive, manual tasks worked on under intense time pressure leading to DevOps burnout and eating up resources, leading to massive wastes of time and budget.

Common developers' challenges include a lack of developer self-service which results in time wasted waiting on Ops (ticket ops) to do simple tasks. And the massively high cognitive load and poor developer experience caused by the expectation that developers should be an expert in everything, and own many traditionally Ops tasks.

Proof that Internal Developer Platforms improve performance

Along with solving enterprise-wide challenges, it became increasingly clear that engineering organizations investing in building an IDP performed better across all DORA metrics (lead time, deployment frequency, change failure rate, MTTR). This is in comparison to the vast majority of organizations that got stuck somewhere along their DevOps transformation journey. Puppet’s State of DevOps Report 2021 proved this for the first time, and used these metrics to compare practices of top-performing and low-performing organizations. More studies followed with similar results, such as Humanitec’s 2023 DevOps Benchmarking Study which found that 93.15% of top-performing software engineering organizations use internal tooling like an IDP compared to only 1.88% of low-performing teams who do the same. 

Tldr: the key differentiator between top-performing engineering organizations and the rest of the industry is their ability to design and build successful IDPs. 

Reference architectures for Internal Developer Platforms

If you’re ready to start your platform journey, this leads to the question “what should an IDP look like?” In the past, figuring this out could cost you months or years, as until recently there was no proven, standard pattern for platform teams to follow.

That is until a group of platform experts using data from 100s of setups from across varying company sizes put together battle-tested reference architectures for enterprise-grade IDPs that have been shown to work. This inspired us at Humanitec to create our own IDP reference architectures for AWS, Azure, and GCP-based platform reference architectures. Our aim was to help organizations design, build, and deliver an enterprise-grade IDP fast, following standard patterns that apply regardless of your requirements — or how much technology changes, and that are based on extensive research of already successful platforms. To help speed this process up and simplify things even more, we’ve open sourced ‌the reference architecture implementation codes for AWS and GCP-based platforms. 

The five key IDP components

There are five main planes set out in the reference architecture that make up an IDP:

1. Developer Control Plane – this is the primary configuration layer and interaction point for the platform users. Components include Workload specifications such as Score (used in the reference architecture) and a portal for developers to interact with. It can be the Humanitec Portal, but you might also use Backstage or any other portal on the market.
2. Integration And Delivery Plane – contains the tools that build, store, configure, and deploy requests coming from the developer control plane such as an orchestrator, which in our example, is the Humanitec Platform Orchestrator.
3. Resource Plane – contains all resource components necessary to run the app. 
4. Monitoring And Logging Plane – provides real-time metrics and logs for apps and infrastructure. 
5. Security Plane – manages secrets and identity to protect sensitive information, e.g., storing, managing, and security retrieving API keys and passwords.

You can start setting one up yourself easily with these open sourced reference architectures.

Platform Orchestrators: the new standard

As a category, Platform Orchestrators are becoming the standard as the centerpiece of any enterprise-grade IDP. Platform Orchestrators are what turn your disjointed toolchain into an enterprise-grade Internal Developer Platform. Platform Orchestrators were mentioned in the last Thoughtworks tech radar, discussed at KubeCon, and are a hot topic amongst leading consultancies and the likes of Microsoft. Platform Orchestrators allow you to make the most out of the power of platform engineering. They enable you to build true golden paths for developers for workflows like roll back, ephemeral environments, deployment pipelines and much more. It allows you to easily standardize these workflows and configs by design and reduce the complexity of tasks on developers, without sacrificing velocity or productivity at all and turn your IDP into a truly enterprise-grade platform.

To round up, the Internal Developer Platform is the sum of all the tech and tools that a platform engineering team binds together to pave golden paths and enable true developer self-service. When done well, IDPs reduce ticket ops, standardize config setups, cut lead time and time to market. Top-performing teams build their own platform, and recognize that using a Platform Orchestrator is the best way to build and run an effective enterprise-grade Internal Developer Platform. The best platform teams use platform orchestrators to get a Minimum Viable Platform (MVP) up and running in as little as 4 weeks.

By using our new open source implementation codes for AWS and GCP setups, you can move the same way and fast-track the entire IDP design process by building a minimum viable platform (MVP) within days, rather than months. For more support, head to our learning path to master your Internal Developer Platform.

Last update: January 18th, 2024