Debugging DevOps

I first became aware of DevOps in 2010 or so. It was around the same period that Steve Blank’s Four Steps to Epiphany was becoming a bible for startups and Eric Ries Lean Startup started gaining adoption. DevOps was seen as a great way to execute lean startup on the product dev side. It made lot of sense. I have been a fan.

Somewhere in 2013, I started feeling nervous about DevOps and started observing symptoms that were telling me that perhaps DevOps is causing more harm to organizations than helping.

I want to help debug it. Here is my attempt.

To me, essence of Devops boils down to three things.

1. DevOps should allow you to do frequent deploys

You can get to frequent deploys through automating deployment tasks and coordinating well between dev and ops. Why do you need to do frequent deploys? Frequent deploys of smaller changes reduce your risk incredibly well than a big deploy every six months.

2. DevOps is about working well within engineering/IT, irrespective of your role

For your organization to hit the required frequency and fix errors if they happen, dev, ops, QA, security and everyone else in the dev-test-deploy chain needs to collaborate well and work as one team.

3. DevOps is about spreading knowledge across the engineering/IT organization

Its about caring beyond your defined boundaries and knowing how other things work. The reason for this is simple. If you know how things work at least at a high-level, you can start taking steps to reduce errors that will cause you rework.

If done well, DevOps will make your work easier and lower work stress.

So, in reality, how is DevOps being talked about?

1. You must have a config mgmt solution

Automating deployments could use a good config mgmt solution. A config mgmt solution will not turn you into a DevOps organization. In fact, I would not recommend using a config mgmt solution in the early days of moving to DevOps — it will hurt you more than help. First understand how your current configuration management works and what you should do to automate it. Based on your needs, start writing scripts and execute few deploys. Once you are convinced your organization is ready, think about adopting a opensource config mgmt solution.

2. DevOps requires reorganization

This is the worst thing you can do. Taking developers, operations, QA, security folks, data center heating and cooling folks into one team is not going to get you very far and it will in fact slow you down. Keep your current structure and figure out how to make it work. If you can not get collaboration between teams, you have a management problem that DevOps won’t fix and you are better off escalating it to senior management. If you can not fix this problem, forget DevOps. Also, may be update your resume. Also, whatever you do, do not add “DevOps” to your title — you will be obsolete faster than “Y2k” experts.

3. DevOps is about hugs

Its not — it does not require you to bring donuts to work everyday or hug your team. Its not all butterflies and rainbows. DevOps requires a fair amount thinking and dedication to getting stuff done. Don’t fall into the trap of thinking that increasing number of high-fives in the organization will help you become better at DevOps.

4. DevOps is about managing development as a foreman manages an assembly line

Applying techniques from a predictable activity such as manufacturing to software development is stupid. This won’t work. Has been tried before — go to your local library and find books written in the 1980s about “software engineering” — for good measure, filter by “computer aided”

In addition, I have also head the following:

DevOps is all about Deming

DevOps is all about theory of constraints

DevOps is about effective adoption of ITIL

DevOps is all about daily hugs

DevOps is all about SDN

DevOps is all about adopting PAAS

DevOps is all about hiring anyone off the street and making them productive

DevOps is nothing but Scrum, but including Ops folks into it

DevOps is all about preventing configuration drift

DevOps is all about Systems Thinking

DevOps is all about bringing security folks to modern technologies

There is a camp that argues that DevOps is all about APIs

DevOps is all about Cloud

DevOps is all about Hybrid Cloud

DevOps is all about masochism and doing 250+ deploys per day

I think it would be fair to say that there is more confusion about DevOps in the industry than an understanding of it. People that act based on this misunderstanding often end up making expensive mistakes with organization, projects, training and event attendance.

At this point, I am of the view that DevOps as a movement can not be saved and we as an industry would be better off to abandon it and get a fresh start. Lets call the new thing Horse Sense or something like that.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.