11–17 of 17 posts
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,…
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,…
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 M…
Earlier quoted context omitted.
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.
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,…
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.
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,…
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 M…
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.
Earlier quoted context omitted.
> 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) o…
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)?
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.
I think DevOps is something more akin to tackling operations problems from a developer's mindset. 'Infrastructure as Code' is a DevOps mantra.
A developer writes a program, runs the program on a compatible platform, and expects a certain output.
I think DevOps is - as an Ops guy you write a program, that program runs on a platform consisting of bare-metal machines, and the expected output is a platform for your developer's software to run on (i.e. configured & monitored web/proxy/db servers)