What is an Internal Developer Platform (IDP)? Why Do They Matter?

The Complexity Crisis in the Modern Engineering Organization

Demand for custom software is at an all time high but the process of developing it is more complicated than ever. Thanks to the rise of cloud and cloud native tools, there is a litany of tools and services developers have to integrate and maintain in order to meet industry standards. Furthermore, the software itself is under increased scrutiny. Teams create standards for their products that promise the “ilities” from securability to extensibility to portability and beyond, but struggle to adopt them uniformly.

The day-to-day of a software developer has also noticeably shifted away from just planning and writing feature code. They are under pressure to build and deploy more custom software under tighter timelines. They must consider code quality, security, infrastructure, and more. Maintenance burdens have shifted to development teams, increasing time devoted to waiting on ops teams for security patching, updates, and provisioning requisite infrastructure–if they’re lucky enough to even have ops support. Delivery deadlines are missed, velocity slows.

The problem worsens as teams adopt modern technologies, like Kubernetes, or move from monoliths to microservice architectures. Developers are forced to wait on Ops to unblock the infrastructure required to test and deploy their code, substantially increasing lead times. Often, development teams end up with a mess of free-floating scripts patched together into a complex web of services and tools. Maintaining them is an error-prone, time consuming nightmare, but the problem worsens as business needs pile up and developers are pushed to deliver.

Simply hiring more Ops members and developers is not enough to remedy this situation and is unlikely to happen quickly enough to keep pace with rising maintenance needs.

Enter: The Internal Developer Platform

The Internal Developer Platform (IDP) was created for exactly this situation. Tech giants like Google, Amazon, Netflix, Spotify, and more built the first Internal Developer Platforms internally to reduce the burden on their Ops teams. By abstracting infrastructure complexity away from their developers, they found remarkable improvement in dev experience and productivity. They also found it an effective mechanism to increase developer autonomy while enabling uniform standards adoption.

Internal Developer Platform:

An abstraction layer on top of the Ops tool stack enabling developers to spin up and deploy application infrastructure preconfigured by the Ops team without waiting.

Ops teams set defaults for common paths and expose other configuration options, should the developer need customization.

Internal Developer Platforms are also known as developer portals, Kubernetes platforms, containers-as-a-service, and self-service platforms. They integrate with the organization’s custom infrastructure and restrict access to development teams through a custom role-based access control (RBAC) model managed by the Ops team. Ops teams stay in control of baseline configurations and templates, systematically enabling infrastructure and standards uniformity across projects.

Why You Need an Internal Developer Platform: The Day-to-Day Impact

Internal Developer Platforms are becoming an industry standard approach to scaling engineering teams, especially as companies adopt cloud-first, service-oriented architectures.

In particular, they:

Boost developer experience and productivity

The best part about Internal Developer Platforms is the immediate effect it has on a developer’s day-to-day. By enabling them to spin up preconfigured environments without waiting for Ops, developers can test and deploy code more frequently. They never have to wait on Ops for an environment to become unblocked. Onboarding new developers is a breeze. Infrastructure inconsistencies across teams are eliminated. Adding third-party resources is much simpler than before. Services are secure and shared across the company, eliminating redundant time spent recreating or maintaining the same service across different teams.

With functioning Internal Developer Platforms, developers are able to spend more time in their flow state, working on value-add work like new features or robust internal tools. Easy access to scalable platforms to build and run code makes it easier for developers to flexibly support new use cases or changing requirements.

Set standards that are actually followed

As organizations grow, expectations of the final product grow along with it. These are codified into development standards from extensibility to reliability to securibility, and beyond.

But the adoption of these standards is a challenge and monitoring compliance can be a futile exercise as more services are created. With an Internal Developer Platform, the Ops team creates standardized workflows for developers to follow, enforced through an RBAC model. With these bespoke “illities” standards baked into the infrastructure accessed by developers, uniform standards adoption is possible and devs produce higher quality code in less time.

Eliminate developer toil

Toil is sucking up engineering time that could be spent on value add work. Whether it’s patching, updates, or firefighting, service maintenance costs development teams increasing amounts of time and energy, worsening as new tools are added to the stack. With an Internal Developer Platform, services are set up in a secure, centralized location. Developers access it safely through golden paths enforced by role-based access control configured by the Ops team. They no longer have to recreate infrastructure in error prone ways that previously left the company vulnerable.

Relieve pressure on Ops teams

As development teams race to meet tight deadlines, they put pressure on the Ops team to streamline and automate the software delivery process. In particular, modern Ops teams have large infrastructure provisioning workloads, bottlenecking developers waiting for environments to build and test code among other needs. As companies adopt microservice architectures with different teams managing different services, Ops teams’ maintenance burdens go through the roof.

Internal Developer Platforms give developers a portal to access their infrastructure requirements without having to set it up themselves. Ops configures everything in one place, allowing them to maintain control of development standards and unlocking developer autonomy. By removing ad hoc developer interruptions from their plates, Ops has the ability to tackle more of their workload. Removes key person dependency and makes it easier to swap tools.

Getting Started with an Internal Developer Platform

While homegrown Internal Developer Platforms are present in big tech and an increasing number of high growth SMBs, there are still relatively few offerings to buy one. Future blog posts will dive into the “build vs buy” decision for an Internal Developer Platform, but a good place to start is WayScript.