As the number of applications and interconnected systems grow in an organization, the complexity of the developer role increases. Companies with a traditional development culture expect developers to describe their infrastructure needs, design highly available applications, map business needs to software solutions and write good code. New applications have to fit in with the existing stack of applications. The cognitive load of developers increases to the point where it severely affects productivity. This is a challenge that spotify and many other companies have faced in the last decade. To help developers cope with cognitive load many companies started experimenting with internal developer platforms.
An internal developer platform (IDP) is a set of self-service resources. These resources help developers build and operate applications that meet the standards of their organization. Typical self-service resources in IDPs are:
- A standardized way to build a new microservice.
- A centralized platform for technical documentation.
- A set of tools for monitoring the performance of applications.
Standardizing how microservices are built and abstracting away abundant infrastructure details can dramatically reduce the cognitive load for developers. While abstracting away infrastructure is great, it is important that developers have sufficient insights to the infrastructure to debug their applications in the case of failure. By equipping the IDP with monitoring dashboards, network graphs and a centralized solution for analyzing logs developers can get the insights they need.
Organizational implications of internal developer platforms
When deciding to build an internal developer platform the organization must allocate a team responsible for maintaining and developing the platform. The platform team should treat the platform as a product that developers consume. In order to communicate the goal of the platform throughout the organization and prioritize tasks for the platform team, a product owner should be assigned. Furthermore, the product owner conducts regular interviews with platform users to recieve feedback and plan improvements.
The platform team is one of four fundamental teams Matthew Skelton and Manuel Pais’ describe in their book team topologies. They elaborate on how to organize business and development teams for fast flow. According to team topologies all teams should be mapped into one out of four teams:
- Platform teams with the purpose of enabeling stream-aligned teams to deliver work with substantial autonomy.
- Stream-aligned teams with the purpose of building and delivering customer or user value as quickly, safely and independently as possible.
- Enabling teams with the purpose of helping stream-aligned teams adopt new frameworks, practices or technologies.
- Complicated-subsystem teams with the purpose of building and maintaining a part of the system that depends on specialist knowledge.
There are many success stories about adopting the organizational structure described in team topologies. However, building an IDP and creating a platform team can generate a lot of vaule without adopting the full team topologies structure. After all, the IDP is about making developer lives easier, and that comes in handy regardless of team structures!