Devops needs to be a two way street devs and ops(mike-woome.tumblr.com)
mike-woome.tumblr.com
Devops needs to be a two way street devs and ops
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.
3 comments
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.
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.
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.
We are the league of sys admins. We know what we are doing.
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
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
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.
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.
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.
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.
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.
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.
Except that that isn't currently a long view position.
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'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'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.
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.
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.
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).
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.
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.