Weekly Rant: "Dev" Ops
This post is part of the “Weekly Rant” series
“We’re doing DevOps now: all sysadmins shall henceforth be known as ‘DevOps Engineers’.”
That’s a fake quote, obviously, but from I’ve observed and what has been shared with me by others has, it sure does seem to be what has happened at many companies. And it’s wrong on so many levels. But I won’t bore you with ramblings about interpretations of “DevOps” or SRE or platform engineering. That’s not what this post is about.
It’s about these fine gentlemen and occasionally, ladies. The rebranded admin that have consequently made efforts to learn how to do “development”. Which perhaps was the intent of this relabelling (if we pretend it was anything other than a misguided management move), but that’s a long, long road. And the ecosystem is not really helping, because it has not been particularly development focused, although that does seem to be changing. You’re just not going to learn how to write large bodies of maintainable code by hacking together some Bash and pasting it into a YAML file.
I’ve joined “DevOps” teams (something that should not exist), and Platform teams and only 1 out 5 knows how to write a half decent Python script. The “dev” part in these teams was never elevated beyond basic scripting. I didn’t blame them. Not only were they thrust into this involuntarily, it was never really expected of them. Loosely hacking together some 3rd party stuff works well enough 98% of the time, anyway, right?
But I’m noticing a clear trend here. There’s more and more “dev” in “DevOps” (and platform engineering), and it more and more starts to resemble “real” development. Deployment and configuration specifications have become so complex that markup just doesn’t cut it anymore. Even a DSL like HCL runs into limitations of maintainability at scale. It’s interesting to see how topics like modularity and even orthogonality, coupling and cohesion squeeze their way into modern IaC discussions at scale, even if many engineers fail to recognize them. We’ve already solved these problems, yet somehow we’re solving them again in a slightly different context.
Or perhaps not so slightly. Not everything is as easily transferable. The common business software design methodologies apply poorly to platform engineering. For example, I don’t think anyone will suggest you apply the blue book. And often much the design concerns are hidden in the tooling. For example Kubernetes controllers, it’s rare you’ll write your own, it’s even rarer you’ll bother with control theory yourself. Or with immutability as a concept, as it’s baked into IaC tools. In some ways this is no different from using frameworks and libraries in application development. It makes sense not to reinvent wheels. Someone has already done the thinking for you when it comes to much of the conceptualization, and for the most part that’s fine. And yet, the principle pain point, as it has always been, remains maintainability.
In the back of my ear I hear coworker talk of unit tests for Pulumi code. All of this is unavoidable.