[vcf-midatlantic] Snipe-It

[Dean Notarnicola]

Nicely put. I will point out however, that I did say it's someone else's
computer, but that's not the only thing it is. That was the point of my
diatribe. Anyone can create their own elastic cloud in-house, so you don't
need to rely on someone else to realize the benefits.

I would argue that, although akin to timesharing, there's an important
distinction from "classic" timesharing by virtue of availability of elastic
resources.

Finally, I should have added that I would most certainly not recommend this
for VCF, as it's not suitable to the task at hand.





On Fri, Nov 30, 2018 at 1:21 PM Dave McGuire via vcf-midatlantic <
vcf-midatlantic at lists.vcfed.org> wrote:

> On 11/30/18 7:09 AM, Dean Notarnicola via vcf-midatlantic wrote:
> > I'm not going to argue with anyone's points here, as they are all valid.
> > I've also been in IT for 35+ years and have built and maintained days
> > centers. The only thing I will contradict is the idea that cloud is just
> > "someone else's computer." Yes, they belong to someone else.
>
>   Not to be argumentative, but I will emphasize that this was the point
> I was making.  Those computers do, in fact, belong to someone else.
> They are sitting in a building(s) that belong to someone else.  And
> someone else controls them, and someone else is responsible for their
> maintenance, in every respect.
>
> > However, cloud (by definition) is not timesharing, it is not co-location.
>
>   I agree that it's not co-location, but I'd ask you to tell me how,
> exactly, it isn't timesharing.  Elastic, capacity-on-demand
> functionality is typically implemented using virtual machines, with
> behind-the-scenes migration of VMs from host to host, in response to
> hardware failures, reorganization, or just plain moment-to-moment
> operating conditions.  We all know that...and I know YOU know that; I'm
> not "talking down" to you here.  My point is, your VMs are sharing a
> machine, or a set of machines, and mass storage, in the larger sense.
> It's not likely that any (smaller) customer of such a service provider
> will have any visibility into exactly where their VM lives and what else
> is running on that processor core at any given time.
>
>   This is, by definition, timesharing.  If you disagree, I'd love to
> hear your point of view as to why.
>
>   Now, if you are a big enough customer to have a "nobody else on this
> hardware" deal with the provider, that's great...and moves it a big step
> closer to being co-location.  Admittedly though, not completely so, but
> I couldn't not point it out. ;)
>
> > One of the
> > benefits of cloud computing is to offer nearly instant elastic, on demand
> > resources for variable workloads, such as software development, seasonal
> or
> > other intermittent tasks. Traditionally, we would overbuild our data
> center
> > to handle these things and as a result, 80% of our resources would be at
> > 10% to 20% utilization for the majority of the year, wasting energy,
> space
> > and the time of our staff to maintain them. To be sure, we keep core,
> > business critical systems on prem (with HA and DR in co-lo) but that's
> ~5%
> > of our infrastructure. After extensive risk analysis, we are able to put
> > everything else in cloud, with the proper security and availability
> > controls that meet our needs (we are a pharmaceutical company and most
> > maintain GxP environments.) As a result, we only pay for the resources we
> > actually utilize, can allocate and de-allocate resources on demand. As
> > well, our lean IT staff can concentrate on higher value work.
>
>   The benefits are huge, only a moron would dispute that.  It's
> incredible, the things a modern VM-based hosting network can do, and the
> benefits to their customers are very real and absolutely huge.
>
>   But those benefits do not come without a cost: Direct control over
> just about everything is lost.  Some suitly types may say that this is a
> good thing, but I personally would never accept that.  That is one of
> the reasons I left the business of "big I.T."  Decisions are now being
> made exclusively for suitly reasons, not technical reasons.  We all
> remember the beginnings of this, when suits in charge of I.T. started
> valuing contracts over OS source code licenses.  They don't want ways to
> fix things quickly, they want someone to scream at when it breaks.  I'm
> a technical person; I don't work that way.
>
>   You said above that your core business-critical systems are kept
> in-house, and for you, that's about 5% of your infrastructure.  In my
> case, my core business-critical systems are about 80% of my
> infrastructure.  In other words, my mileage did, in fact, vary.
>
>   For that other 20%, I'm envisioning of all the idiots I've interviewed
> and rejected in the past, who went on to work for Rackspace...I'll keep
> that 20% in-house, thanks. ;)
>
>   Further, benefits or not, it's still "someone else's computer".
>
> > To be sure, cloud is not a magic bullet. Getting true value from it
> > requires due diligence in knowing your compute environment, your business
> > and security needs, and creating/maintaining proper governance and
> > controls. It may not be cheaper, but done properly can be more efficient
> > and result in a much more agile infrastructure. Again, YMMV.
>
>   Agreed on all points.  But VCF is neither Netflix, AirBNB, Atlassian,
> nor a pharmaceutical company.  The moment VCF's internal operations
> begin to depend on an agile infrastructure with capacity-on-demand etc,
> I'm sure things will be looked at a bit differently.
>
> > Tread lightly :-)
>
>   You've met me, right? ;)
>
>        -Dave
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
>