[vcf-midatlantic] Snipe-It
Dean Notarnicola
dnotarnicola at gmail.com
Fri Nov 30 13:40:51 EST 2018
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
>
More information about the vcf-midatlantic
mailing list