I find there is a tendency to believe that in the era of DevOps and Continuous Delivery Operations folks are not needed anymore: developers just need to learn some tools, maybe a few practices and they are good to go. NoOps FTW!
“NoOps” beats “cloud”, “agile”, and “SOPA” as the dumbest marketing term ever coined in my field. http://t.co/53On2fZf #devops
— John Allspaw (@allspaw) February 1, 2012
I think this is going to come back to haunt us.
There is a humungous Operations body of knowledge most developers completely ignore. And to be honest I think only a fraction of those who know it even exists are interested in it, good at it or will ever be great at it.
Nothing wrong with that, different people are good at different things and all that. But I see lots of people who believe all they need to do to replace Ops is to learn Chef‘s syntax and spin up a few AWS instances. This is akin to the Object Oriented developers who believe they just need to learn Clojure‘s syntax to become good functional developers (by the way we sponsor EuroClojure for a reason ;-)).
And of course they kind of completely miss the collaboration bit of DevOps: since they are “replacing” Ops there are no Ops to talk to, right?
The industry by and large is going down the route of automating what Ops do without knowing why they do it.
The funny thing is that many experienced Ops folks make the same mistake! They argue all they need to do to jump on the DevOps bandwagon is learn a few new tools. They too concentrate on what and ignore that their value starts with the why.
And of course they kind of completely miss the collaboration bit of DevOps too: they are only changing tools after all.
I think we need to look at this from the generalising specialist point of view.
Devs in this brave new world should:
- have one or more technical specialties specific to Software Development
- have at least a general knowledge of Operations and, in particular, Operability
- have at least a general knowledge of the business domain in which they work
- actively seek to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas
and on the other side of the coin Ops should:
- have one or more technical specialties specific to Operations
- have at least a general knowledge of Software Development
- have at least a general knowledge of the business domain in which they work
- actively seek to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas
A few weeks after I jotted down this post, Donnie Berkholz of RedMonk wrote a post titled ‘The interface from Dev to Ops isn’t going away; it’s rotating’ where he illustrates neatly how the outcome companies need to be looking for is not what many seem to think it is:
“what’s missing is the understanding and communication that developers must own application-layer code wherever it lives, while ops must own the infrastructure wherever that is […] the key transition here is a cultural one of bidirectional empathy and bidirectional contribution.”