Software developers are expected to master the entire software delivery pipeline—especially in DevOps. Because of this, they risk cognitive overload and a loss of productivity. 

Successful companies solve this issue by establishing internal developer platforms—IDPs, or platforms for short. In fact, Gartner estimates that by 2025 95% of enterprises will fail to scale their DevOps initiatives without an internal developer platform.

So it’s good to have at least a basic understanding of this topic. And that’s exactly why I created this blog post.

Below, I’ll answer these questions:

  1. What is an internal developer platform?
  2. What’s the experience working with one as a developer?
  3. Why exactly do you need one?

I’ll base my information on both extensive research on related topics, and on insights I have gained from assessing some of our customers’ DevOps capabilities. 

DevOps

DevOps is a software engineering approach that advocates automation and integration between software development and operations. The main idea is to embrace a culture of sharing, to break the silos between developers and IT administrators. On the technical side, DevOps builds upon version control, build pipelines, and a cloud-native toolset that relies on software containers.

What the term “internal developer platform” really means

For such a widely used one, the term internal developer platform doesn’t sound that descriptive. So let’s take a step back and explain each of its keywords—in the reverse order for clarity—to understand what it’s all about.

“Platform” 

In this context, the word platform means both an infrastructure and a collection of software tools. Typical functions of the platform relate to different aspects of the software delivery pipeline: 

  • provisioning resources;
  • carrying out different types of testing;
  • deploying artifacts onto a target environment.

The platform has a developer portal as its user-facing component. 

All elements in the platform are tightly integrated and built upon shared abstractions that you typically see in cloud-native software: containers, declarative configuration, and control loops.

“Developer” 

The developers are the end users of the platform. Self-service is the key aspect here, as developers: 

  • focus on creating value by swiftly implementing new features, without depending on IT to provision resources;
  • use templates to quickly create a proof-of-concept or a minimum viable product;
  • use a dashboard to gain a unified view across different data sources, from the outcomes of a build pipeline to the health status of a running service.

“Internal” 

This word emphasizes that the platform is specific to each company, very much like a tailored suit. 

You simply can’t buy it as a pre-made product: you need to build and maintain it. It’s based on the processes, governance principles, and technical solutions adopted by your company. And it clearly outlines the so-called golden paths—the “recipes” on how to build stuff, including tutorials for new developers to quickly get started.

A fancy way of putting it is: An internal development platform is an effort to empower developers to create value by careful selection and integration of software tools that support company-internal practices.

Platform engineering

The terms “internal development platform” and “platform engineering” are usually used together, but aren’t synonymous. Platform engineering refers to the process of establishing and running an internal development platform, especially in terms of culture and impact on teams. These include developer onboarding, establishing a platform team, and ensuring commitment to the platform—not only from developers, but also from the company. In contrast, the term internal developer platform more typically refers to technical aspects alone: the chosen collection of tools and their actual integration within the platform.

Find out more about platform engineering

What it’s like working with an internal development platform: a short example 

It should be clear by now that the platform is all about developers. But what is their experience with the platform in concrete terms? Let’s illustrate this by looking at Amanda’s experience.

Amanda has just started working at a company. As part of her onboarding, she’s given access to the company’s internal developer platform. Once inside, she’s presented with a dashboard that has concise instructions on how to get started. 

She starts by exploring the software catalog, which tells:

  • what components that are available at the company;
  • the components’ maturity level (some deployed in production, others are proof-of-concepts);
  • how they relate to each other.

She then goes to the section on software templates, which provide a wizard-like interface to bootstrap different types of projects. 

Amanda has prior experience with backend development, so she selects a template to create a microservice with the python programming language. She picks a name for the component and presses a button to create it. After a couple of minutes, Amanda is given access to a newly-created software repository with a sample microservice. 

The platform: 

  1. picks up the source code;
  2. creates a testing infrastructure;
  3. builds the software;
  4. runs unit tests;
  5. deploys the microservice. 

Amanda sees the outcome of the build pipeline and the availability of the new component directly from the dashboard.

She then starts checking the content of the software repository. The microservice employs the FastAPI framework to create an application programming interface. She’s new to FastAPI but the source includes a link to tutorials that are available within the platform’s dashboard. 

Amanda starts reading the tutorial and succeeds in adding features to the sample microservice before even completing her first week at work. The tutorials aren’t only explanatory but also compelling, making her eager to get to know more about how software is done at the company.

The platform helped Amanda achieve a strong feeling of independence and accomplishment by improving both her knowledge and productivity. After several months, she still uses the platform’s dashboard on a daily basis: she has even created new templates and tutorials.

Why you need an internal developer platform

It’s clear that improving developer experience is the main goal of an internal developer platform. But the benefits aren’t limited to developers. 

Satisfy your employees 

Employee satisfaction is at the core of successful companies: it helps attract a skilled workforce, reduce turnover, and increase productivity. 

A successful platform is a welcoming and friendly environment that provides context to explore and support, to start or become involved in software projects. It also offers safety in experimenting without compromising quality.

Make technology easier

On the technical side, the platform offers a curated set of functionalities through a carefully integrated toolset that spans the entire software delivery pipeline. 

This helps overcome tool complexity and the overhead of maintaining several, diverse software products. It also reduces cognitive load by providing a consistent and supported set of services. So, you can reduce overhead and let developers focus on what really matters: delivering customer value.

Provide self-service

The platform consolidates architectural and technical choices in a developer-friendly way. Therefore it’s easier for developers to adopt company-wide best practices. And through self-service, the platform promotes trust and makes it easier for everyone to follow governing principles and compliance. 

Stay in control

The platform also avoids fragmentation and a bring-your-own-tool mentality. This means you can streamline access control, security checks, and monitoring. And you can do all that with minimal interference with the developer’s workflow.

In short, an internal developer platform optimizes the process of delivering value to customers, fast. It does so by focusing on developer experience while ensuring security and compliance. 

The platform is the foundation of how work is done at your company. It follows your values and governance, but is flexible enough to adapt to dynamic environments. By overseeing the software delivery pipeline, it simplifies the related processes—at the same time allowing DevOps to scale.

Summary

By now, you should have a clearer view of what an internal development platform is, what it does, and why it’s needed. My goal was to give you a brief introduction to the topic and highlight the value it brings to DevOps, primarily in terms of developer experience. Establishing a successful platform is not easy though. It’s a long journey, but now is just the right time to get started.

Published: Apr 25, 2023

Updated: Dec 18, 2023

DevOpsCloudCI/CD