Internal Developer Platform (IDP)
As a manager, our roles mainly involves people and process. One of my latest improvement work is about process improvement around Internal Developer Platform (IDP). As a Platform squad product managers, just want to share my thoughts about this topic. Mainly about how much of a game changer in can be compare to the existing workflow for our developers.
Background
This concept isn’t something new to begin with. As a developer, you probably have already done it somewhere, just not as organize and properly plan out. For those that have not heard of this before, read more about it from here.
The term “Platform” used to be an alias to SRE. Well, not anymore. Ever since the introduction of Team Topology (read more separately), the definition of platform extended to serve the stream-align(Product) team. Which is to reduce cognitive load and improve on the Developer Experience (DevEx). I also think that with the rapid improvement on the Cloud Provider, there are way more tools and automation to manage the infrastructure, that now the platform teams has the capacity to do more.
IDP Objective
That bring us to IDP. To put in simple, the goal here is to create a place for engineers to share silo components into a searchable information that is easy to consumed by other squads. In IDP, this is call service catalog.
In my way of putting it, the list has to be searchable and browsable. We don’t know what we don’t know. Because not everyone knows about the latest development within the company. By being able to search about keywords, and then being able to browse for relavent information be it a library, runbooks or best practices. We empower the engineers to connect the dots by reusing existing knowledge.
Another objective of IDP is to make self-serving tool easier and secure to use. As engineering practice matured within a company, a lot of repeatable task can be time consuming. Say for example, creating secret key and key rotation. All these aims to reduced the stream-align cognitive load while ensuring the engineering operation remain compliant.
Service Catalog Options
If fact what is shared in above already has tools that is exist in the market. First object can be achieve with the these list of platforms (developer portal)
| AutoCloud | Automatically generate secure Terraform code for anything |
| Backstage | An open platform for building developer portals |
| Compass from Atlassian | Developer experience platform and service catalog |
| configure8 | An enterprise-grade developer portal solution |
| Cortex | Build reliable and innovative software at scale |
| OpsLevel | All your services, all in one interface |
| Port | A developer portal for all your services,software & resources |
| Roadie | Backstage as a service: adopt OSS without the overhead |
Atlassian Compass
Since my company is a pro-Atlassian advocate, without doubt we opt for Compass. Our first impression of the tool is nice and promising. It takes awhile to read and understand the concept they introduce, like additional features such as “scorecards”.
However, for you to fully immerse with this tool, we need to migrate our existing repos and documents that works with Compass. Besides that, among the managers, we had quite a few conversations about the scorecard metrics to use.
End Note
As of this writing day, we have not really rollout the IDP yet. But, it seems promising that this tool is able to solve one of the challenge we faced, which is the accountablility and the work synergy among the squads.
There are still tons of work need to put in to make it friendly to use, nevertheless, we have started our journey to IDP. Hope that I have the time to remember writing the update for this journey. Dear reader, what is your engineering story?