Dev and Ops have misaligned, or if I may, even opposing priorities. Development (Dev) is tasked with producing innovation and getting it to the hands of the users as soon as possible. Operations (Ops) is tasked with making sure that the users have access to a stable, fast, responsive system. While Dev and Ops’ ultimate goal is to make the user a satisfied (and potentially a happy, paying customer) of the systems they provide, their views of how to do it tend to be inherently opposing. No developer wants to intentionally produce a buggy system that would cause the application to crash while a user is using it. No operations person wants developers to not produce updates with new exciting features and capabilities. It is how they would like to go about it is what is different. It is a classic symptom of what is referred to as Water-SCRUM-Fall. Developers want and are expected to produce new features, fast. Operations want and are expected to produce a stable system, at all times.
Dev vs. Ops:
When Developers and Operations lived in truly isolated worlds, these opposing priorities were not that much of an issue. Developers and Operations worked on a schedule. One marked by limited interactions, only at release times. Developers knew when the release date was. They could only release new features then. If they did not get a new feature in by the release date, they would have to wait for the next train. Operations knew when the train would come to town. They would have enough time to test the new features before deploying them. And they could take days (nights) to deploy them out to customers. For large systems, even do it in a phased manner spread over long periods of time. Stability was maintained.
DevOps changed all that. With Continuous Integration and Continuous Delivery, developers now are getting their features out daily. There was no release train to wait for. It was a conveyer belt (pipeline) that ran all the time. The developers now wanted their features out and up and running – in the Dev environment, in the test environment and in Production – at the same frequency at which they produced and integrated them. They wanted Ops to accommodate all these new releases.
Ops had to now deal with not one release every so often but a continuous barrage of CI builds. These builds may or may not be deployment ready, but had to be managed by Ops and deployed to test and eventually production environments. Ops now cared more about quality. They do not want features that were not aggressively tested disrupting production systems. They could no longer take days to deploy features once they were passed by Test. They still however had to maintain stability.
Dev AND Ops:
The solution to this battle between Dev and Ops is what DevOps and the practices that make up DevOps are trying to address – to achieve the balance between innovation and stability. Both Dev and Ops need to change how they operate and align better.
The Dev view
The above section may make it seem like it Ops that need to change more than Dev (My name is Sanjeev. I am a developer, and I am biased), but Dev does need to make several changes too.
- Dev needs to works with Ops to understand the nature of the Production systems their applications will be running on. What are the standards for the production systems (Patterns – more on patterns in later posts) and how should their applications perform on them? Under what constrains they have that the applications need to operate within? Dev now needs to understand System and Enterprise Architectures.
- Dev needs to get more involved in testing. Not just making sure that their code is bug-free (as my Grad school QA professor Dr. Soong used to say – if you don’t want bugs in your code, don’t put them in there!), but also testing the application to see how it will perform in production. This requires Dev to work closely with test and test their application in a production-like system (more on production-like systems in a later post too).
- Dev also needs to learn how to monitor deployed applications and understand the metrics Ops care about. They need to able to decipher how processes interact and how one can cause another to slow down or even crash. Understand how changes to their code will impact the whole production system and not just their own application.
- Dev need to communicate better with Ops.
The Ops view
Ops need to be able to allow their systems to absorb rapid change.
- Ops need to know what code is coming and how it would impact their system. This requires them to be involved with Dev right from understanding requirements and system specs of the applications being developed. They need to make sure that their systems can accommodate these applications as they are enhanced.
- Ops need to automate how they manage their systems. Rapid change, with stability cannot be achieved without automation. Automation will not only allow rapid change, but also rapid roll-backs, if something does break.
- Ideally, Ops need to version their systems. This can only be done when the infrastructure and all changes to it are captured and managed as version controlled code. (More on infrastructure as code in a later post – yes, this is going to be a long series).
- Ops needs to monitor everything, all through the Dev – Test – Prod pipeline, whichever environment it is that the Ops teams manage. They need to be able to spot potential instability as soon as it happens.
- Ops need to communicate better with Dev.
The Cheese is being moved:
To conclude, Dev and Ops both need to be bought into the DevOps paradigms. They both need to know that this is not going to be easy. It is not going to be something that can be achieved in a day. They need to plan for and work towards gradually adopting the changes needed to achieve the promise of DevOps. They may never get to or in most cases should never get to where Dev and Ops are one team, but need to understand that their roles will change as they adopt DevOps. They need to change just enough to work together and find the right alignment between Dev and Ops that their organization needs. And improve from there.
Like to learn more about Adopting DevOps? Check out my new book – The DevOps Adoption Playbook.
Related Posts
Understanding DevOps:
- Understanding DevOps – Part 1: Defining DevOps
- Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
- Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
- Understanding DevOps – Part 5: Infrastructure as Code
- Understanding DevOps – Part 6: Continuous Deployment
- Understanding DevOps – The Video (6 minute Intro to DevOps)
Adopting DevOps:
- Adopting DevOps – Part I: Begin with the Why
- Adopting DevOps – Part II: The Need for Organizational Change
- Adopting DevOps – Part III: Aligning Dev and Ops Teams
- Adopting DevOps – Part IV: Adopting Continuous Deployment
- Adopting DevOps – Where to start? (Video blog)
- DevOps vs Outsourcing
DevOps books I have written:
Other DevOps Posts:
- What is Water-SCRUM-Fall?
- Leveraging DevOps in a water-SCRUM-fall world
- Monetate’s 12-step program for Continuous Delivery
- The State of DevOps (by PuppetLabs)
- DevOps for Mobile Apps – Slides from IBM Pulse 2013
- Chef for DevOps – An Introduction
Home: sdarchitect.blog 
31 Comments Add yours