[RndTbl] Attempted murder of sysadmin

[Adam Thompson]

I mostly agree.

 

Although per-minute billing has yet to be a useful feature to me or any of my clients – none of us are equipped, or even have the need – to operate “at scale” in that manner.  Cloud’s ability to scale quickly, tear down quickly, etc. is really only meaningful to orgs and applications that have made the jump to distributed, composable, microservices.  My estimation is that represents less than 1% of the mechanized (computerized) processes in existence.  Those <1% are highly visible, however (i.e. Netflix).  I still spend my days managing large, monolithic systems – even though they happen to be virtualized or running on “someone else’s servers”.

 

There’s an excellent recent discussion on legacy vs. cloud architecture on JWZ’s (of Netscape, Mozilla, and xscreensaver fame among others) blog: https://www.jwz.org/blog/2017/06/dear-lazyweb-tell-me-about-colo/, and his followup post https://www.jwz.org/blog/2017/06/colo-again/.  The discussion actually takes place in the comments, which – particularly for a public comments section on a public blog – are surprisingly readable and polite!  (Hint: JWZ doesn’t like cloud architecture any more than I do.  It’s still an interesting read.)

 

As to Docker: yes, I understand the theory.  I just believe that we’ll see a raft of businesses deploying Docker (&c.) images without really understanding the ramifications, and then the Docker evangelist will leave or get promoted or whatever, and we’ll be left with millions of unmanaged, unmaintained services because not only aren’t they getting patched (which is the whole point, yes) but they *also* aren’t getting replaced with updated images.  Never underestimate the power of inertia!

 

Meanwhile, yes, I take advantage of Other People’s Servers and Other People’s Bandwidth and Other People’s UPSes, and etc. because  you’re right: managing UPSes and HVAC and all the other necessary-but-not-sufficient stuff is a pain in the butt that I’d rather not have to deal with.  That doesn’t mean I have to buy into the Cloud “swam” concept at all, mostly because it’s irrelevant to me.  And I’m not at all convinced that requiring swarms of immutable VMs to achieve scalability & reliability is a sound architectural choice in the first place – it seems like a reaction, not a design.

 

(and *whoosh* there we went off on a different tangent altogether)

 

While I agree that Trevor’s initial discussion could serve as a proxy for some old technical arguments (local vs remote datacenter, rent vs own, etc.) I don’t think the reverse is true.  The original concern was that we seem to have targets painted on our backs as a group, for some reason.  Which is true – and the reason is that most HR people (in my experience) can’t understand what a system administrator *is*, can’t figure out how to hire them effectively, and as highly-skilled, highly-mobile/portable, highly-paid individuals, that coupled with the difficulty of hiring good admins, inherently makes us a business risk.  So of course the “business” is going to respond well to anything that claims to reduce that risk or that cost.

 

Naturally, that ignores the fact that then you need an AWS jockey, or an Azure admin, or a Docker expert, all of which are equally/more difficult to find, equally/more highly-paid, and have equally/more portable skill sets.  But who ever accused groupthink of looking past the immediate payoff? ;-)

 

-Adam

 

 

From: Roundtable [mailto:roundtable-bounces at muug.ca] On Behalf Of John Lange
Sent: July 13, 2017 10:31
To: Continuation of Round Table discussion <roundtable at muug.ca>
Subject: Re: [RndTbl] Attempted murder of sysadmin

 

You guys covered a lot of ground in your discussion and for the sake of time I won't comment on every point, but basically what you're discussing is the business case for "Cloud" vs. on-prem.

 

In short, the "Cloud" reduces the complexity of operations while increasing agility and scale-ability.

 

Cloud reduces complexity by eliminating the management of the infrastructure. You no longer have to worry about servers, storage, power, cooling, network switches, cabling, virtualization etc. etc. etc. (not to mention making all of the above redundant). This is a massive win for I.T. operations because it lifts the burden of the most time consuming and expensive part of operations (building and operating data centers). Most admins also don't enjoy swapping UPS batteries and testing HVAC systems so double win!

 

Cloud increases agility because it's all billed per-minute. You no longer need to go through a multi-month (year?) process to add a new service. You just click. You can add hundreds of servers to your environment in seconds then turn them off again 5 minutes later. There is no equivalent of that in any other environment.

 

Cloud increases scale-ability because day-to-day maintenance tasks like monitoring and patching can all be automated. So while it's fine to say you can spin up 100 new servers in 5 minutes, that's not a good thing unless you have a way to manage all that new compute. Cloud has you covered.

 

Or think of it this way, Cloud is your way to access the most sophisticated & robust I.T. infrastructure and management solutions available. Solutions that, until Cloud, were only available to the worlds largest organizations (and even they struggle to cope).

 

"Cloud" is like buying a plane ticket. You don't just get a seat on a plane, you get a "slice" of all the complex operations that happen in the background to get you from point-A to point-B safely (air traffic control, airport maintenance, airplane maintenance, etc. etc. etc.) Think of what a different world it would be if we didn't have a "Cloud" of airplanes in the sky to utilize.

 

Now a quick side-bar on containers (e.g. Docker). The whole point is that they don't get updated. If there is a new version of your code, you push it out to a new "swarm" of containers and all the old ones get torn down. It's easy and that's the whole point. If you had to do patch management on containers, now you're effectively just turning them back into VMs and that defeats the whole purpose.

 

John

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://muug.ca/pipermail/roundtable/attachments/20170713/7b5e6b46/attachment-0001.html>