Anatomy of an Internal Developer Platform

In the previous parts of this series, we’ve taken a closer look at the state of cloud-native software development, the proliferation of platform engineering as a response to cloud-native complexity, and how to approach implementing an internal developer platform (IDP). If you haven’t read our previous entries, we highly recommend going back and checking those out as well:

Part 1: The State of Cloud-Native Development

Part 2: Platform Engineering as a Solution to Cloud-Native Complexity

Part 3: Getting Started with Platform Engineering

Armed with an understanding of the purpose of platform engineering and how to approach implementing an IDP, let’s dive into what’s actually under the hood of an IDP.

What Does an Internal Developer Platform Look Like?

When researching and reading about platform engineering and IDPs, the concept of an internal developer platform can seem abstract and hard to grasp. So let’s begin with what the final product looks like.

An IDP is a streamlined, user-friendly control panel tailored to your organization's unique development workflows. Think of it as an enhanced version of Heroku's dashboard with features designed to cater to your development process.

Just like you use a code editor or IDE to write your code, the IDP becomes your go-to place for all things related to managing and deploying your applications. Imagine having a user interface where, with a single click, a developer can select the version of a service they want to deploy, specify the environment, and hit 'deploy.’ The IDP takes care of the rest, abstracting the complexities of deployment scripts, environment configurations, and infrastructure orchestration.

Moreover, an IDP can also provide immediate feedback. If you're familiar with using browser-based developer tools to debug your code, envision a similar experience but for your deployments. Log streams, service health metrics, or error notifications - all can be made available in real time on your IDP interface.

In essence, an IDP is a GUI-based development tool extended to cover the deployment and management of your applications, as well as infrastructure management and orchestration on the DevOps side. It's a platform that embeds infrastructure management into your day-to-day coding activities, making the process seamless and highly efficient.

Designing Your IDP Architecture

While the end result of implementing IDP is a streamlined and simple interface for your developers, arriving at the final product is quite a bit more complex than that.

While many tools could be integrated into an IDP, they can be broken down and clustered into five core modules.

‍

Developer Control

The cockpit for devs. It includes your IDE, a UI for visual tasks, and version control integration. Important considerations here are the smooth integration with popular IDEs and version control systems, the UI's intuitiveness, and the feedback loop's effectiveness when coding and deploying.

Integration & Delivery

Home of your CI/CD pipelines and image registry. It's essential to consider pipeline configurability, the ability to handle different build environments, and how well the system stores and retrieves container images.

Monitoring & Logging

The observability powerhouse. Make sure it has efficient log aggregation and smart, real-time metrics display. Can it do distributed tracing? Can it integrate with your preferred monitoring and alerting tools seamlessly?

Security

The gatekeeper of your secrets and identities. It's crucial to consider its compatibility with your existing secret management tools, the ease of rotating and revoking secrets, and the robustness of its access control policies. Does it integrate with your Identity Provider for Single Sign-On?

Resource Plane

The engine room of your IDP. This module handles everything from spinning up containers to managing data stores, networking, and other cloud services. Does it play well with your cloud provider(s) of choice? Can it handle autoscaling effectively and efficiently manage resources based on demand? Does it offer easy and quick setup of databases, caching, queues, and other services required by your applications?

Remember, an IDP should reduce the cognitive load for developers. Any friction in these planes could hinder that goal. So, keep it lean, make it mean.

If you’re building your own platform, be sure to check out internaldeveloperplatform.org for an overview of recommended tools for each module and component.

Follow the Thinnest Viable Platform Approach

Having understood the typical IDP architecture, let's move on to an important design philosophy that drives efficient and effective IDP implementation - the Thinnest Viable Platform (TVP) approach. Similar to how you architect the IDP around the primary user—the developer—the TVP method puts their needs and challenges at the forefront of platform design.

The TVP approach is like the MVP approach specifically for IDPs. You focus on the bare minimum - the thin slice - that provides value to developers while abstracting the underlying complexity. This tactic is all about taking baby steps, getting fast feedback, and iterating quickly.

Benefits:

• Faster time-to-value: Instead of building a massive, all-inclusive IDP from the get-go, you can deliver essential value to your developers quicker and refine as you go.
• Avoiding Overengineering: TVP helps prevent a 'white elephant' scenario, where you've poured heaps of time and resources into features no one uses.
• Better Adoption: A simple, user-friendly platform is more likely to be accepted and used by your developers.

Ignore TVP, and you risk wasting valuable resources and time on over-complicated solutions that may fall flat on user adoption. Your platform could become a labyrinth that deters devs rather than enabling them.

Applying TVP is pretty straightforward for anyone familiar with MVP and Lean Startup methodologies. The framework can be broken down into four simple steps:

1. Identify the pain points that your developers are facing in their daily workflows.
2. Choose the smallest set of features that can alleviate these problems.
3. Build, measure, learn - roll out your minimal platform, gather feedback, iterate, and expand.
4. Gradually add functionality based on actual developer needs and usage patterns.

Remember, with IDPs, as with most things in tech, simpler is often better. So, strip it down, make it lean, and let it evolve naturally with your team's needs.

The Platform Litmus Test

As we've just unpacked the TVP approach, you might wonder how to gauge whether your IDP development aligns with this strategy. Here is where a litmus test comes into play.

A litmus test provides a simple, unambiguous way to assess whether your IDP meets its intended goals while adhering to the TVP approach. It's a pragmatic tool to ensure that your platform doesn't bloat with unnecessary features or complexity but remains tightly focused on delivering immediate value to your developers.

Now, let's look at a concrete, actionable checklist that serves as a litmus test to ensure your IDP is on the right track.

1. Developer Autonomy: Your platform should empower developers to spin up their environments without getting entangled in red tape or waiting for other teams.
2. On-Demand Resource Provisioning: The IDP should facilitate immediate access to computing, data, networking, and services as required, mirroring the elasticity of cloud-native paradigms.
3. Abstracted Complexity: The system should smartly encapsulate the complexities of underlying technologies (like Kubernetes), offering a user-friendly interface for developers.
4. Speedy Application Deployment: Ensure your IDP ensures streamlined CI/CD pipelines and facilitates quick, reliable, and repeatable deployments.
5. In-built Observability: Without overloading your devs with complex tooling, your IDP should provide critical debugging and performance insights.
6. Security and Compliance: Your platform should still encapsulate security best practices despite being lean. It should also aid in meeting compliance requirements without developers intervening manually.
7. Practical, Not Perfect: Your platform doesn't need all bells and whistles at the start. Focus on what's immediately valuable for your developers.

Remember, the checklist serves as a North Star, guiding your platform's evolution. Be flexible and responsive to your developers' feedback, adapting the platform over time to serve them better.

Up Next: Building a Platform Team

Now that you’ve built a foundational understanding of the principles of platform engineering and how to approach implementing an IDP, we’ll next look at what makes up a platform team. Whether you’re looking to build or buy your platform, it is pivotal to understand what makes up a well-rounded platform team.

This way, you can make a more informed decision on building or buying your platform, as you will be better able to gauge if your organization can afford the main cost driver of building a custom platform - the talent - or whether you’re better off going with a PaaS approach.

‍