DevOps has always been about Ops

Based on my experience, the term DevOps is mostly used for sysadmin folk that can script, whilst empathising enough with their fellow backend developers, in order to collaborate in an agile fashion and enable their organisations to release software at high frequency and confidence.

Puppet and CFengine, both proto-devops tools, that ushered the era of configuration management to the average organisation, were created by Ops people.

Luke Kanies, Puppet creator, founder and executive board member, had a few sysadmin jobs after his graduation, before deciding to develop Puppet in order to deal and cope with repetitive nature of the job. Mark Burgess, creator of CFengine, is an Astrophysicist turned Professor of Network and Systems Administration. Jezz Humble, synonymous with the Continuous Integration and Delivery movement, is essentially a release manager and an Infra guy. Gene Kim of Tripwire, Visible Ops and Phoenix Project fame, is also an Ops guy at heart.

There is a good reason why terms such as NoOps are viewed as ill guided and plain wrong by the DevOps community. Ops are here to stay. They just evolve and change like all other tech roles. The DevOps Godfather a.k.a Patrick Debois, is also a Systems guy. He came up with this catchy and nuanced term to describe this Dev compatible new breed of Ops, back in 2009. Seven years on, and the term is still reverberating in the IT world, and causing a stir in both start-up and mature enterprise CTO and CIO circles alike.

The vast majority of individuals who use the DevOps title to describe their work have a background in Ops. Google SREs need to understand Systems and Infrastructure. They also need to be competent Software Engineers, but the Systems element is the prerequisite for their title.

Infrastructure as Code, is a set of principles and practices that attempt to apply Agile, TDD and XP programming to the Cloud and Software Defined Infrastructure reality.

So, if DevOps is firmly placed in the Ops end of the spectrum, what about all the cultural and organisational elements that it’s supposed to be bringing along with it? How can those be articulated, presented, applied and adopted by Organisations that are willing to undertake the journey, but have no idea about the itinerary let alone the destination?

More on that later.