Click here to monitor SSC

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the Simple-talk.com and SQLServerCentral.com websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his Simple-Talk.com blog or his SQLServerCentral.com author page. As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management. In his spare time, he enjoys running, football, contemporary fiction and real ale.

DevOps Dilemma

Published 14 February 2014 1:21 pm

The term ‘DevOps’ has been widely misunderstood because the different teams within any really substantial development project understand the work of the other teams so poorly. There will be several teams, including business analysts, technical architects (maybe), UX specialists, designers, testers, and developers. No development specialists, however, have until recently had the production environment firmly in mind when designing and developing their applications. Unfortunately, this causes problems for the team tasked with supporting the live application, especially as development teams move towards a culture of releasing applications ever more frequently.

The DevOps grassroots movement grew up from groups of operations people meeting to discuss the challenges of providing 24×7 support for business applications, subject to stringent SLAs, when those business applications, on the whole, lacked those qualities that allowed for uninterrupted service to meet those SLAs in production. The goal was to find ways to encourage developers to “think production” earlier in their development efforts. It aimed to promote the ideas, tools and automation that will allow developers to release software often, while retaining environmental stability, and the sanity of the Ops staff. The aim, in short, was to prevent nasty surprises and subsequent conflict as the time of software release approached.

It makes a lot of sense for Dev and Ops to cooperate in streamlining the application deployment process, but I don’t think DevOps means that these two separate skills should be merged into a multi-skilled development role. It is an unrealistic idea. Instead, surely, the devs work on their deployment processes so that they can deliver early and often, to a “production-like” environment. The Ops are able to ‘work upstream’ and identify the coming changes that might cause issues way before they are due to hit production. They can then advise on whole range of issues that will derail the whole process if discovered at the eleventh hour. More important, they can contribute to solving the more ‘cultural’ issues such as instrumentation, the types of performance, resilience, and scalability testing that minimizes production risks, and support-documentation that will help them support the application effectively when it goes live.

The DevOps movement has not had an easy growth, as the warring tribes of corporate IT departments have used it as a weapon to diminish the work of the others (e.g. NoOps), and development movements such as Agile have tried to claim the infant movement as their own. It has, at times, been portrayed as little more than a “group hug”, aimed at nurturing better relations and communications between the development and operations teams, so that delivering business applications becomes more like a smooth, cooperative production line than a game of ‘pass the hot potato’.

Surely it is more than this? I’d love to hear from anyone about the technical solutions and better processes that DevOps has delivered for them.

5 Responses to “DevOps Dilemma”

  1. Keith Rowley says:

    I disagree about not merging the skills at least from the dev side. I think every developer should spend time working in operations and customer support on a rotating basis. Having to actually support users in the real world makes me a better developer. 37Signals is a great example of this. They have talking on their blogs about the way developers shift into customer support on a rotating basis and how this improves the product overall.

  2. Keith Rowley says:

    Just to clarify, I don’t work for 37 signals. I just read their blog as I like the philosophy of software development they advocate for.

  3. TodConover says:

    The topic is too big to cover, but I’ll suggest that Operations be treated like a customer. As developers we have an obligation to meet our customer’s functional requirements and the requirements of operations to support the end product. Support requirements for a new product should be gathered after functional requirements and before design begins. You must factor operational support requirements into the mix prior to design, otherwise you are not really solving the whole problem. There is no excuse to deliver a product that can’t be properly supported, regardless of how cool it is or how fun it was to create.

  4. paschott says:

    I’d tend to argue that this is a two-way thing. Devs need to code w/ Ops in mind, but Ops has to listen to what Dev says they need as well (and there has to be some give and take in the end result at times). We’ve had a DevOps team in the past and enjoyed several benefits as a result – streamlined releases, better environment builds, configs easily accessible in source control, real-world scenarios and pain points being resolved, and just better overall understanding of why some things work or don’t work on both sides.

    I actually like the idea of devs being able to do a little customer support from time to time. Some devs need to know why their great idea is or isn’t so great to customers. Many need to actually know and understand how the customers use or want to use the systems. Many also need to better see how their code affects the underlying hardware.

    We’ve also had some gains when it comes to writing code that can be supported more easily. Services that can be monitored, restarted, throttled, or tweaked to generate more detailed logs were another benefit we got from our DevOps team. There were still quite a few older pieces of code that weren’t affected, but we were able to write these into newer apps as they came up. We also worked closely to come up with appropriate levels expected for monitoring, answering questions about why some were so out of place or sometimes realizing that the code needed to be adjusted because of those levels.

    It definitely fostered a more cooperative environment for producing and releasing software. I wouldn’t discount the better communication and relationship aspect to DevOps. That goes a long way toward helping everyone truly feel like they’re on the same team instead of opposing teams.

    I read the “NoOps” article and agree that Infrastructure as Code is a good thing. We used Chef to automatically configure many of our servers and services. The devs helped our Ops team with the configuration, needed components, and so on. We can now easily generate a completely new working environment in a day or so – mostly by adjusting the scripts for that environment and letting them run. I don’t necessarily agree that DevOps == “just getting a better way to push code”.

  5. jerryhung says:

    I know someone who got merged with the Devs team from the Ops side, and it’s strange all around, I suppose for the better?

    For one, Devs are Revenue centre instead of Cost centre for Ops

    And Ops wasn’t exactly doing chargeback/showback while Devs side are

    I think there’ll always be 2 sides (for larger companies) because of the nature of work are too different. But it doesn’t hurt to involve both sides more

Leave a Reply