Cloud: The Other White Meat…On Service Failures & Hysterics
Cloud: the other white meat…
To me, cloud is the “other white meat” to the Internet’s array of widely-available chicken parts. Both are tasty and if I order parmigiana made with either, they may even look or taste the same. If someone orders it in a restaurant, all they say they care about is how it tastes and how much they paid for it. They simply trust that it’s prepared properly and hygienically. The cook, on the other hand, cares about the ingredients that went into making it, its preparation and delivery. Expectations are critical on both sides of the table.
It’s all a matter of perspective.
Over the last few days I have engaged in spirited debate regarding cloud computing with really smart people whose opinions I value but wholeheartedly disagree with.
The genesis of these debates stem from enduring yet another in what seems like a never-ending series of “XYZ Fails: End of Cloud Computing” stories, endlessly retweeted and regurgitated by the “press” and people who frankly wouldn’t know cloud from a hole in the (fire)wall.
When I (and others) have pointed out that a particular offering is not cloud-based for the purpose of dampening the madness and restoring calm, I have been surprised by people attempting to suggest that basically anything connected to the Internet that a “consumer” can outsource operations to is cloud computing.
In many cases, examples are raised in which set of offerings that were quite literally yesterday based upon traditional IT operations and architecture and aren’t changed at all are today magically “cloud” based. God, I love marketing.
I’m not trying to be discordant, but there are services that are cloud-based and there are those that aren’t, there are even SaaS applications that are not cloud services because they lack certain essential characteristics that differentiate them as such. It’s a battle of semantics — ones that to me are quite important.
Ultimately, issues with any highly-visible service cause us to take a closer look at issues like DR/BCP, privacy, resiliency, etc. This is a good thing. It only takes a left turn when non-cloud failure causality gets pinned on the donkey that is cloud.
The recent T-Mobile/Danger data loss incident is a classic example; it’s being touted over and over as a cloudtastrophe of epic proportions. Hundreds of blog posts, tweets and mainstream press articles proclaiming the end of days. In light of service failures lately that truly are cloud issues, this is hysterical. I’m simply out of breath in regards to debating this specific incident, so I won’t bother rehashing it here.
Besides, I would think that Miley Cyrus leaving Twitter is a far more profound cloudtastophe than this…
When I point out that T-Mobile/Danger isn’t a cloud service, I get pushback from folks that argue vehemently that it is. When I ask these folks what the essential differentiating characteristics of this (or any) cloud service are from an architectural, technology and operations perspective, what I find is that the answers I get back are generally marketing ones, and these people are not in marketing.
It occurs to me that the explanation for this arises from two main perspectives that frame the way in which people discuss cloud computing:
- The experiential consumer’s view where anything past or present connected via the Internet to someone/thing where data and services are provided and managed remotely on infrastructure by a third party is cloud, or
- The operational provider’s view where the service architecture, infrastructure, automation and delivery models matter and fitting within a taxonomic box for the purpose of service description and delivery is important.
The consumer’s view is emotive and perceptive: “I just put my data in The Cloud” without regard to what powers it or how it’s operated. This is a good thing. Consumers shouldn’t have to care *how* it’s operated. They should ultimately just know it works, as advertised, and that their content is well handled. Fair enough.
The provider’s view, however, is much more technical, clinical, operationally-focused and defined by architecture and characteristics that consumers don’t care about: infrastructure, provisioning, automation, governance, orchestration, scale, programmatic models, etc…this is the stuff that makes the magical cloud tick but is ultimately abstracted from view. Fair enough.
However, context switching between “marketing” and “architecture” is folly; it’s an invalid argument, as is speaking from the consumer’s perspective to represent that of a provider and vice-versa.
So when a service fails, those with a consumer’s perspective simply see something that no longer works as it used to. They think of these — and just about anything else based on Internet connectivity — as cloud. Thus, it becomes a cloud failure. Those with a provider’s view want to know which part of the machine failed and how to fix it, so understanding if this is truly a cloud problem matters.
If the consumer sees the service as cloud, the folks that I’m debating with claim then, that it is cloud, even if the provider does not. This is the disconnect. That’s really what the folks I’m debating with want to tell me; don’t bang my head against the wall saying “this is cloud, that isn’t cloud” because the popular view (the consumer’s) will win and all I’m doing is making things more complex.
As I mentioned, I understand their point, I just disagree with it. I’m an architect/security wonk first and a consumer second. I’ll always be in conflict with myself, but I’m simply not willing to be cloudwashed into simply accepting that everything is cloud. It’s not.
It’s all a matter of perspective. Now, Miley, please come back to Twitter, the cloud’s just not the same without you… 😉