An Introduction to Internal Developer Platforms

These days, developers have a lot of cognitive load.

You’re not just writing code, you’re playing around with cloud providers, troubleshooting Kubernetes, managing observability tools, making sure that your software is compliant with security best practices, and so much more…

It’s not only you.

It’s everyone in your organization. It’s slowing everyone down and sucks the living soul out of you if you just like building stuff.

You're not alone.

Developers are tired. Ops are tired. Stakeholders are complaining about why things are going slow. This is what sparked a new stage for DevOps.

Platform Engineering.

A Brief History of DevOps

I wanted to first tell you how we got here.

In the early days of software development. You had a team of developers who would develop an application, then the developers would pass it to the operations team to deploy.

This worked for simple applications but as software got more complicated over time, this approach proved to be faulty. As the teams were operating in silos, there was a lot of back and forth between them.

Problems such as long deployment cycles, risky deployments, high costs, and many more were common.

DevOps was created to solve these issues and it did.

But as software became more and more complicated. It introduced numerous different tools that had to be provisioned and maintained.

Cognitive Load Overload

The average developer has to use 10 different dashboards. Things such as GitHub, AWS/GCP/Azure, password manager, observability tools, and more.

It wasn't getting any better for DevOps engineers either. They had to do all the provisioning and maintenance of the tools.

Additionally, if anything went wrong, they would be pinged to fix the issue. In most organizations there just aren't enough DevOps engineers to support everyone.

You can see how this approach is not scalable.

Welcome to Platform Engineering

The philosophy behind platform engineering is to empower developers to do things themselves in a safe and easy manner.

By safe, I mean, they should be able to do things with predefined guard rails so that they can't do anything too crazy. On the other hand, easy simply means minimizing the mental effort to do things.

We do this by creating self-service platforms. For example, we could have a form that will allow developers to deploy their applications to some environment.

The possibilities are endless here.

You could have a self-service platform to provision a Kubernetes resource or a platform that manages secrets using a third-party tool like Hashicorp Vault.

Internal Developer Platforms (IDP)

There's this confusion between platform engineering and internal developer platforms.

They aren't the same thing. Platform engineering is a set of practices of designing, building, and maintaining the foundational infrastructure and tools that support software development and operations across an organization.

On the other hand, an internal developer platform is a subset of platform engineering, specifically tailored to address the needs of software development teams.

You can think of IDPs as a single window to everything that a developer would need in your organization.  

The goal of an IDP is to simplify and streamline the developer experience by providing self-service tools, best practices, and automation for tasks like deploying code, managing environments, and monitoring applications.

Examples of functions of an IDP would include:

• Hosting documentation and standards (golden path)
• Management of Infrastructure (Kubernetes, Cloud Providers, etc...)
• Management of Developer Friendly Tools (Elastic, Vault, etc...)

IDPs are custom-made, so you can automate anything that your organization uses and add it as a self-service function in your IDP.

When do you need an IDP?

Before you embark on the IDP train, you must first ask yourself whether you need it.

By "you", I mean the organization that you represent. It doesn't make any sense to build an IDP if you aren't a big organization.

So if you are one of the following, then you don't need an IDP:

• You are a small team (1-15 developers) and you have DevOps engineers or everyone in your team is comfortable with scripting or infrastructure.
• You have a single monolithic application.
• You have one application with a simple, single-cloud infrastructure.

Let's flip the script, and see where IDPs make sense:

• You have or plan to adopt a distributed architecture.
• You have a team of more than 15 developers with dedicated DevOps engineers (or plan to hire one). Your DevOps team (or person) can't focus on service-level agreements or workflows because of repetitive work.
• You have a small team and not everyone feels comfortable with deployments, scripting, and infrastructure and you have not yet hired a dedicated DevOps.
• Your developers are blocked in their work by dependencies on other colleagues.
• Anytime when you have to go multi-cloud.

Benefits of IDPs

The benefits can be broken down into three types:

Benefits for developers

IDPs help developers by keeping the cognitive load low so they can focus on the thing that they like to do, code. This makes developers happier and increases their productivity.

Developers also have the added benefit of being provided a golden path and the tooling around it. The golden path refers to the set of technologies that the organization advocates and that has lots of internal support tooling.

Benefits for DevOps engineers

IDPs help DevOps engineers by minimizing repetitive work. They can focus on enabling developer productivity while not risking resilience or availability.

This type of work is less mundane, which makes DevOps engineers happier and more productive.

Benefits for the organization

Due to the benefits above, the organization benefits from being able to ship faster, cheaper, and safer.

Due to the nature of IDPs and automation, a lot of things will have to be standardized (commonly referred to as golden path). This allows the organization to scale well.  

How does one build an IDP?

This one isn't straightforward. You would first need to set up a platform team that would be responsible for building the IDP. The platform team should treat the IDP as a product and the developers as its customers.

The process is just like building any software.

You have to gather requirements, select technologies, architect, build, deploy, and get feedback. But the special thing about IDPs is that it's essentially gluing a bunch of different tools into a single application that is easy to use and understand.

For specific tooling, you can check out the internal developer platform wiki: