Understanding DevOps – Part 3: Dev vs. Ops

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.

Related Posts

Understanding DevOps:

Adopting DevOps:

Other DevOps Posts:

About these ads

, ,

  1. Understanding DevOps – Part 1: Defining DevOps « Sanjeev Sharma
  2. Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery « Sanjeev Sharma
  3. So, what is ‘Water-SCRUM-fall’? « Sanjeev Sharma
  4. Leveraging DevOps in a ‘water-SCRUM-fall’ world – my Post on IBM’s Invisible Thread Blog « Sanjeev Sharma
  5. Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring « Sanjeev Sharma
  6. Monetate’s 12 step program for continuous deployment « Sanjeev Sharma
  7. Understanding DevOps – Part 5: Infrastructure as Code « Sanjeev Sharma
  8. There is no such thing as DevOps for Mobile Apps! « Sanjeev Sharma
  9. Chef for DevOps – an Introduction | Sanjeev Sharma
  10. Understanding DevOps Series!! | the BPM freak !!
  11. Adopting DevOps – Part II: The Need for Organizational Change | Sanjeev Sharma
  12. Adopting DevOps – Part I: Begin with the Why | Sanjeev Sharma
  13. The State of DevOps (by PuppetLabs) | Sanjeev Sharma
  14. Adopting DevOps – Part III: Aligning the Dev and Ops Teams | Sanjeev Sharma
  15. Understanding DevOps – Part 3: Dev vs. Ops | Brent Sordyl's blog
  16. Slides: IBM Innovate 2013 Session – Continuous Integration for System z | Sanjeev Sharma
  17. Slides: IBM Innovate 2013 Session – DevOps for Mobile Apps | Sanjeev Sharma
  18. Slides: IBM Innovate 2013 Session – DevOps 101 | Sanjeev Sharma
  19. My ‘meetup’ with Gene Kim | Sanjeev Sharma
  20. Updated DevOps 101 Deck | Sanjeev Sharma
  21. Understanding DevOps – Part 6: Continuous Deployment | Sanjeev Sharma
  22. Adopting DevOps – Part IV: Adopting Continuous Deployment | Sanjeev Sharma
  23. My First Video Blog: Understanding DevOps (A 6 min Overview) | Sanjeev Sharma
  24. IBM Pulse Session: Continuous delivery – accelerated with DevOps | Sanjeev Sharma
  25. Video Blog: DevOps – Where to Start? | Sanjeev Sharma
  26. Video Blog: Continuous Delivery vs. Continuous Deployment | Sanjeev Sharma

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 27 other followers

%d bloggers like this: