mike-woome.tumblr.com
Frankly, being an ops person who was dev trained (CS degree, doing ops since) what I've seen from other ops people once exposed to a devops mindset one of a few things:
1. Fear - mostly people who haven't even scripted anything before (common in Windows and pre-OS X Mac environments)
2. Confusion - I'm supposed to learn what with the who now? Mainly this is a tool choice issue - there's an overwhelming number of options out there.
3. Relief - finally, someone ELSE understands what I've been trying to do for the last N years, and I can talk to!
My guess is that, for ops people to accept this is to get the #3's to work with the the #2's on tool choice and familiarity, and then have the #2's convince or prove to the #1's that it's a good idea.
Dev interaction would probably be with mainly the #3's, as that would be the best opportunity for dialogue that would be meaningful to both sides.
We are the league of sys admins. We know what we are doing.
Personally, I find the whole devops notion a bit bizarre, since, from what I can tell, the theme is one of two.
One is trying to make sysadmins into programmers (or hybrid programmers/sysadmins). This may be the one-way street the blogger is referring to. I could be a programmer if I wanted to, but that's not what brings me joy. There's a reason I've been a sysadmin for my entire career, and it's not some deficiency (i.e. I'm not a layman).
The other is, to my mind, just wishing for better sysadmins. Sadly, I don't think there are enough of us who do know what we're doing, not to the depth you describe. Much of this may be for lack of experience and/or mentorship: they haven't seen it and done it.
when I cut my teeth on sysadmin work in the late 17th century, ops guys drew a line in the sand
This comment was the revealing one to me. Its inference belies long experience. My own start at the profession was in 1988, though, arguably, not in an environment with software developers until '92. Not only did we[1] not put artificial limits on our responsibilities, but I had to fight a couple battles to keep developers from running roughshod over a shared environment made stable through my concerted efforts.
Agreed: We are the league of sysadmins. We know what we are doing.
I would only add: Not all problems are best solved by more code.
[1] originally just me, but then a total of three of us in that environment
And of course, sysadmins have a wealth of experience to bring to the way development is done. It wouldn't hurt if a few more developers learned bash and the different levels of RAID.
Personally, give me a developer who also knows operations and systems maintenance and debugging, or a operations guy who also groks development and the product development lifecycle. Having these roles be distinctly separate people or teams, who don't have experience on the other side, is a gross inefficiency.
There's a tendency, as a company grows larger, to separate the concerns. In a smaller company, it's almost necessary to have the same one or two people do both roles (especially in a startup -- your startup's chances of even getting out the gate are reduced if your technology arm only does one or the other). I think some of the increased elitism from the purely developer side comes from the recent perception that "you can get rid of your systems and ops guys because developers can now deploy to the cloud". Elitism exists in some form on the systems and operations side because technical debt is more obviously visible to them (but they are unaware of the history of the reason for much of the technical debt, not having been involved with the product side). The ones who are legitimately elite, because they are on both sides, are also seen as humble because they concentrate on actually solving problems using whichever tools are available from either camp.
We're likely less than 5-10 years away from a world where most operational tasks can be passed on to trusted cloud providers, similar to how you don't wire up your own phone service or plumbing any longer. You still need talented ops people, but they'll be working for a service provider not your own organization.
I'm not so sure that comparing systems and operations to wiring up your own phone service or plumbing is appropriate. Those are home, consumer level concerns, but businesses would be wise to have someone on staff, dedicated to understanding their exact needs, rather than attempting to outsource everything, especially during rapid growth. You still need systems experience to know, for example, which of EC2, Softlayer, Media Temple, Engine Yard, or Linode is appropriate, and how to interpret their offerings.
Even in 10 years, someone who knows both is going to be more valuable than someone who knows just one. Devops is a different kind of specialization that is actually multidisciplinary.
We already have outsourced systems/operations work available as a purchasable service, it's called "Managed Services". Datacenter providers have been trying to upsell to it for years. I used to do managed services at various datacenters, and we all knew we weren't very effective because there was never enough time or money (from the client) to spend on truly understanding their needs.
I think you answer your own question:
you don't wire up your own phone service or plumbing
Although linemen and plumbers aren't seen to be in jobs that are menial, you'd have trouble classifying them as elite, compared to their customers[1].
Regardless, the analogy strikes me as tenuous, since plumbing and telephones aren't fundamental to most businesses. On the other hand, computer systems, for a software company, are very much the fundament of what it does.
Perhaps a better analogy would be the likes of FedEx or UPS outsourcing the maintenance (and perhaps all operation) of its trucks and planes. I'm pretty confident they keep that in-house.
[1] Presumably, this is, predominantly, homeowners and landlords.