Hacker News Reader

Comment by gaius | Hacker News Reader

Yeah, the whole DevOps thing is weird - it's like these guys have forgotten than there was a time when every sysadmin worth his salt was a competent Perl or Tcl programmer who regularly worked on thousand-line scripts for automation. We just took it for granted in the 90s that if a sysadmin needed a tool and didn't have it, he'd make it. One of my former cow-orkers, a dyed in the wool sysadmin, happily used C++ and Motif.

Maybe the sort of "Redhat certified" sysadmin you get these days can't even shell-script and they think this is some radical innovation.

View on HN

> Maybe the sort of "Redhat certified" sysadmin you get these days can't even shell-script and they think this is some radical innovation.

No, sorry. I'm not going to let you get away with that.

Have you ever actually looked at or done any Redhat (sic.) certification? I have. If you compare it to any other certification at all, you will find the exams much much tougher. I passed all of them first time, most (RHCE) or the majority (above RHCE) definitely do not.

I think dragging in Red Hat certification really weakens your argument. What does being Red Hat certified have to do with knowing how to shell script? Nothing at all. If you want someone who can shell script, _ask_them_if_they_can_shell_script_.

It's a simple question, but don't drag down people who've got certifications, particularly this certification, to make your point.

If that is true then why is "DevOps" a new thing? Where is the break in continuity between the old-school sysadmins who did all this stuff anyway, and the new-school who think it even needs a special name (and that they've invented it themselves)?

It's not really a new thing. It's just a new approach and mentality.

It's not new. There was a time, not long ago, where all sysadmins were "devops".

The "new school" is not about operations doing it all themselves, or about a new "devops" position that does both dev and ops. It's about greater cooperation between the team that's developing the application ("dev") and the team that supports it on a day to day basis ("ops"). It's not a new idea, but that doesn't stop it being useful.

If you're working on a team that is responsible for both then devops isn't a useful concept - you're probably doing it already. Many people are not so lucky.

It's a consequence of the Java era where the black-box tendency of apps running in the JVM and the "javaschool" educational system conspired to produce a large number of programmers who could produce web apps, but didn't know anything about administering the boxes they were running on. Thus ops teams started loading up with admins who just made sure the servlet containers could spin up and the underlying machines didn't run out of memory or disk space, but had no idea what was going on inside of the app.

So the argument is that, because one group of people invent the name "DevOps", then all recent sys admins must be like that?

I think it is because most sysadmins didn't study computer science in school, and don't know much about software lifecycle management.

When you have a big complex environment with thousands of servers all running the same code, it makes sense to start treating the hardware itself like software components. All modifications to hardware can be committed to a central SVN repository and pushed out with post-commit scripts. As long as you can script all types of OS patches, firmware updates, etc, using some type of language and an automation tool like Puppet or Cfengine, this can be done.

For a large company like Google or any cloud provider I'm sure it makes sense to start treating your server infrastructure like software components and have the same type of change control, QA, and deployment methodologies wrapped around it.

Just because I know how to script in Perl, can automate my own patch updates, and store my own server and backup information in a MySQL database using DBI and my own hacked together scripts - that doesn't mean that I'm qualified to hack on your production code.

Hell, I don't even have commit access to the corporate SVN repository, so why would you expect me to be a cowboy and fix bugs on production systems?

I'm happy to help automate deployments, etc, but you stay away from my Perl scripts and I'll stay away from your code, thank you very much.

Speaking of; when did mere programmers turn into ninja/rockstar developers instead? (Probably around the same time that 'sysadmins' became incapable of shell scripting.)

Reply on news.ycombinator.com