Widespread misunderstanding of cloud from the people who claim that there is a widespread misunderst

[perennate]

We've all heard the complaints: providers are abusing the word "cloud" to market their services; this abuse is perpetuated by customers who don't know what cloud really is; and then so and so platform is not "true cloud".

Those who make these statements (let's call them "misguided cloud fundamentalists") often define an alternative set of requirements for cloud infrastructure-as-a-service platforms. Misguided cloud fundamentalists expect:

• VM's disk to be distributed across multiple host nodes (or even geographic locations)
• Quick failover when the host node goes offline
• Easily scale up/down the VM without downtime or reboot

Yet, the reality is that these requirements are entirely at odds with the expectations of cloud application developers. When you design a large-scale, distributed application, you EXPECT virtual machines to fail, beacuse that's simply the hard reality. In order to provide your customers with high availability and reliable storage, you distribute data across multiple virtual machines in multiple geographic locations at the application level. For these use cases (which are as close to the core of "cloud" as you can get), a single virtual machine cannot possibly provide the necessary throughput for the system. Thus, it becomes silly to worry about minimizing the failure of individual virtual machines; rather, the application is designed to scale across a large number of VMs and tolerate frequent failures.

These expectations that actual cloud application developers have is supported by definitions of "cloud" by standards organizations. As DomainBop helpfully pointed out in another thread, the National Institute of Standards and Technology in the United States provides a much more reasonable definition of cloud computing:

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured Service); three service models (Cloud Software as a Service (SaaS), Cloud Platform as a Service (PaaS), Cloud Infrastructure as a Service (IaaS)); and, four deployment models (Private cloud, Community cloud, Public cloud, Hybrid cloud). Key enabling technologies include: (1) fast wide-area networks, (2) powerful, inexpensive server computers, and (3) high-performance virtualization for commodity hardware.

Here, NIST is arguing ("on-demand self service", "rapid elasticity") that the most important feature of a cloud platform is on-demand, automatic horizontal scalability, i.e., we can provision and destroy virtual machines on the fly via an API. Nothing is said about the reliability or availability of individual virtual machines.

(Note that Digital Ocean, Vultr, and many other services labeled "fake cloud" by misguided cloud fundamentalists in fact provide these features.)

Indeed, there are no providers to my knowledge that provide the sort of "cloud" that misguided cloud fundamentalists desire. Achieving failover with sub-second downtimes necessitates the usage of primary-backup replication systems like Remus. Do you know any providers using Remus? I certainly don't. Similarly, scaling up/down VMs without a reboot generally requires a container-based virtualization technology; cloud application developers generally prefer fully virtualized machines as they offer greater isolation, customizability, and infrastructure-level features (i.e., it's easier to support live migrations, distributed disk storage, primary-backup failover, and virtual networking when the kernel itself is virtualized).

