Author: Mike Vizard

Every few years, sometimes every few months, someone declares DevOps dead.

If that sounds familiar, it should. We’ve been hearing some version of this refrain for more than a decade. DevOps has failed. DevOps is broken. DevOps has been replaced by insert latest shiny thing here. And yet, every time the obituary is written, DevOps stubbornly refuses to cooperate.

Which is why I want to talk about DevOps for what it really is: Not a failed movement, not a completed project, but a never-ending story.

This latest round of conversation was sparked by a smart, provocative blog post by Charity Majors, titled “You Had One Job: Why Twenty Years of DevOps Has Failed to Do It.” Charity’s piece struck a nerve, and rightly so. She articulated a frustration many practitioners feel: after two decades, why are so many organizations still struggling with reliability, ownership, and operational excellence?

I responded with a piece of my own on devopsy.kinsta.cloud, “DevOps Didn’t Fail — We Just Finally Gave It the Tools It Deserved.” That article wasn’t meant as a rebuttal so much as a riff—an acknowledgment that Charity’s critique landed because it came from lived experience, not marketing copy.

What followed was the best part. A thoughtful LinkedIn discussion unfolded. Charity herself joined in. Others shared their own experiences. And instead of the usual food fight, something more useful happened: reflection.

And that reflection led me here.

Let’s start with an uncomfortable truth: DevOps has never been perfect. Anyone who tells you otherwise is almost certainly selling something. DevOps didn’t magically fix broken incentives, eliminate silos overnight, or turn every organization into a high-performing engineering culture.

But it did work.

Not always cleanly. Not always consistently. But it worked well enough that entire careers—mine included—were built on it. Teams shipped faster. Failures became more visible. Conversations changed. Responsibility shifted closer to the people doing the work.

And all of that happened long before we had today’s tooling, platforms, and automation layers.

We did DevOps with what we had.

Which is why I bristle a little when I hear that DevOps “failed.” Failed compared to what, exactly? A theoretical ideal? A vendor slide deck? A world where incentives, culture, and humans behave rationally all the time?

DevOps didn’t fail. It endured.

Part of the reason DevOps has survived — while so many other movements have flamed out—is that it never locked itself into a rigid definition. Early on, people were deeply uncomfortable with that. There was no single manifesto that everyone agreed on. No authoritative checklist. No certification that proved you were “doing DevOps right.”

At the time, that felt like a weakness.

In hindsight, it may have been DevOps’s greatest strength.

Because while the industry argued about definitions, DevOps kept evolving. It attached itself to cloud native technologies. It embedded into SRE practices. It became foundational to platform engineering. It absorbed security. It grew up alongside Git. And now, inevitably, it’s entangled with AI.

DevOps doesn’t compete with new ideas. It absorbs them.

That adaptability is not accidental. It’s the direct result of DevOps being less about tools and more about people. About how humans collaborate, share responsibility, handle failure, and learn from it.

As humans change, DevOps changes.

That’s why a line often attributed, in spirit if not verbatim, to Andrew Clay Shafer has been resonating with me lately: we may finally be getting the DevOps we deserve.

Not the DevOps we were promised.
Not the DevOps vendors marketed.
The DevOps we deserve.

For the first time, the tooling is starting to catch up to the intent. Observability platforms that reflect how systems actually behave. Automation that reduces toil instead of adding ceremony. Security tools that integrate rather than obstruct. Platforms that support teams instead of dictating process.

But let’s be clear: Better tools won’t save DevOps if we forget what it was always about.

DevOps was never a destination. It was never a product. It was never meant to be “done.”

It was—and remains—a response to how humans build and operate systems in an increasingly complex world.

That’s why every time someone declares DevOps dead, it sounds less like analysis and more like frustration. Or worse, a sales pitch. Email didn’t die. The web didn’t die. Agile didn’t die. They changed. They adapted. They outlived their original definitions.

DevOps is doing the same.

Yes, there are blemishes. Yes, progress has been uneven. Yes, twenty years in, we should be further along in some areas.

All true.

But in an industry obsessed with reinvention, DevOps has shown something far more valuable: resilience.

It has stood the test of time not because it was perfect, but because it was human. Because it allowed teams to interpret it, adapt it, and make it their own. Because it accepted that the DevOps you get is, in many ways, the DevOps you deserve.

Which brings us back to the beginning.

DevOps isn’t dead.
It isn’t finished.
And it certainly isn’t done evolving.

It’s the never-ending story.