How to Fulfill the Empty Promises of DevOps

Alcohol and cell phones. Toothpaste and orange juice-flavored ice cream. A rich guy and his 18-year-old love interest. Some things in life are better apart than they are together.

Could the same be true of Dev and Ops?

In orthodox DevOps mythology, we are led to believe that the roles of developers and operations will eventually blend into one with no visible gap between them. Instead of the two camps sitting on the far side of a field, they’d pitch their tents side-by-side, learning from one another. Ops learning about Dev, and Dev learning about Ops. Eventually, they’d all be in one tent: development and operations engineers participating together in the entire service lifecycle, from design through the development process to production support.

Well, as we all know, that hasn’t really happened. Like communism before it, the theory and practice of DevOps haven’t always come together the way we expect them to.

What we are now seeing is conflict between the camps. On the one side, we have developers who are paid to deliver change. The organization relies on them to respond to changing requirements, so they’re called upon to come up with new ideas and innovations. That change is anathema to the ops team. They are paid to make certain revenue generating services keep on generating. That the lights stay on. Change to them undermines stability and means revenue generation might grid to a halt.

We all want an environment where code sails from desktop to production quickly and easily. The power of having such a rapid feedback loop for customers and developers alike is the technological equivalent of El Dorado, the fabled city of gold. But just like the folly of searching for myths, DevOps in practice often leads to more disillusionment than mountains of treasure, especially when it comes to scaling those practices.

So are Dev and Ops better together or better apart? To find the answer, think back to the original goals you set for DevOps. You wanted end-to-end automation: the ability to develop, release, and manage applications faster than before.

What you ended up with, however, was dev automation: the dev and test part of your application lifecycle now runs like Usain Bolt in Rio.

But what about your operations team? Do you push ops into adopting DevOps (often against their will) and make them work in the same sandbox as the dev team? Or do you give them their own set of automation tools that pick up where DevOps tools leave off? It’s an intriguing prospect.

So is this: does it really matter that much if Dev and Ops never come together? That they remain in those isolated tents on far sides of the field?

What if you could give operations their own sets of automation tools — tools that work well with DevOps tools and could ultimately collaborate on a full automation pipeline for your application lifecycle? Would that not also accomplish the end-goal of DevOps?

Fundamentally, trying to get two groups of people working on the same problem is idealistic and overlooks some fundamental flaws in human nature. Sometimes two groups with different goals, different values, and different points of view aren’t supposed to agree all the time. Sometimes the best way to get those groups of people working together is by not forcing them to work together in the first place.

Enough philosophizing. I’m off to try that toothpaste and orange juice-flavored ice cream.

Want to learn more about the topics I cover in my blogs: DevOps, AgileOps, Continuous Delivery, Release Automation, Digital Transformation (and many others!), then feel free to register here to get regular updates from me.