While the phrase “DevOps” suggests a cross-pollination of skills between Dev and Ops, in practice most think of it as Devs assuming some Ops roles, with their influence ever increasing across the app life cycle.

I predict this is only the beginning of the diminishing role Ops will play. In fact, I will go as far as to hypothesize the end of the dedicated operations team members altogether. I see NoOps as closer to the reality we will see in the next few years; Dev’s role will increase until it consumes Ops entirely.

Dev and Ops: Destined to split?
Dev and Ops were actually drifting apart before the DevOps movement brought them together. At the turn of the century, while Devs yearned for agility, Ops created formal repositories of best practices in ITIL and COBIT (and you can’t get much less agile than a formal repository!).

Perhaps DevOps was a last-ditch holiday for a warring old couple, a desperate attempt to avoid the inevitable acrimonious divorce. Was DevOps a ploy by Dev to kid Ops into thinking it has a place in a digital future? Did it pull them along for the ride, harvesting its knowledge before tossing it by the wayside, the pupil having become the master? After all, DevOps encourages change while ITIL seeks to control them.

Do we trust developers to do Ops?
Is IT Operations dying? The more important question is, while Devs can handle deployments, do we trust them to manage data centers or infrastructure? There are areas where stability is paramount, so Ops will still have a role to play, although it could change significantly.

In DevOps, there are delicate Ops requirements that require specialists, duties that we may not want to trust Devs with. Production infrastructure is a complex matrix of technology, often involving a subtle mix of modern and legacy architectures. This is often why an app that was successfully tested in one environment suddenly doesn’t work in the next, and it is crucial to validate code in an exact replica of the production environment.

(Related: How to put testing back in DevOps)

For this reason, perhaps DevOps should actually be led by Ops rather than Dev. If we focus on making frequent changes, then the workload for Ops also increases or even produces a bottleneck at Ops, so effectively Ops is in control. Therefore, value is only added to the company if Ops is strong enough to mirror the additional focus on development.

OpsDev
Perhaps DevOps can even be viewed as OpsDev, as Dev’s changes mean nothing if they cannot be tested and progressed to the next environment successfully. For OpsDev to run as smoothly as possible, Dev must subordinate itself into a consumer of environments. Ops then needs to provide infrastructure on demand for all steps of Continuous Integration: compilation to unit testing to qualification.

Infrastructure would be described and built from source code using sophisticated automation, with complex self-service infrastructure available as a result. This would allow Dev and Ops to share the same piece of automation technology to continuously deliver both applications and infrastructure.

So DevOps does not spell the end for IT Operations, but rather the emergence of bidirectional agility that will require the support of intelligent automation. Anyway, whatever your angle on the release process, there is always a common goal: delivering a flawless service to customers.