3 ms·
I think the difference is that there were (and still are) many sysadmins who don’t code. So the shift was that there was an expectation that all ops people coul
by prepend 5y ago
I think the difference is that there were (and still are) many sysadmins who don’t code. So the shift was that there was an expectation that all ops people could code.
I don’t think it’s solely a Unix/windows thing, but I still work with windows admins who manually set up machines. Like they set up a vm in azure and then spend hours or days pushing buttons until it’s “ready.” For one vm.
A person like this should not be in ops. They should be trained and improved to automate this by code.
So the world is full of “there’s always been devops” because 30 years ago sysadmins were scripting out their stuff in shell scripts and whatnot. And also “we’re moving to devops” where people still manually do system tasks.
- jlokier 5y agoNowadays some companies have dedicated devops teams who say they don't code. I've been to meetups where I met staff from devops teams who talked about wanting to learn to code in a language like Python someday, to switch into a developer role, and whose response to me telling them I was a C developer was "wow that's really hardcore isn't it". So perhaps there isn't an exceptation that all ops people can code, and perhaps those particular devops teams are not much different from the sysadmins of old.
- prepend 5y agoSimilar with me. But I’ve also met agile teams that put our annual releases and have giant msproject plans. People definitely misuse labels. But I think that devops teams should be people who code.
- dijit 5y agoSysadmins should be people who code too: https://opensource.com/article/17/7/truth-about-sysadmins#:~:text=Sysadmins%20can%20write%20code&text=While%20a%20sysadmin%20isn't,testing%20with%20continuous%20integration%2C%20etc https://opensource.com/article/17/7/truth-about-sysadmins#:~....
- theptip 5y agoIt’s weird. I always thought DevOps meant a philosophy of using traditional agile software development practices (source control, continuous delivery, testing, etc) to make ops processes better. So config as code, instead of maintaining unique snowflakes; cattle over pets; deploy pipelines instead of manual jobs etc. But the term seems to have been diluted into almost meaninglessness as people seem to mean very different things when they say it. SRE is related but my take is it’s an evolution/reaction to DevOps. Some took devops to mean “developers do all the the ops” and SRE puts on-call back onto a dedicated role (so back to the NOC and old school Ops) but keeping (and perhaps even further-emphasizing) the commitment to engineering work in service of automating operations at scale.