Is DevOps Being Hijacked by Technologists?

This is a guest post by Lindsay Holmwood (@auxesis).

The DevOps Movement

When Patrick Debois kicked off the DevOps movement, his experience as a project manager gave him a very unique perspective on the problems faced by development and operations teams. Patrick is visionary because he saw that while teams generally worked well by themselves, things started to break down when the teams worked together.

This breakdown was exhibited clearly by teams throwing problems “over the wall” at each other. Neither team was willing to accept responsibility for problems they caused, and more critically there was a dearth of communication between the teams. Most importantly, neither team was more to blame than the other – both were suffering the effects of “siloisation”, the compartmentalisation of responsibility to a single team.

Patrick wanted to expose both developers and sysadmins to a better way of working together, one that was blameless and collaborative, that shared responsibility between teams, and took a more holistic approach to the life of software.

If you look at the what Patrick was trying to achieve, there’s actually nothing about it that was IT specific. All industries suffer from similar problems: doctors swoop in and lob the intricacies of patient care to nurses, and architects stay blissfully ignorant of design problems they’ve created that engineers and builders have to work around.

Technology And DevOps

Somewhere along the way, technology piggybacked itself onto the DevOps movement. Operations folk thought “if we’re going to start working with developers more closely, maybe we can use some of the same tools and tech?” DevOps became a label savvy and cutting edge Ops folk could apply to the cool tech they were making and using to manage massive numbers of machines.

In a way, this evolution makes a lot of sense – we’re working in an industry where technology is the bread and butter of what we do, so why not use technology to solve our organisational problems? It’s a very engineering way of looking at the problem, and something that, as geeks, we’re inherently predisposed to.

Funnily enough, I can see how I’ve personally contributed to this shift in the DevOps movement towards technology over process. When Patrick invited me to speak on cucumber-nagios at Devopsdays 2009, I was very focused on tools and technology for Ops. Cucumber was my hammer, and I’d be damned if there was a problem it couldn’t solve!

When I organised DevOps Down Under earlier this year, I unintentionally loaded up the programme with Ops-focused technical content that didn’t really appeal to the 50% of developers I worked so hard attracting to the conference. While the conference was still very successful, the focus on Ops-tech sabotaged that bridge building.

I was lucky that some of the process and methodology talk rubbed off on me at Devopsdays and DevOps Down Under, and I’ve since taken a greater interest in the process problems other folk in the DevOps movement are trying to address.

What DevOps Really Is

Looking at DevOps today, I’d contend that it’s seen as:

• improving collaboration and communication between development and operations teams,
• an adoption of methodologies (and some technologies) used in software development by operations teams, and
• a renaissance of infrastructure technologies that is strongly influenced by cloud computing.

I personally subscribe to Damon Edward’s assertion that “DevOps is not a technology problem. DevOps is a business problem”. The slogan is essentially a terse summary of what Patrick was getting at when he kicked off the movement.

Given how DevOps has morphed into a “one part process two part technology movement”, can we say that DevOps is being hijacked by technologists?

I’d argue “Yes, but it’s not necessarily a bad thing.” As long as the technology is an enabler of the underlying principles (communication, collaboration, a holistic view), the DevOps movement is still sound.

And even if DevOps evolves into a movement of technologists, people interested in process will found another movement that’s process-only – no tech allowed!

So I put it to you, fellow DevOps: where do you want the movement to go? Is there too much focus on tech? Do we need to get more developers (or, *gasp*, managers) involved, or are we content with being Ops-tech oriented?

About the author

Lindsay Holmwood is a sysadmin/developer from Sydney, Australia. He’s the creator of cucumber-nagios, Flapjack, Visage, and Gastro.