In the early 2010s, three major trends started picking up: the cloud, containerization, and microservice architectures. All of them had a significant impact on our daily work patterns. Industry-accepted patterns had to change and adapt to the new standards. For instance, virtualization became the new standard for dedicated servers.
Where things should have become more simple, they often became more complex. The days where you could throw your software over the wall to the ops team were gone. Do you remember doing a simple FTP transfer to update your application’s files? That is plain simple!
On the other hand, it felt like everyone in the software engineering industry had their interpretation for the catchphrase:
You build it, you run it.
Many teams erased all boundaries and gave developers end-to-end responsibility from machine to frontend. In theory, that was great, but reality often looked quite different. Ops teams in many organizations came under intense pressure. Their tasks involved educating teams, trying to establish standards, or spinning up environments and databases. This is where the commonly preached catchphrase “You build it, you run it” came to its limits. Things didn’t get easier for anyone. Instead, they became more complicated for both development as operations teams.
And while the rest of the market struggled to make sense of the “you build it, you run it” paradigm, elite tech teams at companies such as Github, Airbnb and Spotify realized that this way of interpreting the paradigm increases cognitive load for the individual developer and decreases velocity. Moreover, they realized that this paradigm requires the ops team to scale exponentially to stay on top of all requests. This problem made them realize that things didn’t add up.
From the middle of this decade, elite teams started building a new breed of internal tools: Internal Developer Platforms.
They wanted to solve all the complexity involved in the delivery and DevOps processes. Therefore, these elite teams gave application development teams three panes of glass:
- <it>An IDE to write code<it>
- <it>A version control system like Git to merge code<it>
- <it>An Internal Developer Platform (IDP) to run code<it>
In those engineering organizations, “you build it, you run it” is defined differently. For those teams, DevOps became a culture. Here, SREs only look after the infrastructure. Ops teams configure the pathways and workflows application developers use. On the other side, developers use Internal Developer Platforms to take code from idea to production by themselves.
So, what is an Internal Developer Platform?
A gentle introduction to Internal Developer Platforms
First of all, two teams in the engineering team are involved in the use of an IDP. The Ops team, also called DevOps or Internal Platform teams, connects and wires up the infrastructure while taking care of baseline configurations.
The development team uses the platform in their day to day work. They will code, push their changes with Git, and the platform will pick up images from the automated CI pipeline run.
Next, the IDP makes sure that the right environments are updated automatically using the newly updated images.
It becomes more interesting when we look at all the new capabilities the platform gives to application developers. They can apply changes to configuration files without having to worry about crashing the staging or production server. It’s important to provide developers with room for experimentation by removing negative consequences. On top of that, developers now have the freedom to spin up resources they need or provision fully-fledged environments without requiring Ops’ assistance.
All of this is possible because you can wire up all your tech and infrastructure to this platform. Furthermore, you can set rules that tell the platform when to provision specific resources, such as databases, file storage, Kubernetes clusters, a DNS, and many more.
So, what happens with your app configuration?
How does an Internal Developer Platform manage application configurations?
Internal Developer Platforms use a very different way of managing application configurations. Rather than letting humans update and version messy scripts, they allow the Ops team to set baseline configurations through templates.
Developers can apply changes to those configurations on a workload-level, such as changing the CPU allocation, updating environment variables, or defining external dependencies.
At deployment time, the platform will apply changes to the baseline configuration template and create new manifests. In that manner, you have one unified bundle, which includes manifests, for each deployment.
An IDP treats application configuration like a version control system
The developer can then use this bundle to spin up fully provisioned environments and roll back to known good deployments - effectively treating the platform like a version control system for the state of application configurations.
What are the five components of an Internal Developer Platform?
So, what are the five core components of an IDP?
- <it>Application Configuration Management: Set baseline templates across workloads<it>
- <it>Infrastructure Orchestration: Wire up the infrastructure and tools and set the rules on how they get provisioned<it>
- <it>Role-Based Access Control (RBAC): Manage who can perform which actions<it>
- <it>Deployment Automation: Helps developers to deploy consistently, over and over again<it>
- <it>Environment Management: Spin up fully provisioned environments on-demand<it>
Of those five components, the Ops team usually uses three components to achieve enhanced deployment automation. They use Application Configuration Management to set baseline templates, to which developers can apply changes. On top of that, they use RBAC to have a fine-grained control mechanism over the system. The Ops team mainly uses Infrastructure Orchestration to hook all their tools to the platform and define how resources get provisioned.
On the other hand, developers can spin up new environments without the need of the Ops team and leverage the power of Deployment Automation to consistently deploy new images.
This brings you two significant benefits: innovation and speed. Let’s find out!
Two main benefits: Innovation and Speed
The impact of these tools is significant. In short, they introduce golden paths. Stay on those, and you can go fast without breaking things. They instill self-sufficiency in the application team as they can now take code from idea to production by themselves.
It’s their code, their application, and their responsibility to run it.
Simultaneously, the new ability to spin up apps and services on the fly becomes a source of inspiration, driving innovation and giving the teams an even more competitive edge.
Even so, it enables platform teams to manage all operational aspects and serve the developers in an automated, standardized fashion. All of this can be done at scale and without getting overwhelmed by repetitive tasks.
Interestingly enough, many leading tech companies have built those Internal Developer Platforms independently of each other for over 2-3 years. The reason is simple: they were facing similar pain points, and all drew strikingly similar conclusions.
The results are impressive. Basically, every single category-defining tech company has been running on those Internal platforms for years.
- Github: #1 in developer tools
- Airbnb: #1 in travel
- Zalando: #1 in Europe’s fashion eCommerce
- Spotify: #1 in music streaming
- Google: #1 in search
Jason Warner, Github’s CTO, summarizes this well when he says, “It’s something we had to build. We would have slowed down otherwise. If you slow down as an organization, you die.”
If you look at the fundamental data, you can easily spot that developer tooling and standards drive velocity and directly impact the business outcomes.
In a recent survey on the impact of teams implementing an IDP, the results were striking for both the ops team and the application development team.
Ops teams can serve two times as many application developers than without an IDP. Meantime to recovery, the time spent on maintaining scripts and integrations, or the time spent on onboarding colleagues or developers dropped drastically.
Moreover, it boosts the productivity of application developers. Waiting times due to blocked environments are reduced by 90%. The average deployment frequency increased fourfold, visibility across all environments drives self-responsibility, and the lead time drops by a factor of three.
Is that the reason why IDPs are going mainstream?
Why IDPs are going mainstream now
Internal Developer Platforms have been out of scope for most teams that weren’t tech-category leaders. Other than that, they lack the resources to build and maintain such a tool.
But the tides have turned. The rise of Kubernetes as a building layer has made it possible for teams from 15 developers onwards to build those platforms internally. Several of those early platform teams at elite companies have now branched out to build frameworks that can help teams build Internal Developer Platforms faster than ever. They help you get the entire feature set that elite teams at companies such as GitHub have had for five years now.
This trend will accelerate as more small and mid-sized teams adopt Kubernetes. A good indication is when people are organizing independent Kubernetes-focused events and community meetups. Or when it’s the number one topic on KubeCon, one of the most prominent Kubernetes conferences. Or when ThoughtWorks puts an IDP on the technology radar.
It’s becoming much easier to build an Internal Developer Platform yourself, and off-the-shelf frameworks are evolving. Reasons for this rise of IDPs are deeply grounded in the immense impact they have on both the ops as well as the application development team. On the other hand, the DevOps space has reached the point where they understand the shortcomings of the current DevOps and GitOps culture. This is why vendors, among Humanitec, show up to offer commercialized Internal Developer Platforms.
Evaluating whether it’s the right thing for you
Jason Warner shared a great rule of thumb in his blog post:
“Stay as long as possible on Heroku and avoid having to deal with your own infrastructure. Then, get yourself an Internal Developer Platform. And build one when you are at an equivalent level of Airbnb.”
There’s not much more to add. An Internal Developer Platform makes sense from around 15 developers onwards.
How to start building your Internal Developer Platform
Internaldeveloperplatform.org is arguably the largest collection of materials around IDPs. There is a list of tools you can evaluate if you want to build an IDP yourself. If you are using an off-the-shelf framework, spinning up the first version is a thing of two hours.
Is this also possible for smaller companies that can’t afford such a platform team or don’t have the knowledge to build one?
The answer is simple: Yes. Modern frameworks allow you to get fully-fledged Internal Developer Platforms for a fraction of the heavy price-point those early pioneers were willing to pay.