Why Do DevOps?

Because DevOps is a force multiplier. It provides the historic opportunity to connect all phases of IT, from the aspirations of businesses to the imagination of designers and architects through the code artistry of developers and the meticulous monitoring and care of production services. Forget “full stack”; DevOps embraces the complete stack and all the processes that surround it. Overall, DevOps seems to accelerate and optimize the whole lot, giving the power and levers to “improve the way things are done.”

To be sure, DevOps also includes all the frustration that attend “mechanic work” and quite a lot of “herding cats.” Invariably-recalcitrant people, processes, cultural expectations, and tools must be made to play nicely together. There are silos to be worked around, historical band-aids to be improved, and constant time pressure. You get blamed for everything that doesn’t work, no matter who picked it, wrote it, owns it, or currently runs it—regardless of how long it’s been a problem.

“Other than that, Mrs. Lincoln, how was the play?”

I admire, learn from, and take solace from the travails of other difficult fields such as fire-fighting, motion picture production, and America’s get-to-the-moon program. When the stakes are epic and there are dozens or hundreds of problems ahead of you every day, nothing suffices but getting into the fight. Fight high and low, strategic and tactical, left and right. Focus on *this* problem right in front of you the next hour, then when that’s tamped down, move on to the next dozen things that needed fixed two weeks, months, or years ago. And keep enough in the tank to fight the long-term, systemic problems that no one else has imagined can yet be fixed.

The frustrations of the job are real. That notwithstanding, DevOps epitomizes the power of integration, networked resources, and a positive opportunity to make things right. Even the gnarliest knots can be untied, if you’re systematic and relentless. That constant challenge is matched by the constant opportunity to fix, to improve, to create leverage.

“Once more unto the breach, dear friends! Once more!”

Isn’t DevOps Just Glorified Systems Administration?

Uh…no. No, no, no! If that's how you’re doing DevOps, you’re doing it very, very, OMG! so very wrong.

The whole point is getting out of the reactive, repetitive, labor-intensive work of IT-that-was. To convert skills into processes, automate gratuitous labor out of the equation, and bridge the former chasm between software and systems, between dev and ops. The tools we use—the containers and clouds, the VMs and CI/CD pipelines, the monitoring and the orchestration engines—they’re often talked about as through they are core of DevOps. They are not. They are simply the practical means to achieve integration goals. If you must make DevOps about a thing, that thing should be the evolving of infrastructure and processes into software, so that code, instrumentation, monitoring, and alerting can stand in for what was once repetitive human labor and constant attention.

There is a lot of mechanic work involved. There are also a lot of incidents to field and debug, making you first-responder and trauma team through rehab specialist. But you’d better be a developer at heart, to build better structures. A bit of a data scientist, to understand the indicators and trends. And an architect, to design features and processes that work at scale. And at least a semi-advanced cat wrangler, to get all the disparate people and groups aligned behind the way things should be done. And, and, and…

It’s holistic, challenging, and requires polymaths. Anyone who feels right and justified reducing DevOps to fancified, shmancified sysadmin work—that’s someone who’s only seen it done poorly.