3 ms·

Yes. The DevOps people seem to be saying that the sysadmin job will go away, to be replaced only by programmers, but they miss what a sysadmin is - The sysa

by lsc 11y ago

Yes. The DevOps people seem to be saying that the sysadmin job will go away, to be replaced only by programmers, but they miss what a sysadmin is - The sysadmin job has always been about keeping the systems that actually make money up and running after the developers got bored and moved on to newer and cooler technology. (Ugh. I'm actually pretty insulted by the incompleteness of the tools they write in an attempt to replace what they think we do. I was going through some puppet add-on to manage your ssh configuration the other day... it had a setting for "allowrootlogin" - but only allowed "yes" or "no" - no "without-password" - which is the only acceptable setting if you must allow root login at all, which you probably shouldn't.) That's the thing... the uncool stuff that isn't making money goes away. Nobody cares. But the uncool stuff that makes money? Someone needs to actually understand it, long after the developers have moved on to the new technology of the week. Really, the division of labor makes some sense. 90% of everything is crap nobody wants, that can safely be left to die of neglect. So when building a new application, it doesn't really make sense to engineer it to be scalable from the ground up; you're probably going to throw it out before you have to worry about scaling. And maintainability even more so. The way most companies run, five years from now, that app will be huge (and they can throw huge resources at maintaining it) or it will be dead, and the fact that it's difficult to upgrade libraries in it with known security holes won't matter. So let your developers run wild and use whatever unmaintainable crap they feel like using, why not? If it's successful, you can pay someone to deal with the problems later; if it's not, it won't matter, and you will have more developer time to spend on a project that might actually succeed. But say you've got a hit; something that people care about, something that pays the bills. At that point? You hire people like me to prop it up. If you are smart, you hire another set of developers to re-write the system in a way that scales... but meanwhile, you need this giant pile of shitty php to keep serving the ads that pay your salary, so you hire sysadmins. In the aughts, this was all about managing shit php code and corrupt mysql tables. I'm guessing five years from now, at the companies that manage to survive the coming carnage, people like me will be slogging our way through ancient and impossibly tangled VM images, trying to figure out all the weird versions of this and that and the other that the developer installed, and how we can set up something compatible that isn't full of known security holes.

wthigo 11y ago
Sounds like you're mixing up DevOps and NoOps. DevOps is what happens when dev and ops (sysadmins) work more closely together. NoOps is the (probably misguided) notion that sysadmins aren't needed at all
spopejoy 11y ago
"So when building a new application, it doesn't really make sense to engineer it to be scalable from the ground up; you're probably going to throw it out before you have to worry about scaling ... if it's successful, you can pay someone to deal with the problems later" Agree. It's important to iterate quickly and get the intent right and not sweat the small stuff, including whatever notion people have of what's "scalable" which usually is misguided if not a fantasy. Scaling is "a good problem to have" after all; it's only necessary if people are actually using your stuff in the large. Having said that, migrating off of a terrible language is nearly impossible and always painful. Pick stuff with a good runtime -- Java, Go, Haskell, Erlang, C#, whatever -- and you have a chance of scaling if you ever need it.
- lsc 11y ago
  I was going to argue with you; but look at facebook. They started with PHP... instead of re-writing it in something sane, they wrote a better php runtime. So perhaps you are right. It still seems wrong to me, though; it seems like if you've got several orders of magnitude more resources to build version 2 than you had to build version 1, you could re-do it from the ground up in something... better.

by lsc 11y ago

wthigo 11y ago

Sounds like you're mixing up DevOps and NoOps. DevOps is what happens when dev and ops (sysadmins) work more closely together. NoOps is the (probably misguided) notion that sysadmins aren't needed at all

spopejoy 11y ago

"So when building a new application, it doesn't really make sense to engineer it to be scalable from the ground up; you're probably going to throw it out before you have to worry about scaling ... if it's successful, you can pay someone to deal with the problems later" Agree. It's important to iterate quickly and get the intent right and not sweat the small stuff, including whatever notion people have of what's "scalable" which usually is misguided if not a fantasy. Scaling is "a good problem to have" after all; it's only necessary if people are actually using your stuff in the large. Having said that, migrating off of a terrible language is nearly impossible and always painful. Pick stuff with a good runtime -- Java, Go, Haskell, Erlang, C#, whatever -- and you have a chance of scaling if you ever need it.

lsc 11y ago
I was going to argue with you; but look at facebook. They started with PHP... instead of re-writing it in something sane, they wrote a better php runtime. So perhaps you are right. It still seems wrong to me, though; it seems like if you've got several orders of magnitude more resources to build version 2 than you had to build version 1, you could re-do it from the ground up in something... better.