K8S

For the third time this month, I’ve come across a company that supposedly already has Kubernetes, but all processes, including CI/CD (it’s always Jenkins, for some reason), rest entirely on Ops, who have been renamed DevOps to be “modern.” In essence, this is no different from the classic Dev and Ops towers separated by a fence, with the same old problems: the need to immerse Ops in project specifics, a high volume of Dev <-> Ops communication, a battle for Ops priorities, Ops becoming a bottleneck, and so on.

And it’s frustrating. What stops you from giving some power back to the development teams? They are professionals. They know how to build their application, how to test it, check its health, calculate metrics, run it (at least locally), migrate data, which ports need to be open, what URLs the application has, and so on. Why take all this knowledge that already exists and run it through additional communication with a separate team, risking that something will be forgotten, and then teaching the Ops team how to work with this specific application? It’s simply incredibly inefficient.

Docker, K8s, serverless, no-code, and so on are not about new utilities in old environments; they are about a new way of dividing responsibilities. And there’s no sense in not taking advantage of that.