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.

[if !supportLists]·         [endif]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.

[if !supportLists]·         [endif]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).

[if !supportLists]·         [endif]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.

[if !supportLists]·         [endif]Dev need to communicate better with Ops.

The Ops view
Ops need to be able to allow their systems to absorb rapid change.

[if !supportLists]·         [endif]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.

[if !supportLists]·         [endif]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.

[if !supportLists]·         [endif]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).

[if !supportLists]·         [endif]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.

[if !supportLists]·         [endif]Ops need to communicate better with Dev.