Hacker News Reader

Comment by inopinatus | Hacker News Reader

I disagree with your disagreement. There's nothing we do under the umbrella of "DevOps" that wasn't part of competent service ownership twenty years ago. I read your article and the point that stood out for me was the notion that the skills to drive tools like chef, puppet are somehow new and different. But I know better, because although I use those tools today, back in the day we used cfengine and a bunch of declaratively/injectively configured shell & perl scripts to achieve basically exactly the same effect.

Back then we called this "systems administration". But we were most definitely working with developers and running the SDLC across silos.

It's nothing new, it's just got a label.

View on HN

As a relatively old guy, I always thought that DevOps was just the new name for what people have always been doing. It is literally just now that I've realised that other people think it is different :-) Possibly younger people don't understand what system administrators used to do...

"Possibly younger people don't understand what system administrators used to do..."

System Administrators used to blame developers. Developers used to blame System Administrators. Devops is in part an attempt to mediate between "silos".

Bad System Administrators used to blame developers. Bad Developers used to blame System Administrators. Real Systems Administrators attempt to mediate between "silos".

therego...

Therefore we need a new title to distinguish "Real System Administrators" from server technicians. So, we get "devops" for people who understand both.

Except in reality we get people who are bad at dev and bad at ops pretending they can do both

You get people who aren't very good in every kind of role in every kind of organization. Sturgeon's Law applies to everything, even people. If you have more than 10% of your team doing really well you're ahead of the game.

DevOps role is different because it assumes full product ownership. Typical system administrators are focused on just the infrastructure portions. In a DevOps role you are more focused on the things running on that infra, as well as the infra. It's a more encompassing role than the traditional 'sysadmin' role.

In the olden days before it became fashionable to outsource everything to "specialist" the sysadmin team often had full product ownership.

You're talking about the difference between sysadmins of the 90s and devops of today. The comment you replied to was talking about the difference between product engineering and operations engineering -- he's defending the idea that devops is a specialization of engineering as a whole. It looks to me like you're right, and the comment you replied to is right, and you seem to be agreeing.

He's not saying that chef and puppet are different because they're new; he's saying that using chef and puppet and docker all day long is a different job than debugging CSS and JavaScript or implementing REST api in scala all day long.

Right, but your parent is saying that job is not some new "DevOps" thing, it is just well functioning operations. "DevOps" is meant to evoke bi-directional buy-in and cooperation between the people working on development and the people working on operations. Re-naming the operations role "DevOps" doesn't get you that - you could still have low buy-in and poor cooperation between development and "DevOps".

I agree, and I agreed with that previous comment and the one before it. But I don't see where the comment I replied to made any reference to the name not doing what it says. I only see him saying that what we call DevOps existed before we called it that.

In any case, of course the name doesn't cause buy-in to happen, just like hiring an "Engineer" doesn't mean the person will do a good job engineering.

You're not saying that we should avoid a term meant to evoke the idea that cooperation is expected, because it might not happen, are you? I can only see rightness in trying to be clear about what's expected and naming roles to suggest positive cooperation is part of the job. If "DevOps" is meant to suggest buy-in and cooperation, you've convinced me that it's a better description than whatever it was called before.

I am saying that using the "DevOps" term for a role undermines the effectiveness of the term as a definition of culture. "I'm just a developer, I don't need to worry about this DevOps stuff, that's what we have the DevOps engineers for!"

Reply on news.ycombinator.com