A few days ago, Google released their yearly DevOps Research and Assessment report, an invaluable look at how the industry is performing.
I read the 120 pages so you don’t have to (but you really should).
There are a lot of things we could cover about DORA, especially how it relates to my engineering excellence and maturity activities. However, we’ll focus on something else today: for the first time, this year’s report has an entire chapter dedicated to Platform Engineering!
By the way, this is how the report defines a platform:
A platform is a set of capabilities that is shared across multiple applications or services. The platform's goal is to improve the efficiency and productivity of software delivery. A company may have multiple overlapping platforms, but we refer to these overall as “the platform”.
Let’s see if I can illustrate the points raised in the report with real-world experience.
A platform serves its internal users
We already knew it, but the DORA people really hammer on the fact that a platform’s main purpose is to serve its users (internal engineering).
Whilst there may be indirect benefits for the business, the whole point of running a “platform” is to support the engineers building the end product. Abstracting away as many obstacles as possible, and therefore increasing the efficiency of the Software Delivery Lifecycle (SDLC).
One way described in the report is to build Golden Paths.
Golden Paths are highly automated, self-service workflows that users of the platform use when interacting with resources required to deliver and operate applications.
(👴🏼Remember when we used to deploy Golden VM Images? 👴🏼)
I once worked for an organization that was running a multi-tenant cloud platform, serving dozens of engineering teams. To provide Golden Paths, we had to flatten the playing field and standardize the tech stacks across the organization.
In our case, taking into consideration the existing skill set, 60%+ of our applications were Ruby microservices with a database and Memcached. This would be our first golden path.
Pipelines and documentation would then be created to make the entire process self-service.
Of course, teams were also entitled to use a different stack, but they would not benefit from the support of the Platform Team.
A Quick Look at the Numbers
The Platform engineering section mainly covers the productivity and performance impact of having a Internal Developer Platform.
I gathered all the results of the survey below - it is surprising to see negatives of platform engineering, but I appreciate the transparency of the report. Let’s dive deeper 👇.
Platforms Boost Productivity & Performance
There is an undeniable positive effect of running a platform or an internal developer platform (IDP) for individual contributors (+8%), teams (+10%) and the overall organizational performance (+6%).
Moreover, the report highlights that when there is a dedicated team managing the platform (and providing support) the team’s performance increase further by 6%.
If you needed data to convince your CTO to build a platform, look no further!
An interesting find is the consistent benefits of the platform over time. The J-curve below (which I have redrawn for clarity) shows three phases:
The Quick-Wins: the immediate benefits of using the platform. For example, a clean CI pipeline.
The Hard Part: A slight regression in performance growth. This is the core of what we do, solving the right problem, hiring the right people, setting the right processes. It’s hard and takes time.
Maturity: An accelerating performance increase. The hard work and the culture of continuous improvement are finally paying off.
The Not So Great
The findings also highlights three areas of negative returns:
A decrease in throughput, meaning things are moving less quickly through the process. A possible explanation raised in the report is that automation allows more functions to be a part of the pipeline (e.g., QA, Security Testing, Performance Testing)
A decrease in change stability seems to strongly decrease when using a platform. An argument raised is simply that the platform allows for faster iteration and a higher risk tolerance by the team.
Finally, there seems to be a correlation between using a platform and an increase in burnout. That’s a surprise to me. Let’s dive into it more.
The Burnout Correlation
Whilst the report can’t draw a direct connection between using a platform and burnout, they indicate that both change stability and using a platform come with higher levels of burnout.
Without paraphrasing too much, one of the plausible reason raised is that organizations that already have these issues tend to build platforms to resolve them.
Because I wasn’t satisfied with the analysis, I went down the rabbit hole and dug out the specific survey questions mentioning burnout. Surveyed users were asked to rate how much they agree with the following:
I am indifferent or cynical about my work.
I feel burned out from my work.
I feel like I am ineffective in my work.
My feelings about work negatively affect my life outside of work.
These are not useful, so let’s use our experience to get to the bottom of this.
My guts feeling tells me an under-estimated possible reason of burnout is long-term exposure to over-complexity.
Platform = Abstraction = Complexity → Burnout
In my experience:
Abstraction leads to increased complexity of the **overall** system
In other words, building Golden Paths and abstracting away specific obstacles for a given process, makes the rest of the system more complex. This extra complexity can show up in various ways: in the maintainability of the system, in its dependencies, in its architecture.
It takes us back to The Commitments of the Cloud Platform, where we understand the platform is not set in stone and must evolve, as well as the ways of working.
When the ways of working associated with a platform in calibration rapidly change the day-to-day responsibilities of engineers, frustration accumulates.
This is why a cultural transformation must drive the platform engineering initiative, not the other way around.
Anecdote
Eight years ago, my organization started “shifting left”.
The first thing that shifted onto the developers’ plate was the writing of Dockerfiles. A year later, Gitlab CI pipelines. A year after that, part of the Kubernetes manifests.None of it was easy. It was only possible thanks to a user-centered approach and overwhelmingly supportive communication and training.
Let’s be honest with each other. Share your feedback. Raise any mistakes I made. Point me to great resources. Engage in conversations. Let’s be friends.