DevOps Burnout? Try Platform Engineering
Are we in the middle of the Great DevOps Burnout?
This report from Haystack says yes. Eighty-three percent of the 258 software engineers surveyed reported feelings of burnout from high workloads, inefficient processes, and unclear goals and targets. Only 26% of participants reported working solely on product development, whereas 74% reported working on operations tasks in some capacity.
While the sample size of the original study is small, the results are plausible. There is a growing conversation in the DevOps community about whether developers can or want to take on operations tasks. InfoWorld’s Scott Carey boldly proclaimed that “devs don’t want to do Ops.” This Reddit thread, started in response to Carey’s article, further illustrates how polarized developers are when it comes to this question.
This disagreement is a major problem for DevOps. As Aeris Stewart wrote in a previous article, “when developers in teams don’t agree on the extent to which they should, or can, do operations tasks, forcing everyone to do DevOps in a one-size-fits-all way has disastrous consequences.” Unfortunately, this is the approach too many organizations took when they embraced this cultural shift. And in this context, the main consequence is obvious: DevOps burnout.
So how did we get here?
Before 2006, most organizations followed a “throw it over the wall to operations” model of software delivery. Then Amazon CTO Werner Vogels changed everything when he announced that the company had implemented a “you build it, you run it” approach. Developers were then responsible for deploying and running their applications and services end to end. This quickly became the standard most engineering organizations built toward achieving.
Some organizations were able to navigate this cultural shift well. Others weren’t so lucky. More complex microservice architectures and technologies like Kubernetes, GitOps and Infrastructure as Code (IaC) became the industry standard. At the same time, developers became responsible for more of their applications’ life cycle and delivery workflows. Even simple tasks required end-to-end understanding of increasingly complex toolchains.
The growing complexity of technologies and architectures paired with the expectation for developers to be responsible for it all proved to be a crippling combination for many organizations.
Inspired by Daniel Bryant at PlatformCon 2022
The cognitive load on developers in setups like these is overwhelming and creates a variety of organizational inefficiencies. One example is what Humanitec’s 2021 DevOps Setups: Benchmarking Report calls “shadow operations.” Here, experienced backend engineers take on infrastructure tasks and help less experienced developers on their team with DevOps work.
This additional responsibility prevents them from focusing on developing features and delivering the most value to the company. The organization’s efficiency suffers as a result.
If cognitive load is the root of the problem, what is the solution? For many organizations, the key is platform engineering, designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud native era.
Platform engineers build what is often called an internal developer platform, which covers the operational necessities of the entire life cycle of an application.
Platform engineering tries to enable true DevOps by following a Platform as a Product approach to strike the right balance between maintaining developer freedom and finding the right level of abstraction.
Platform teams pave paths of least resistance, called golden paths, for developers using the platform, drive standardization by design and connect various parts of the toolchain together to build a coherent and improved developer experience. This enables self-service capabilities for the organization while abstracting away the unnecessary complexity that contributes to cognitive load.
Successful platforms result in less repetitive and manual work. They enable developers to do their jobs without having to learn all technologies in depth. This gives developers the confidence to deploy code independently and without fear of messing everything up.
Internal developer platforms are also associated with a lower change failure rate, which means fewer late-night shifts or weekend work for engineers being on call. It’s easy to see how all these benefits could help minimize the risk of developer burnout.
But building a platform does not make cognitive load disappear entirely. Syntasso’s COO Paula Kennedy rightly asks, “In addition to the developer experience, shouldn’t we also be thinking about the platform engineer experience?”
Kennedy explains that cognitive load often shifts from developers to platform teams, who have to find ways to incorporate a sprawling landscape of tools into golden paths.
The Great DevOps Burnout is real. Platform engineering might be one part of the solution, but we have to be careful not to burn platform teams in the process. That’s why the platform engineering community exists: to share expert insights and best practices so organizations can make the most of their transition into this exciting, new discipline.
Want to dive deeper into all things platform engineering? Check out our State of Platform Engineering Report.
