An Internal Developer Platform (IDP) solves many problems the DevOps culture experiences today. Many Ops teams use a ticket-based approach. They often get buried under repetitive tasks, such as spinning up environments and databases, making changes to existing deployments, or manifests maintenance.
These delays have a direct impact on the company’s velocity, adaptability, and lead time. Other than that, Ops teams can’t continue to manage tooling and processes without becoming a bottleneck. This impacts job satisfaction.
Yet, many developers praise Ops teams for their “automate everything” mentality. I’ve seen Ops guys that could trigger a deployment by tapping on their Apple Watches. This example displays the strength and creativity of Ops teams.
So, why would an Ops team not automate the above tasks and build an Internal Developer Platform? The answer to the question here is, they would love to. But many Ops teams don’t have enough engineering power to tackle those tasks or even improve their workflow.
That’s unfortunate as Internal Developer Platforms offer many benefits, for both Developers and Ops teams:
- Unified deployment workflows within teams and across environments
- Developers become self-serving
- Lower learning curve and faster onboarding for Dev and Ops teams due to lower cognitive load
- Easier experimentation
- Increased visibility (real-time stats, logs, debugging) and troubleshooting capabilities
So, what are the core components that make up an Internal Developer Platform? This blog post explains each of these five building blocks to better understand the key concepts behind Internal Developer Platforms.
Fundamentals of an Internal Developer Platform: The five building blocks
When speaking about an Internal Developer Platform, there are five core components that should be addressed:
- Application Configuration Management
- Infrastructure Orchestration
- Role-Based Access Control (RBAC)
- Deployment Automation
- Environment Management
Let’s explore each of these components and define who uses which ones.
Application Configuration Management
There is one underlying pattern in the way teams build those early platforms. It usually all starts with finding a new way to deal with Application Configurations. This search leads to the first building block of every Platform: Application Configuration Management.
Unstructured scripting is the culprit of pressure on Ops teams.
To find an answer to the day to day problems that put pressure on Ops teams, you will likely identify unstructured scripting as the core evil.
It’s correct that unstructured scripts aren’t only hard to maintain, they are also a blocker when making your setup self-serving for developers. This means, as long as you keep on letting everyone write configs the way they want, you won’t improve your company’s velocity and won’t be able to scale.
So how do you take control of your zoo of scripts?
The answer is to introduce baseline configuration templates. The ops team sets those templates that provide default application configurations.
As developers spin up applications, they can apply changes to those defaults. Note, they can only make changes to the defaults, no “surprise” changes are possible. An Internal Developer Platform wants to prevent this from happening by standardizing configurations explicitly.
At deployment time, the Internal Developer Platform creates the final set of configuration files by applying the changes made by the application developers to the defaults.
Now, the Platform creates those manifest files at every single deployment. Therefore, the Internal Developer Platform holds a clear trace of all changes from deployment to deployment. This trace forms the basis of the “Deployment Automation” component. This component will be covered later in this article.
An application is more than plain configurations. It also includes many dependencies and infrastructure requirements. An Internal Developer Platform has to provision these dependencies into a particular state. On top of that, you want the Platform to connect those dependencies to your applications.
Therefore, Internal Developer Platforms had to find a way to put resources (DBs, file storages, or clusters) into the right state if an application that is being deployed requested them. This problem is where the next core component comes into play: Infrastructure Orchestration.
Infrastructure Orchestration describes a way of connecting resources to the platform and triggering their creation. For instance, you want to create a new seeded database when developers request a new QA environment for testing a feature.
In this example, the platform would follow the configured “recipe.” That could be:
- Provision a namespace in a managed Kubernetes cluster
- Dynamically spin up a PostgreSQL database
- Configure a DNS entry to point to the new QA environment
Automation is key here to reduce pressure on Ops when developers want to spin up a new environment.
At this point, you have a raw version of the Internal Developer Platform. The IDP can deal with Application Configuration and Infrastructure Orchestration.
We now need to add Deployment Automation to string together both components.
Deployment Automation allows the individual developer to:
- Add the workloads the app should contain
- Apply changes to the default configurations, if needed
- Define what type of environment the IDP should spin up
The Deployment Automation component makes sure to put the right resources into the correct state. Furthermore, this component wires the applications’ required dependencies.
And voila, the app is up and running.
Let’s add one more component: Environment Management.
Applications running on IDPs usually follow the 12factor-app conventions to parameterize environment variables. Because of such parameterization, manifests are environment independent. The platform puts the infrastructure automatically into the correct state and spins up the environment. It also lets you copy configurations to new environments.
Using Infrastructure Orchestration, you can configure which resources run with which environment type. This freedom unleashes a whole bunch of new functionalities. Developers can autonomously spin up new environments for QA, integration tests, or feature branches.
They can promote a hotfix branch to production, and it suddenly doesn’t matter whether staging is ahead. This detail is compelling as you don’t have to worry about handling conflicting environments. An Internal Developer Platform takes care of this.
For the developer, it becomes irrelevant what resources those environments consume. They can select an environment type and the Infrastructure Orchestration component makes sure that everything is set up as configured. So one environment might be running in AWS using RDS, whereas the next one runs on GCP using Cloud SQL.
Role-Based Access Control (RBAC)
In the enterprise context, many teams put RBAC in place to manage access on a granular level. You can assign everybody in your organization one or more roles. This approach is much more scalable than assigning individual permissions.
In short, it’s a must-have component to improve the robustness of your Internal Developer Platform.
Should you build your own Internal Developer Platform?
Building your own Internal Developer Platform requires a lot of time and effort. Even though you manage to build such a platform, don’t forget about maintenance costs.
Yet, elite teams at companies such as Github, Airbnb, and Spotify have built their Internal Developer Platforms. They realized that it’s not an easy task to build a Platform alongside your product or services.
Therefore, you can opt for an out-of-the-box solution that can provide you with an Internal Developer Platform to connect your tools and infrastructure. The Humanitec platform can do all of this via the UI, API, or CLI.