(As far as I know (the documentation isn't very clear), most container-based live migration require suspension of processes while the filesystem and other VM state are being migrated. On the other hand, block migration in KVM does a streaming copy where we copy the disk online until the source/destination are synchronized. Similarly, connecting with block storage like Ceph RADOS cluster is simply unheard of.)

Personally, I think all attempts to define "cloud" (and thereby restrict it's meaning) are flawed. First, even the most reasonable of definitions (including NIST's above) are made useless by the fact that cloud computing covers three distinct service models (as mentioned in the definition): software services like DuckDuckGo and Reddit, platform services like Heroku and Google App Engine, and infrastructure services that we usually talk about on this forum. Second, academics only use the term "cloud" to refer to a broad set of ideas like horizontal scalability, fault tolerance, and high availability in a distributed system; not with any specific technical definition. That's what "cloud" really is, a broad set of ideas.

Third, and most importantly, no one cares. Definitions are supposed to be accepted by the majority. If the majority uses "cloud" in a different and overly broad way, then the definition must change and broaden.

But ah, who can go against the "true definition" of cloud?

What do you think?

 

[drmike]

I think definitions aside (but appreciated) cloud is nearly always on and able to be ported to and self moved and redeployed ideally automagically in same DC but emphasis on other DCs.  DC1 goes pop, no matter, your container is alive in DC2.  Elastic is a key word and it's not just resource scaling, but surviving down time.

To have just one location is not cloud.  To have no fail over in case of outage at a DC or hardware failure isn't cloud.

NIST fubared definition of "On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured Service"  is sufficient.

The point all tend to fail on the NIST definition is on BROAD NETWORK ACCESS.   The term is flawed and I think not what it appears.  Elastic and on demand are convienence to grow or start what you want when you want (more containers, more disk, etc.).  What is inferred by BROAD NETWORK ACCESS is this flexibility and redundancy of multiple DCs.  This is redundancy to SURVIVE outtage, not just the idea that a host has multiple DCs.   Interconnecting them and making it work seamlessly and redundtly is the key.

The lack of some detailed spec doesn't mean any bullshit factory should be able to claim they are cloud or infer it  with cutesy graphical top dressing.

I also note that your angle here is to say cloud is about multiple VMs running with layer of customer built redundancy (I pick LAX + NYC + ATL and run three instances live and put 2-3 load distributing front ends out there).  This is high availability and heaped upon customer.  We've been building stuff like this for 20 years.  It's not cloud.  It existed long before cloud. 

High availability self distributed is all plumbing and mechanics on customer to rig the shit.   It's very ummm problematic unless usually dealing with full servers and additional resources.  Not really a VM play (although can do a lot with VMs).

Cloud is a provider thing, single solution that cooks in high availability without the external DIY stuff customers have been doing.

But as a purist and realist, Cloud + DIY High Availability is where the sane will be.  Single provider can go tits up at any time and for any reason.

 

[perennate]

I also note that your angle here is to say cloud is about multiple VMs running with layer of customer built redundancy (I pick LAX + NYC + ATL and run three instances live and put 2-3 load distributing front ends out there).  This is high availability and heaped upon customer.  We've been building stuff like this for 20 years.  It's not cloud.  It existed long before cloud.

Customer must build in availability/redundancy, these are impossible to reliably implement without sacrificing performance below the application level. It may have been done for a while, but customers had to maintain their own infrastructures, and increasing capacity meant buying more servers. Cloud computing at its core is a set of old ideas re-applied on an externally maintained platform that provides rapid scalability.

Either way, very few providers actually allow failover to a completely separate datacenter; this requires either something like Remus (which as I mentioned, no one uses in practice) or distributed storage between datacenters; such distributed storage is slow, and cloud application developers don't want to sacrifice single-VM performance for single-VM availability.

Also keep in mind that even with distributed storage, we still have five minutes or so of downtime to detect the outage and reboot the virtual machine in another host node or datacenter. For scalable applications, the VM might as well be destroyed and re-provisioned; by the time it comes back online data will have already been re-balanced.

(It's like RAID, we're always going to need something more on top of it to handle failures and outages, but RAID increases reliability, while simultaneously increasing performance. Distributing storage across datacenters decreases performance.)

The point all tend to fail on the NIST definition is on BROAD NETWORK ACCESS.   The term is flawed and I think not what it appears.  Elastic and on demand are convienence to grow or start what you want when you want (more containers, more disk, etc.).  What is inferred by BROAD NETWORK ACCESS is this flexibility and redundancy of multiple DCs.  This is redundancy to SURVIVE outtage, not just the idea that a host has multiple DCs.   Interconnecting them and making it work seamlessly and redundtly is the key.

There is more than I quoted, the full definition is at http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

About broad network access they say:

Capabilities are accessed over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).

It's not targeting the infrastructure as a service model.

Regarding elasticity, I think of that exclusively as provisioning and destroying on the fly (as does NIST in their full definition).

At any rate, above all I think it's pointless to debate about the meaning of cloud since it really doesn't matter. A definition must reflect common usage of a term, and cloud is used so broadly that the definition must be correspondingly broad. Rather than argue that cloud should have so and so specific meaning (especially when the applications that are most often considered cloud don't use VMs that fit that meaning) and getting riled up whenever some "bullshit factory" markets themselves as "cloud", we should promote usage of accurate terms that actually have specific definitions like "distributed storage over multiple datacenters", "primary-backup failover in separate datacenters" (Remus), or "live snapshots".

 

[KuJoe]

People who complain about the usage of the word "cloud" are just scared of the cloud and those of us who aren't bothered by words.

 

[host4go]

consider this....

IBM CEO once said that cloud is a marketing term, and then gave the example of the "ghost" workstations (or whatever terms you use for the monitor+keyboard workstation kept alive by a server) which is not new tech.

Cloud is the fancy cousin of "unlimited HD". Fancy because its possible but costly, and lets be honest most (all?) companies that sell cloud are really selling VPSs with a better billing\vps manager.

now now.. I'm on a phone so play nice with me

 

[drmike]

Either way, very few providers actually allow failover to a completely separate datacenter; this requires either something like Remus (which as I mentioned, no one uses in practice) or distributed storage between datacenters; such distributed storage is slow, and cloud application developers don't want to sacrifice single-VM performance for single-VM availability.

Also keep in mind that even with distributed storage, we still have five minutes or so of downtime to detect the outage and reboot the virtual machine in another host node or datacenter. For scalable applications, the VM might as well be destroyed and re-provisioned; by the time it comes back online data will have already been re-balanced.

(It's like RAID, we're always going to need something more on top of it to handle failures and outages, but RAID increases reliability, while simultaneously increasing performance. Distributing storage across datacenters decreases performance.)

At any rate, above all I think it's pointless to debate about the meaning of cloud since it really doesn't matter.

A definition must reflect common usage of a term, and cloud is used so broadly that the definition must be correspondingly broad. Rather than argue that cloud should have so and so specific meaning (especially when the applications that are most often considered cloud don't use VMs that fit that meaning) and getting riled up whenever some "bullshit factory" markets themselves as "cloud", we should promote usage of accurate terms that actually have specific definitions like "distributed storage over multiple datacenters", "primary-backup failover in separate datacenters" (Remus), or "live snapshots".

I'll start by saying words having meanings.  Even if idiots and snake oil salesmen use such words over and over with great conviction.  The common definition by use of cloud is buzzword bingo stabbing in the dark to ride the fad wave with the rest of the inept.  It means literally nothing in today's use.   I see hordes of OpenVZ with cloud names all the time and graphics to infer such.  Not even close to being cloud by any stretch of the imagination.

The origins of cloud appear to be a billing model for ala carte consumption of digital content.  Pure marketing bullshit.  http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=75291765  Single bill get your PPV, get your data use, maybe throw a pizza in there too.

"Either way, very few providers actually allow failover to a completely separate datacenter; this requires either something like Remus (which as I mentioned, no one uses in practice) or distributed storage between datacenters; such distributed storage is slow, and cloud application developers don't want to sacrifice single-VM performance for single-VM availability."

And for this reason they are not cloud.  They are overly bullshitified virtual machines most often with a bit more software management stack mods.  They are no more cloud than shared hosting was circa 1998.

Having per hour billing plan doesn't convert a VM or VPS into being a cloud either.  Nor do pool resources.

This --> "cloud application developers don't want to sacrifice single-VM performance for single-VM availability" assumes that devs care about performance benchmarks in a bad way.  Rolling redundancy dev side across multiple providers isn't exactly a good utilization of time or resources.  It's entirely the wrong layer and inefficient.  People continue to do such out of necessity and failure of 'cloud' to actually deliver, be elastic, be redundant, etc.

As implemented today, Cloud mostly means the very same old hosting maybe with hourly billing.  Requires end customer to plumb and automate and manage everything.  It's about no difference than a vanilla OpenVZ shops with API access plus a reseller style pool of resources to at-will launch containers.

So remind me again why these shops are selling cloud?  Other than to be misleading hipsters?

I say we stop calling this crap CLOUD and call it what it really is VAPOR.

 

[Hxxx]

I think drmike nailed it.

But first why we have 2 threads about the word cloud?

Cloud nowadays = hourly billing.   Simple as that. In the end i think we shouldn't care. The people that wants any kind of high redundancy and availability usually have the money to invest into a private infrastructure.

So If we were to really do genuine cloud, it would just cost a lot more. There would be no such thing as budget cloud or cheap cloud. 

So maybe a provider like Linode should be classified as Instant Computing, because that's just what it is. Spin resources and do. Cancel next day or leave it on.

There is also the movement. Remember that anything online is now called cloud. The cloud app, the cloud backup, the cloud hosting, etc. Companies are just riding with the move. If by any reason the cloud term lose popularity probably the majority of these so called cloud hosting (which i don't mind, for me is just fine, is all about computing) will no longer have the cloud term and upgrade their name to the next popular term. How about containers? online containers? The docker movement is OP.

 

[HN-Matt]

I'll start by saying words having meanings.  Even if idiots and snake oil salesmen use such words over and over with great conviction.  The common definition by use of cloud is buzzword bingo stabbing in the dark to ride the fad wave with the rest of the inept.  It means literally nothing in today's use.

True meaning of cloud:

 

[HN-Matt]

But as a purist and realist, Cloud + DIY High Availability is where the sane will be. 

If your sense of 'cloud' can't be acquired inexpensively, doesn't your definition of 'sane' suddenly become meaningless?

Relegating sanity to monied HA la la land would be quite stupid...

 

[drmike]

But as a purist and realist, Cloud + DIY High Availability is where the sane will be. 

If your sense of 'cloud' can't be acquired inexpensively, doesn't your definition of 'sane' suddenly become meaningless?

Relegating sanity to monied HA la la land would be quite stupid...

Anyone selling 'cloud' and actually intending on building something that resembles such is going to find themselves with sticker shock.

It isn't an el cheapo random E3 on a mutant network sitting as an island with an OVZ + Solus stack.  Need big cores, big RAM, fast back plane innerconnects.  Gbit isn't cutting it.  SAN over Gbit, isn't really cutting it either.  Talking about a quarter rack of gear low side.  Sure you can self cobble some Raspberry Pi's and have a low performance pretend-a-cloud for hobby stuff.  But as always we are speaking of providing a service to customers and a reusable platform that is multi-tenant and flexible to some degree (scale at will).

Anyone giving half a real thought to cloud - true technical folks - the customers who are smart businesses you actually want - and who pay amounts one can sustain a business from - want real cloud functionality on the software control layer and hardware implementation that at least tries to be a cloud.  Talking about front end servers at this point that are $5-10k low side frugally bought, EACH.    That's why the plethora of ARM solutions with many cores and many CPUs in tight density with fast back connects are so appealing to me.   Because I get to come down off Intel enterprise solutions and their cost into something with inferior CPUs, but a lot of them and cores and do so at a huge cost savings ---- well conceptually --- if ARM stuff wants to actually sell.

 

[joepie91]

I'm going to stick with "there is not a single supposedly 'cloud' concept that cannot be expressed more precisely, so how about we stop using the term 'cloud' altogether?"

 

[HN-Matt]

I don't think competent, stable, blah blah highly performing cloud infrastructure can be done for cheap either. I was only saying it can't possibly hold any claim to the word sanity after all the money has been spent on achieving it and catering to the higher-end market that needs it without coming off as ridiculously classist and so on (pecuniary != sanity). It's likely that no one wants to approach it from that angle, but you said "I'll start by saying words having meanings" so I was responding to that. What you perceive as 'fake clouds' probably appear in large part because 'true clouds' are not affordable enough for the common man's symlink realism, but they want to feel/pretend otherwise (and it isn't because they're not sane). I mean, what happens if after inheriting the earth, the meek clouds join forces with the kitsch clouds and begin to sublate all of the Wizard of Oz clouds into their combined will?

 

[drmike]

It's not about spending money and coming off as classist.  I am not a provider nor do I suscribe to classism and some might infer I just have no class.

The only high-end there is in this conversation truly is high demand customers.  Those that expect more 9's on uptime, expect a robust platform, expect responsive support, proactive plumbing and a real SLA.

Do those demands cost more?  Certainly.  Reason why you aren't seeing real SANS and fast interconnects on low cost money.  Real SLAs are hard to find too.

In many ways, cheap only happens in the VPS world because corners are cut, humans eliminated and the whole shop is ran less seriously than a hobby.  Vanilla VPS isn't cheap from a provider side either.  It's only via creative downward pressure via leasing and credit lines + older gear + limited support that most providers can even swing a bat at the business.  Most DCs out there would laugh their heads off about the prices we see on the cheap side and the give away the DC rack pricing.  Are they out of touch?  I think not as they don't need to dip to silly price wars as their sole gimmick to make sales or dressing crap up and tossing the cloud banner over it.

Often we'll hear (lesser so on this site) about how customers were unrealistic and writing was on wall about whatever crazy offer selling the moon for less than a piece of pie a month. On the cloud side, companies are tangoing with different animals.  Those customers won't come near cheap no matter how many times it pretends to be such, no matter if you are the leading provider in the cheap world, or whatever feather pumping a company has.

Does the common man doink around in hosting and have a need for cloud?  Hardly.  The common man might end up here for game hosting, which is still a dedicated resource play or vanilla VPS if your nodes can handle it.  Arguably nothing hosted is affordable.  By the time you factor in company fail rates, data loss risk, time wasted on frivilous problems due to bad providers and servers that are mismanaged, etc.  it represents quite a bit even though the fake commodity is cheap.  Time is money and even to the slackers, they value their TV and screw around time.   Do they value it enough to catapult them from $7/mo to $70?   Depends. 

Real businesses though, they buy all day at the higher numbers.  That's where the money is.  That's where cloud actually is.  Plenty of snakeoil there as well and people who are enhancing their sales pitches for maximum profit via deception.

Doing provider side of cloud on the cheap.  Good luck.  Like I said, a bunch of owned gear... Lots of drives... fast connections on backplane.  Better cozy up to a routing platform too.  I like affordable like the next frugal person.  Cheap I freaking detest because of the cancer it is in most things.  Cloud and redundancy is anything but cheap.  Even affordable it isn't.  Cloud and redundancy are for big boys running or growing real businesses where downtime actually means lost revenue.

 

[HN-Matt]

The planet's surface now appeared like streaky bacon, by reason of its cloud-zones. Clouds fogged its whole circumference. Now I drew abreast of it and passed it. Owing to the immense depth of its atmosphere, night and day merged into one another without assignable boundary. I noted here and there on its eastern and unilluminated hemisphere vague areas of ruddy light, which were perhaps the glow cast upwards through dense clouds by volcanic upheavals.