The First Rule of DevOps is you do not talk about DevOps

I’ve been giving a lot of advice on DevOps adoption lately. Everyone wants to know what tools to buy, how to reorganize their development teams, how to reorganize their operations teams, how to merge development and operations, or how to automate their builds. Their tests. Their deployments. However, everyone seems to be missing the primary point of DevOps: DevOps is all in your head.

I don’t mean it’s fake or misguided. This isn’t going to some rant about how DevOps is some horrible idea and that silos must continue. I’m not Yegor Bugayenko, arguing that ORM is bad in favor of smart objects. I mean that it’s not about a particular process or any tools. There is no specific organization. It’s all about how you go about solving problems, and it’s about communication.

Let me explain. The primary change all the DevOps tools and processes introduce is simple communication. Yes, they give you automation. That’s a given. I mean, come on, we work with the most versatile automation tools in the world. It’s what computers are for. So we’ll set that aside, because while automation is required for DevOps, it’s not the goal. It’s what you should be doing anyway. Everything should be automated. Always.

The whole point of DevOps is communication. That doesn’t mean talking. It means that when developers have a release candidate for deployment, the communication to operations should be simple. This can be done in a variety of ways. You could standardize on Docker containers, you could manage all deployments with Jenkinsfile, you could write good documentation and make sure the artifacts will work as documented, or you could hire an army of interns to sing ballads of how to deploy. It doesn’t matter. The point is that when Development has a deployment artifact for Operations, Operations shouldn’t have to ask what to do with it. It doesn’t matter how you get them that information. Carrier pigeon you resurrected from DNA you found on your grandfather’s World War I uniform. No one cares. Just make sure it works before you waste Operations’ time. Make sure they can understand what to do with it.

This is one reason why automation is so critical. However, I think automation is just the red herring everyone is paying attention to while the workhorse gets the job done. That red herring didn’t do anything notable for the team. Velma, the workhorse, is the one who got stuff done. In this extended metaphor, standards is our Velma. You simplify the communication by removing the need to communicate very much. Ever see an old married couple who has gone past just finishing each other’s sentences to not even talking anymore? It should be like that. Define a standard way of how to package and configure applications so Operations doesn’t have to ask.  They just know

Which brings me to the main reason DevOps is all in your head. It’s all about defining complete solutions. Defining standards to simplify and facilitate communication is just such a complete solution. Which is what DevOps is about: defining complete, reusable solutions for all your problems. A good solution is one that can be automated. So don’t worry about the tools, or the process. Focus on solving your problems permanently and in a way that can be reused for other problems.

About the Author