

Devops needs to be a two way street devs and ops - nicferrier
http://mike-woome.tumblr.com/post/1691265243/devops-devops
What strikes me right now, that the devops community, at least the bits I am meeting seems to be full of devs believing their bringing a revolution to the poor unwashed sysadmin masses. Well, you have some nice ideas and I think we can improve the whole community with some of this stuff but seriously drop the attitude because I’m finding it quite condescending and I’m not the only one.
======
zdw
The relevant XKCD: <http://xkcd.com/793/>

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.

------
chuhnk
I have to completely agree with this blog post. I'm a sysadmin living in a
world of developers and what I'm being shown is nothing new. I think there are
a lot of companies in which dev and ops is split to such a degree that the
devops movement becomes relevant in aiding them to bring together both sides,
but for the rest of us we've seen it and done it. I agree with the author,
there's a lot of condescension coming across. I am open to learning and
refining the processes by which we all collaborate and work but I'm not a
layman. I understand my field and enough of yours to keep systems running in
the evenings, middle of the night and times when you are not around to look at
bugs. I understand the scaling problems. I understand the need for continuous
integration testing and deployment systems.

We are the league of sys admins. We know what we are doing.

~~~
mmt
Hear hear.

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

~~~
nicferrier
devops makes so much sense to me because it's what I've been doing my whole
career. The trouble is with the devops movement, as the blog says, the old
tools and processes are sometimes still relevant. Sysadmins in that category 2
from the first comment need to be persuaded that a lot of their old skills are
absolutely still usable. The example from the article, of bash scripts getting
version controlled is a really good one I think.

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.

------
thwarted
As someone who has a CS degree but who is professionally a systems person,
I've been flipflopping continuously on if I even like the term "devops". I'm
looking for someone for my team to fill a "devops" role, and sometimes people
talk about it like it's "developer/operations" (someone who can be both a
developer and do systems work) and sometimes it's "developer operations"
(someone who is a toolsmith _just_ for developers, does release engineering,
deployment related work, monitoring and maintenance, doesn't deal with the
nittygritty of production systems).

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.

~~~
gfodor
I'm not really sure why "you can get rid of your systems and ops guys because
developers can now deploy to the cloud" is elitism, if you take the long view.
(Today, yes, you're jumping the gun a bit if you don't think you need ops
folks.)

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.

~~~
mmt
_I'm not really sure why "you can get rid of your systems and ops guys because
developers can now deploy to the cloud" is elitism_

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.

~~~
gfodor
I have a feeling the reason we think racking servers and configuring Apache
are fundamental elements for software companies has less to do with reality
and more to do with the status quo. The world is going through a phase shift,
and each day that goes by trends _away_ from the current model of in-house
operations. It's just a matter of how much farther things are going to get
before it slows down and stops.

~~~
thwarted
It definitely trends away from in-house operations for companies who view
their systems and operations to be cost centers that _are not_ intimately
involved with the product/service. And companies that do keep in-house
operations will have the same kind of competitive advantage that companies
that don't outsource their developers have (whatever that may or may not be).

~~~
gfodor
Honestly, how many companies fall into the category of having their data
centers be intimately involved with their product/service? Not very many, to
me.

~~~
thwarted
None, but the point of the OP is that operations is a lot more involved than
racking servers and hitting power switches. There's a wide range of stuff that
between "developer" and "server racking". The things on this spectrum that are
closer to developer are the things that I'm saying are not worth outsourcing,
my previous comments in this thread touch on that.

