[RndTbl] Attempted murder of sysadmin

[Kevin McGregor]

I didn't want to say anything because I don't have a lot more to say than
"Ditto. What he said."

I will point out (sorry if I missed it in your voluminous contributions ;-)
) that much of the original goal was to reduce numbers of servers and
* reduce power usage
* reduce cooling requirements
* reduce running up and down many aisles of many tower computers checking
and replacing hard drives
* reduce stranded assets i.e. servers with big hard drives hardly being
used; servers with lots of RAM hardly being used; servers with mostly-idle
CPUs

Of course where I work we have many blades, all of which are typically at
10-25% CPU usage. Also, no one is checking on how much of the assigned RAM
is actually in use. VMware isn't too bad at monitoring actual RAM usage and
letting one oversubscribe RAM without much of a performance hit, but
there's still overhead in the management. Oracle VM on SPARC (at least)
doesn't allow oversubscription of CPU or RAM *at all*, simplifying that,
but then ending up with... stranded assets: idle CPUs and unused RAM.

It was probably later when someone thought "We can sell this as a way to
reduce head-count!"

I think it will go in cycles. As in
- "Hey, we can use all these technologies to reduce head-count!"
- "Oh, I guess we still need them."
- "Hey, we can use all these technologies to reduce head-count!"
- "Oh, I guess we still need them."
- "Hey, we can use all these technologies to reduce head-count!"
- "Oh, I guess we still need them."
And so on.

On Mon, Jul 10, 2017 at 1:27 AM, Trevor Cordes <trevor at tecnopolis.ca> wrote:

> On 2017-07-09 Adam Thompson wrote:
> > > I mean, look at docker or flatpacks or even VMs.  These things are
> > > the opposite of what we spent 30 years working against...
> > > duplication.  So
> >
> > Don't forget that Docker images can't be updated.  Ever.  (You have
> > to replace the entire image with a new image that contains updated
> > components.) So for any (i.e. most) orgs that create a docker image,
> > think "Cool!" and deploy it into production - never to be updated
> > again - I foresee massive swarms of 'bots in the future, that
> > basically can't be fixed.
>
> Good point!
>
> > > now we have the same/similar 100-thousand OS files duplicated
> > > everywhere.  Now they want to undo the entire concept of shared
> > > libraries and essentially make libs static again (well, shared but
> > > distribute specific lib versions with the apps, duplicating out the
> > > wazoo).  For an efficiency purist it seems insane.
> >
> > Yup.
> > There's deduplicating storage, which helps somewhat...
> > But yeah, Docker takes that downside to VMs and magnifies it 100-fold.
> > (In the case of VMs, the files would have been duplicated anyway -
> > just on another physical server & physical disk.)
>
> Ya, but more worrying is what I alluded to: duplication in memory.
> Wouldn't techs like Docker mean that you lose the shared library
> effect?  Instead of each app instance taking about 20% real memory
> (with 80% shared), each app takes 100% of its own footprint, no?
> Dedupe might fix it (somewhat) on the disk, but won't fix it in RAM,
> which is far more precious than disk (still).
>
> > I don't know about you, but I've never actually met any of these
> > mythical $100k rainbow unicorns.  I get paid less than some of the
> > developers at my company.
>
> Yearly industry surveys.  Sr. sysadmins are always 80-110k.  Of course,
> this is in the USA (converted to CA$).  Wpg prices obviously vary :-)
>
> > > Bonus question: What happens the day AWS (or whatever) screws up /
> > > has a major data loss / some other calamity?  You sure are putting
> > > a lot of trust in *their* sysadmins, who may not be as smart as you
> > > are!
> >
> > It's happened more than once already.  And it's OK, because there's a
> > 3rd-party to blame.  (Well, it's not "OK", but no-one gets fired for
>
> I was thinking more along the lines of data loss or massive hacker
> infiltration/data theft.  Outages, meh; data loss, maybe not so meh.  I
> await that day to see industry reaction, dropped jaws, fired CIOs, etc.
>
> > So I don't really care if the "system administrator" dies off.  In
> > many ways, that should be a goal for our industry, not something to
> > be feared.  It's pathetic that we still can't produce reasonably
> > bug-free systems that interoperate with each other in a plug-and-play
>
> I'm not so sure it's pathetic.  It's probably a result of the insane
> complexity of every system.  Just to browse the web on a phone you're
> relying on, what, 20-40 million lines of code?  Laymen don't understand,
> know or appreciate the insane complexity behind "simple" computer
> things.  I talk to my wife about this occasionally and she can't even
> begin to "get it" (not for lack of brains, either); why doesn't is "just
> work", "shouldn't be so complicated".  One could posit that we will
> never be "bug free" (in fact, bugs seem to grow over time), and
> completely "easy" (just "easier", at least we are winning there).
>
> ... ah, but you answered your own question...
>
> > (Oh, and it's not just sysadmins.  Remember "visual programming"?
> > Each time it gets reinvented, it's going to let business users do
> > their own programming and get rid of all those overpaid programmers.
> > Yeah, right.  I still see lots of programmers.  Just, hardly any of
> > them write in assembler or COBOL anymore.  Although 4GLs haven't
> > exactly taken over the world...)
>
> Simplifying programming and firing all the programmers is the same
> pipe dream as "bug-free systems".  They have the same root cause.  It's
> the same class of problem.  There's probably a mathematical way to
> state / model all of this and it's probably the same equation.  It's
> probably NP-complete and will never be solved.  I'll bet money on it.
>
> I laugh at all the news sites/papers/shows being filled with
> "automation / AI" job-loss doom-porn all the time these days.  I laugh
> even harder when they proclaim the imminent elimination of
> programmers.  Never going to happen, and I'll bet money on that too.  In
> my lifetime I can remember: (circa 2000) UML "killing all the
> programmers"; then I heard some APL wizadry would do it; now it's AI
> (and probably many more I never got wind of).
>
> For us programmers out there (lucky me, I'm 50/50 programmer/admin),
> don't worry about this nonsense, because it's never going to happen.
> Levels may get higher, but someone still must think through all the
> corner cases and gotchas and flows and bugs, or just plain elicit the
> #%!@$ specs from the stakeholders!  If you think AI can program another
> kernel like Linux, or a new Firefox, or your next e-commerce idea, dream
> on, and I'll take that bet too.
>
> Nice reply, Adam, guess the rest of MUUG is off to the cottage, or not
> an admin, or too busy shaking in their boots to reply :-)  As we both
> said, no reason for anyone to get scared about any of this stuff as
> long as your skillset is deep and wide.
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.ca
> https://muug.ca/mailman/listinfo/roundtable
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://muug.ca/pipermail/roundtable/attachments/20170711/3604a8c7/attachment.html>