Follow me on Twitter Twitter_16
Subscribe to my RSS feed Rss_16
Posted over 7 years ago

What is DevOps?

I’ve been interviewing candidates for a DevOps opening that Interactive Intelligence has available and I keep getting asked by candidates, ‘What does DevOps mean to you?’

If you were to google ‘What is devops?’ you’ll find pages and pages of blogs and articles answering just that. I’ve read a few of them but I still find myself struggling to give a clear answer.

I think the trouble with anwering this question is that people generally expect a 2-3 sentence answer and it’s difficult to encapsulate all my thoughts on the subject that concisely. Another issue is that when I’m talking about DevOps, I feel like my attempts at explaining it come off as if it’s some magical, fundamental, paradigm shift that exploded onto the scene and if followed will lead to peace on earth and an end to all hunger.

DevOps is a revolution!

No it’s not, it’s just a natural progression in the software industry. Take a minute with me to consider it from a business perspective and then from a historical perspective.

Business needs are the primary driver of change. In the software industry, speed is the key to success. If a competitor can deliver relevant features faster and with a higher quality than you, you’re eventually going to lose market share. A business can continue to invest heavily in sales and marketing campaigns, but eventually customers will move to the superior product.

So the business says, ‘We need to deliver code faster.’ Ten years ago when that question was asked, developers answered the call. They replied, ‘You asked us to build this huge product, with hundreds of requirements, then 6 months in you changed those requirements! Give us smaller pieces of work and we’ll deliver.’ Thus Agile was born. Granted this is oversimplified, but the point is that now we all look back and there is a clear delineation in the history of software development; before Agile and after Agile. But Agile wasn’t a revolution, it was a natural response to a business need.

Once again, the business is saying, ‘We need to deliver code faster.’ Now it’s operations turn to answer.

Why now?

Operations has been talking about DevOps concepts for a long time. Tools like PXE, cfengine, etc. are proof of this, but until recently the operations side of the house has been hand-cuffed by the physical world. By hand-cuffed I mean that for operations, change is difficult and slow. Physical machines must be moved, plugged in, booted, installed, and configured. On the other hand, the work that developers do is not constrained by the physical world. All that’s needed to implement a change is editing a line of code. The point is change is easier for developers. For that reason developers have been able to introduce change (not just in code, but in tooling as well) faster than operations have been able absorb it.

The advent of virtualization and following that, the cloud… has changed the industry. The ability to spin up new resources with ease has transitioned the focus from ‘creating and managing stable servers’ to the ‘creation and managment of stable infrastructures’.

I like that, so I’ll say it again… The ability to spin up new resources with ease has transitioned the focus from ‘creating and managing stable servers’ to the creation and ‘management of stable infrastructures’.

So… What’s all this mean?

The primary goal of development is to change applications to meet business and customer needs. The primary goal of operations has historicaly been to maintain a stable application. Change is the enemy of stability. For that reason, a wall developed between developers and operations. This wall was further re-enforced by silos that were put in place by managment. DevOps is about moving away from this. Operations/DevOps is now about maintaining an infrastructure that is both stable and resilant to change. It’s about breaking down walls and enabling conversations, feedback loops, processes and tooling to that end.

The DevOps community continues to define how to accomplish these goals. The details are varied and outside the scope of this post, but the high level concepts are.

- Automate, Automate, Automate!
- Consistency (both within a single enviroment and between environments).
- Repeatability
- Test (both the application code and the infrastructure)
- Version control
- Visability (If it’s not tracked, then it won’t be improved. If no one see’s it, then it won’t be improved.)
- Communication (with both developers and the business)

But above all…

My goal as a DevOps Engineer is to create a performant and stable infrastructure while enabling the ability to push new code to production frequently, easily, and with confidence.

Want more?

- The DevOps Manifesto
- 2013 The State of DevOps
- DevOps weekly newsletter
- Just Enough Developed Infrastructure
- Code as Craft
- Food Fight Show
- The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

comments powered by Disqus