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.
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.
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.
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.
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.
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?
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?
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.
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:
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:
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.
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.
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.
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.