Hacker News Reader

Comment by wccrawford | Hacker News Reader

Maybe I'm retarded or something, but I can't imagine having a development team that doesn't interact strongly with operations.

How do you know what software to build? Operations.

Who uses the software and reports bugs and makes suggestions? Operations.

Without Operations, I'd just be sitting here twiddling my thumbs.

Of course, if you are developing software for other companies, you need to work through the channels, and I could see them not allowing communications directly with their operations personnel. But if it's the same company and you can't communicate, shame on everyone.

View on HN

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.

> 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.

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

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.

This isn't the problem. The issue is that from the insular perspective of most dev teams in most IT orgs, "Ops" is extremely fragmented. This fragmentation results in the "Devs" only getting a fraction of the picture, and this results in a patchwork quilt of hacked together code.

The solution is to encourage high quality communication at the stakeholder level and force that high quality communication downward throughout the chain of command. Most people are crappy communicators, and that results directly in the need for articles like the linked one.

Uh- raise your hand if you've ever worked in development or operations on any enterprise CRUD apps. 90% of the companies I've worked for, from a systems architect and operations point of view, the developers never told us a thing, except when to deploy updates.

I'm sure it is the same from both sides- we usually didn't tell them what type of back-end storage we were putting their database on, and they didn't tell us how hard they were hitting our database. It's pretty much messed up. I would kill for a good DevOps relationship, but most organizations are so dysfunctional that giving out too much information to other departments is considered a bad thing...

Like the developers that put outer joins into production code and then wonder why everything is slow. It takes a DBA to analyze it and say "stop doing that" before the developer tells us what they were trying to do in the first place. It would be nice if more communication happened, but in corporate America, it is not about to happen any time soon.

My thought is that the development department just doesn't want to show the rest of the company how bad of shape the code base actually is in, and the operations team just doesn't want to show the rest of the company how bad of shape the servers, storage, and network is in.

Reply on news.ycombinator.com