The rise of the developer platform
I have recently seen quite a few articles and talks covering why organizations are aiming at implementing a developer platform to help speed up the adoption of microservices within their organizations but before we get started on discussing what a developer platform is, the developer experience and productivity on Kubernetes, and how different teams are working through it, let’s define some common ground:
- Kubernetes is the de-facto solution for running cloud-native systems
- Enterprises are either starting or scaling their cloud-native initiatives where Kubernetes is the centerpiece for service orchestration
- Adopting Kubernetes is like adopting an elephant as a pet.
Working with organizations on both ends of this journey, in most cases, it’s easy to see that embarking on this journey was a sound decision from an engineering standpoint. Kubernetes is a complete platform designed in a generic way that makes it supposed to meet every possible use-case that your organization might need, right?
While the point above is valid, the reality is that users quickly realize that K8s adoption is not just about the operations and infrastructure teams running clusters while development teams run services and pods in these clusters.
Developer productivity into play
It’s not uncommon to see discussions around how the complicated abstractions and interfaces introduced by Kubernetes have hurt the developer experience and productivity as the load for the average developer who lacks deep K8s expertise will increase when you adopt K8s at scale. Because of that, we see many teams concluding that K8s should be an implementation detail and not the end goal.
That conclusion took many teams down the path of exploring different routes to improve their developer experience and productivity while still allowing them to move towards a new architecture. The goal is to enable developers to focus on shipping code and applications and operations teams to focus on control. So hence, so many discussions starting around implementing a developer platform.
Let’s see why developer productivity is so important and why organizations and teams are thinking about it:
According to one analysis, an engineer engaged in purely non-innovative activity destroys nearly $600K in employer market value. On the other hand, the average engineer, working on a combination of maintenance and innovation activities, adds $855K in market value to their employer.
A recent global survey done by Stripe asked developers to rate the productivity of their engineering teams on a scale of 0-100%, and the average response was a surprising 68.4%
While this seems like a high number, let’s flip it around: (100% – 68.4%) / 68.4% = 46%.
This means that developers could be nearly 50% more productive than today.
Defining developer platforms
To address this point, teams started looking at implementing a developer platform to abstract away cumbersome infrastructure-related decisions for software developers, easing the operation burden on overstretched DevOps teams. One way to define a developer platform would be:
The developer platform is the foundation of self-service APIs, tools, services, and support that enables developers to write code quickly, with the required automation to support different deployment methodologies, monitoring, and more related to the management of the application.
Going further on its definition, for this platform to be successful across the organization, I believe the following definition should also be part of it:
To be adopted across the organization, the developer platform should plug into the infrastructure of choice and enable DevOps teams to increase the reliability, predictability, compliance, and security of the microservices platform.
Bringing these values together will shift the work from creating and managing a never-ending set of YAML files for each service (deployment, ConfigMap, service,…) per environment (dev, test, production) to development teams focused on running their code without even knowing that there are K8s clusters under the hood.
This approach allows your team to focus on delivering applications rather than being tied to infrastructure-related work. We have seen this saving hundred, if not thousands, of hours of work for engineers while enabling good practices and governance around security, logging, debugging, and more.
Implementing a developer platform involves team interactions and clear definitions of roles and responsibilities. Otherwise, you may fail to address questions such as “Who is responsible for x” or “Who is affected by y.” Having clarity of purpose and understanding the responsibilities and behaviors are crucial to success.
Getting started
There are many ways to start the adoption of a developer platform. Taking a team-centric approach, some of the steps you can start with are:
- Understand the current workload by asking your developers if they genuinely understand how to build, deploy, manage, and support their applications at scale.
- Plan for the platform to clearly understand how your organization is currently operating and map the missing pieces for a developer platform.
- Define the ownership model, setting the right expectations regarding who is responsible for what, who should be involved from the beginning, and how to evangelize the developer platform within your organization.
The exercise above will help you succeed in implementing a developer platform and give you insight into how your teams interact today and any misaligned expectations that create friction between the different teams.
In the end, a developer platform will help you drastically increase the developer productivity and experience in your organization while improving controls and governance. Next, we will cover some of the challenges and opportunities organizations see when implementing their developer platform across development and operations teams.
Resources:
Sign up for Shipa Cloud: https://apps.shipa.cloud
Shipa home: https://www.shipa.io
