There’s been a boatload of blogs, Twitter threads, and articles published over the last several months musing over the question of whether DevOps as we know it is withering away into the archives of O’Reilly oblivion. It’s an interesting (and often amusing) mix of commentary that reflects conflicting notions about what DevOps actually is.
For example, in a blog entitled “DevOps ain’t dead but… we gotta talk,” Mallory Haigh, Director of Customer Success at Humanitec, wrote, “DevOps isn’t dead by any means. The field is still evolving…But the picture isn’t perfect. Organizations often do DevOps in problematic ways, and engineers suffer the fallout. From causing daily cognitive load to permanent shellshock, many DevOps setups are just plain broken.”
In other words, DevOps as a discipline is often misunderstood. While some companies just hire a DevOps engineer and believe they’re “doing DevOps,” they don’t realize that DevOps is not actually a role in and of itself. Truly effective DevOps, Haigh says, is composed of a culture and methodology wherein developers better understand the infrastructure for which they develop. In her characteristic sardonic style, she writes, “They commit to a mistaken ideal by declaring, ‘You build it, you run it—and you just have to suck it up and deal with it.’”
Gartner analyst Lydia Leong, in an article on CloudPundit, sizes the situation up a bit differently. She writes that developer responsibility and/or control over infrastructure shouldn't be an all-or-nothing proposition. ”Responsibility can be divided across the application life cycle…without necessarily parachuting your developers into an untamed and unknown wilderness and wishing them luck in surviving because it’s not an Infrastructure & Operations (I&O) team problem anymore.”
Leong says that the solution lies in finding the right balance between “Dev” and “Ops” in DevOps. She notes that this sweet spot will be different for every organization. It’s a delicate equation that requires conversations about “autonomy, governance, and collaboration, and no two organizations are likely to arrive at the exact same balance.”
Taking the issue a step further, Sid Palas’ widely quoted Twitter thread reads, “Most developers don't like dealing with infrastructure. They want to write code and run it somewhere but don't care much where that is.”
An InfoWorld article penned by managing editor Scott Carey, entitled “Devs don’t want to do ops” prompted a raucous Reddit romp that continued the debate: “The article is kinda right? I mean, most of the devs I worked with didn't want to learn ops, they were just using the ops role recklessly. For example setting PHP memory limit to -1 and f--k it.” Another Redditor wrote, “Who cares what some disgruntled devs want. The author of that book was probably talking about the fact that devs don't want to be concerned with the infrastructure itself but would handle the engineering aspect of it through software.”
While my personal opinion is that Reddit is the cesspool of the Internet, the latter comment is where the issue actually starts to get teeth. Because maybe the root of the problem with DevOps isn’t about whether developers want to “do” ops. Maybe they’re just overwhelmed. Maybe the problem that needs addressing is that most companies are simply doing DevOps wrong.
Haigh’s take is that the DevOps methodology is morphing into an approach that focuses on enablement and engagement, so IT teams can grow within their infrastructure and cloud-native environments in a sustainable way. And that, she says, is where platform engineering comes in.
Is platform engineering DevOps 2.0?
Where all the articles, threads, and posts seem to converge (if you scroll far enough), is that to truly fulfill the DevOps “agenda”—ensuring that developers are writing software that runs well on its intended infrastructure—companies should be building standard infrastructure and self-service interfaces. Providing developers with digital platforms that deliver software at scale would empower them to build high-quality applications without becoming operations experts. Who would build and maintain these platforms? Dedicated platform-engineering teams.
In August of last year, Gartner put platform engineering on its Gartner Hype Cycle for Emerging Technologies, defining it as “the discipline of building and operating self-service Internal Developer Platforms (IDPs) for software delivery and life cycle management.” (Side note: platform engineering actually predates DevOps, having emerged in the early 2000s.)
If you return to Sid Palas’ Twitter thread, you’ll start feeling a sense of dejà vu. “The challenge then becomes moving up the control axis without exiting the Developer Comfort Zone. This is where platform engineering comes into play!” he wrote. “Platform engineers build the tooling and abstractions around the complex infrastructure configurations such that most software engineers don't need to worry about those aspects as much. The resulting system is what is known as an ‘Internal Developer Platform.’ (IDP).” Mic drop!
If you feel a bit dizzy, join the club. There are a wide array of personalities chiming in on this conversation and as many ways of slicing and dicing the same issues.
That said, let me return to answering the question I posed in this post’s headline. In my quest to decide whether to run out and buy a new black dress to mourn the passing of DevOps, I considered the entire range of opinions, from the experts at Gartner to the rabble-rousers on Reddit. At the end of the day, the conclusion seems clear: no, DevOps isn’t dead. It’s just growing up.
Top comments (0)