My take on DevOps
standalone-sysadmin.com
My take on DevOps
1–10 of 17 posts
Re: My take on DevOps
#2Maybe 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.
Re: My take on DevOps
#3Maybe 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 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.
Re: My take on DevOps
#4Maybe 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,…
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.
Re: My take on DevOps
#5Maybe 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…
> 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.
Re: My take on DevOps
#6Earlier quoted context omitted.
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…
> 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)?
Re: My take on DevOps
#7Earlier 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)?
It's not really a new thing. It's just a new approach and mentality.
Re: My take on DevOps
#8Earlier 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)?
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.
Re: My take on DevOps
#9Earlier 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)?
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.
Re: My take on DevOps
#10Earlier 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)?
So the argument is that, because one group of people invent the name "DevOps", then all recent sys admins must be like that?