On a recent call to discuss our DevOps services, one of our executives asked for a clear definition of the term “DevOps”. So I thought I’d write down a few of my thoughts here in the interest of sharing.
First, it’s easier to describe what DevOps is not. DevOps is not a tool or a set of tools. It’s not a methodology or even a process. It’s not something that just happens. And it’s not just a buzzword.
DevOps is a mindset more than anything else. DevOps is something an organization (not an individual) adopts and grows a culture around. Many organizations will implement Continuous Integration (usually with a set of tools) and believe that they are implementing DevOps. But they are only partially right. This is a good first step to a DevOps culture, but it’s a lot more than that.
A successful DevOps end-state (if such a thing even exists) centers around the concept that applications, software, infrastructure, middleware, datastores and networks are all mutable. In fact, it’s not just that any or all of those things can change, it’s that they will change. So a DevOps-capable organization will put processes and tools in place to handle those changes. It’s not just adopting an agile development approach — though that is something that actually drives DevOps since all of those application changes need to go somewhere — it’s pushing the idea of agility beyond developers and into operations (the Ops part of the portmanteau).
I’ve encountered many organizations involved in creating and deploying software-based solutions who truly believed they would only deploy their solution once. Or maybe they’d do annual or biannual updates. In this environment, the pressure builds to make sure the deployment goes perfectly, since you only have one shot at it (or have to declare an emergency to get a second shot, which usually involves an executive watching you type…). No wonder that deployments are things to be avoided.
DevOps should turn this on its head – deploy often so that deployments aren’t scary things. They are routine.
But this is hard. Anyone familiar with KAI (Kirton Adaption-innovation Inventory) will recognize that development teams tend to be right-end KAI organizations, while operations teams are left-end KAI groups. A DevOps effort will bridge this gap and create a new culture that includes both groups.
There are a few ways I like to suggest to make this happen:
- Stay with your code until it’s stable. This means a developer will move to operations while her latest change is rolled into production. If deployments happen frequently (daily, weekly) this should only mean a few days of sitting in an ops chair monitoring usage.
- Rotate operations staff through development sprints. Give an ops guy a small task to implement. This will give them a chance to see how developers expect things to run in production (and allow them to correct that early).
- Use the same runtime environment for developers and operations. This means automating the stand-up of development environments (docker, vagrant, ansible and bosh are good tools to look at here) and applying that same automation to QA and production. Frequent deployments can start at the developer’s desktop. Another interesting one announced today is OneOps from Walmart Labs. More on that in a later post.
DevOps is a journey that really never ends, since nothing in your environment will ever really be permanent. So adopt the mindset and make your entire enterprise more agile.