This is a guest post from DevOpsGuys. DevOpsGuys are an award winning DevOps consultancy working with enterprise organisations to create and help deliver DevOps strategy and transformation programmes. These incorporate education pathways, cultural change, and engineering solutions by applying DevOps principles to build a digital culture.
Widely regarded as a global thought leader in the DevOps space, the opinions of DevOpsGuys consultants have been quoted in research by Gartner, Forrester and Microsoft.
In this three-part series, guest bloggers from DevOpsGuys 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 DevOpsGuys on 0800 368 7378 or email the team.|
Also in Blog
I’ve read through a number of the industry thought leaders to get an understanding of how DevOps is being communicated out there. As with so much else in life, you can start at Wikipedia to get a ge...
Also in Database DevOps & DLM
In this three-part series, guest bloggers from DevOpsGuys 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 ...
Also about Database DevOps
How do you quantify the value of DevOps? The answer might depend on what value actually means for your organization, which stakeholder you’re talking to, and what type of lens they're looking throug...
Also about DevOpsGuys
Earlier this year, we ran a DevOps 101 webinar in conjunction with Redgate to a predominately DBA audience. In this blog post our own DevOpsGuys DBA, Paul Ibison, gives his views on what DevOps means ...