DevOpsGroup

14 June 2017

Where’s the Ops in DevOps? Part 1

In this three-part series, guest bloggers from DevOpsGroup look at the real role of Ops in DevOps. Where it changes, how it changes, and why Ops has an important part to play in the brave new world of DevOps.

DevOps does not equal ‘Developers managing Production’

I’ve had quite a few conversations, mainly with smaller start-ups or development houses, who tell me: “Yes, we work in a DevOps model.”

What they really mean is: “We pretty much have no Operations capability at all, and we rely on the Developers to build, deploy and manage all of the environments from Development to Test to Production. Mostly by hand. Badly.”

As someone from a predominately Operations background, I find this quite frustrating.

Operations is a discipline, with its own patterns and practices, methodologies, models, tools, technology, etc. Just because modern cloud hosting makes it easier to deploy servers without having to know one end of a SCSI cable from another doesn’t mean you know how to do Operations (just like my knowledge of SQL is enough to find out the information I need to monitor and manage the environment, but a long way from what’s required to develop a complex, high-performing website).

DevOps means Development and Operations working together collaboratively to put the Operations requirements about stability, reliability, performance into the Development practices – while at the same time bringing Development into the management of the Production environment. For example, by putting them on-call, or by leveraging their development skills to help automate key processes.

It doesn’t mean a return to the laissez-faire ‘anything goes’ model, where developers have unfettered access to the Production environment 24x7x365 and can change things as and when they like.

Change control was invented for a reason, and while change control has becomes its own cottage industry involving ever more bureaucratic layers of management-by-form-filling, the basic discipline remains sound. Think about what you want to change, automate it if you can, test it, understand what to do if it screws up (the rollback plan), document the change, make sure everyone knows when, where and how you are making the change, and make sure the business owner approves.

When I took over the Operations of a high-volume UK website about eight years ago, I spent the first three weekends fighting fires and troubleshooting Production issues.

My first action after that baptism of fire was to revoke access to Production for all developers (over howls of protests). Availability and stability immediately went up. Deafening silence from Development – invitations to beers from the business owners.

Next step was to hire a Build Manager to take over the build and deployment automation, and a Release Manager to coordinate with the business what was going into each release, and when, etc. End result – 99.98% availability, with more releases being deployed within business hours without impacting the users, and a lower TCO. The business was much happier, and so was the Development Manager, because he was losing far fewer developer hours to firefighting Production issues, and hence the overall development velocity improved considerably. Win-Win.

Was that a DevOps anti-pattern? Did I create more silos? Probably … but in a firefight a battlefield commander doesn’t sit everyone down for a sharing circle on how they’re going to address the mutual challenge of killing the other guy before he kills you. Sometimes a command and control model is the right one for the challenge you face (like getting some supressing fire on the target while you radio in for some air support or artillery!).

That said, once we had developed a measure of stability, we did move partway to a more DevOps pattern – we had developers on-call 24×7 as third-line support, we virtualised our environment(s) and gave Developers more control over them, and we increased our use of automation.

Organisationally, we remained siloed however – we were incentivised in different ways (Operations emphasising availability, Development emphasising feature delivery), we remained in essentially a waterfall delivery model and Ops vs Dev was a constant struggle for manpower and resources. All the usual problems that the DevOps movement is trying to address.

In summary, what I am trying to get at is, please don’t devalue the DevOps concept by saying you do DevOps when you don’t.

Unless you currently do both Development AND Operations separately, and do them well, AND you’re now trying to synthesise a better, more agile, more cloud-oriented way of working that takes the best part of both disciplines … you aren’t doing DevOps!

Are you looking to get started on your DevOps journey? Call DevOpsGroup on 0800 368 7378 or email the team

Discover more about applying DevOps processes to the database on the Redgate solutions page