Dev Vs Ops

I’m extending my previous posts “Defining DevOps” and “CI / CD” with this post.

Dev and Ops have misaligned, or contrasting priorities. While Dev and Ops’ ultimate goal is to make the user satisfied of the systems they provide, their views of how to do it tend to be inherently opposing. This is how they would like to go about, and this is what makes the difference.

Dev

Ops

Dev is tasked with producing innovation and getting it to the users as soon as possible

Ops is tasked with making sure that the users have access to a stable, fast, responsive system
No developer wants to intentionally produce a buggy system causing the application to crash while in use No operations person wants developers to not produce updates with new exciting features and capabilities
Developers want and are expected to produce new features, very fast

Operations want and are expected to produce a stable system, at all times

Note: Integrating Agile Framework on Waterfall / RUP Model can resolve this issue up to maximum extent.

When Developers and Operations live in discreet worlds, these opposing priorities were not that much of an issue. Developers and Operations work on a schedule with limited interactions, that too 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 turn.

Operations knew when the turn would come. 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 that with Continuous Integration and Continuous Delivery, developers now are getting their features out daily. There was no release turn to wait for. It was a 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 test passed. 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 all about – to achieve the balance between innovation and stability. Both Dev and Ops need to change how they operate and align better.

Dev View

Ops View

Work with Ops to understand the nature of the Production systems their applications will be running on.

Needs to understand System and Enterprise Architectures.

Understand how their code changes impacts the whole production system and not just their own application.

Need to know what code is coming and its impact to their system.

Requires to work with Dev right from understanding requirements, and system specs.

Need to ensure that their systems can accommodate these applications as they are enhanced.

Needs to know what are the standards for the production systems and how should their applications perform on them?

Under what constraints the applications need to operate within?

Need to automate their systems management.

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.

Needs to get more involved in testing to ensure that their code is bug-free, and also see how it will perform in production. Requires close collaboration with QA in testing application in a production-like Environment.

Ideally, 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.

Needs to learn how to monitor deployed applications and understand the metrics Ops care about.

Need to able to decipher how processes interact and how one can cause another to slow down or even crash.

Needs to monitor everything, all through the Dev – Test – Staging – Prod pipeline, whichever environment it is that the Ops teams manage.

Need to be able to spot potential instability as soon as it happens.

Dev need to communicate better with Ops.

Ops need to communicate better with Dev.

To conclude, both Dev and Ops 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 desired 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 continuously improve from there on.

Advertisements

One thought on “Dev Vs Ops

Add yours

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

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: