Elasticity 🙂
I just finished reading Randy Bias’s piece, “Elasticity is NOT #Cloud Computing … Just Ask Google“, and I must admit, it takes me back to all sorts of questions of a vaguely unsettling nature that have been bubbling below the surface of my cloudy thinking for some time.
If Elasticity is NOT Cloud Computing, and I profoundly disagree with that statement, then what the heck is Cloud Computing? I admit to already having been pretty skeptical about whether Private Clouds are really Cloud Computing, but I got over that from an understanding of elasticity and private clouds. However, if we take away Elasticity, and make whatever is left Private, I’m not sure we have anything profound whatsoever. How does it differ from an outsourced data center, for example?
Randy seems to have come to his position about elasticity by looking at the large web operators like Amazon, Google and Salesforce who offer Cloud platforms of one kind or another (IaaS, PaaS, and the rest of the alphabet soup). He’s interested in their history, why they built the kind of infrastructure they did, and why that turned out to be an ideal platform from which to offer Cloud Computing offerings. My problem is that the mere fact that Amazon did not get the Elasticity benefit from its Cloud that AWS customers can does not in any way diminish the revolution that is the Cloud and that comes with Elasticity. Without customers, these fancy Amazon and Google data centers are literally the sound of One Cloud Thunderclapping (because Clouds don’t just clap in the sense of the old Zen saying). I don’t see how you can regard those data centers as “Cloud” at all. A term more like “commodity computing” data center, perhaps with some form of “virtual” thrown in makes more sense. Interestingly, it is the addition of the customers to their data centers that exposed Amazon and Google to a little elasticity. Why? Because now they have customers to help pay for excess computing capacity and hence elasticity. What a beautiful thing, and another strong argument for why elasticity changes everything.
The term “Cloud”, in any sense I’ve ever heard it used, is a service of some kind provided by one organization and shared (this sharing is critical) by many other independent customer organizations. Thinking back on the idea that Amazon’s data center wasn’t cloud until they flipped the switch and started sharing it with customers (that’s the point where they got elasticity too), you can see that the ideas of “sharing” and “independepent customers” are critical. Without both, there is no way to pay for the excess capacity that is elasticity, or at the very least, if the sharing is the sort pushed by companies like VMWare to up server utilization, it isn’t quite the same as having real net positive dollars coming in from paying customers, versus simple cost savings.
This is where I get into trouble with the Private Cloud concept. Yeah sure, people are interested in building data centers that use technology similar to what the “Cloud” vendor’s data centers use. Yeah sure, there is some benefit to that. Those technologies were developed by organizations that needed to commoditize their data center services into as cheap an offering as possible. But to call that Cloud Computing sure seems like gratuitous marketing to me. If nothing else, it radically understates the challenge those organizations faced. A little bit of storage virtualization, a healthy dose of VMWare-style machine virtualization, and do you really have the full benefits of Cloud Computing? Not in my book. You just have a modern data center.
There are steps beyond that to take advantage of. And the advantages are enough of a quantum leap that it isn’t fair to award the accolade “Cloud” for anything less. If you do, you’re just engaging in gratuitous marketing, trying to draft somebody else’s hype and momentum. I am already on record as arguing for the definition of Cloud being two things:
– It is Software as a Service. I sometimes refer to this as “Ops as an API”, meaning rather than crawling around cages and machine racks, you perform ops by making API calls on your Cloud infrastructure.
– It is Elastic. Yep, I refuse to separate Elasticity from the Cloud, though Randy’s piece wants to leave it more in the camp of simply “Data Center as a Service”.
So then what really is a Private Cloud, and can we still call it a Cloud? If you include the Software as a Service Piece, and the Elasticity, I would say “yes”. The difference between a Public and Private Cloud is simply that in the Private case, the Customer paid the service provider to decouple their Private Cloud from the rest of the Public Cloud so no network traffic can get into the Private Cloud without its full knowledge and consent. This is no biggie–it’s a subnet with the additional proviso that we don’t run anyone else’s Cloud Software but the one owner of the Private Cloud insider that subnet. This is actually a pretty good deal for all concerned. The Private Cloud user still gets nearly all the benefits of the Public Cloud user. They do not get quite a good a price as they must monopolize the hardware to a greater extent than their Public brethren, but it is still a great deal. Elasticity is still available to them, as is “Ops as an API”. If your Private Cloud lacks either one of those characteristics, you have a modern data center, but it isn’t Cloud, despite what your vendor’s marketing people want to tell you.
Why do a Private Cloud?
Largely to reduce perceived risks. The risks boil down to security and performance. The Private Cloud is presumably more secure, and its performance is more predictable because no unknown Public Cloud tenants can get into the Private Cloud and do unknown things.
There is one more advantage I will mention for the Cloud, which very much does include Elasticity, versus the Modern Data Center, which uses some Cloud technology, but has no Elasticity and is not a Cloud:
You Cloud Vendor may have more buying power than you, more technology they have amortized over more customers, and hence a lower cost to deliver the service than even relatively large corporate data centers can attain. Hey, if it was easy, everyone would be doing it, instead of just everyone claiming to do it. 
Hi Bob,
Thanks for the great response. Just wanted to clarify a few points. First, I’m not arguing that EC2 is not a cloud because Amazon doesn’t get elasticity from it. My argument is that elasticity is essential a benefit of cloud computing customers, not cloud computing in and of itself. As someone who has looked closely at 5-10 IaaS clouds, where by ‘closely’ I mean done deep technical and business due diligence, I can tell you that none of these infrastructures are ‘elastic’ internally.
In fact, most of public IaaS clouds *must* run at 70-80% capacity for the business models to work out properly. That means that they are rather inelastic to be certain. There is certainly no doubt that Amazon customers derive tremendous benefits from elasticity and in fact, most new cloud-based applications depend specifically on this benefit. But is that cloud computing? Or is it just cloud applications consuming cloud computing?
I think about it sometimes like I would electrical power. Specifically electrical power from to a factory. IaaS is the feed from grid, PaaS is the electrical power distribution system within the factory and SaaS/CloudApps are the end systems inside the factory (computers, robotics, machinery) that consume the electricity.
Again, thanks for the response. I can appreciate your particular viewpoint here.
Best,
–Randy
Randy, I’m glad you brought up the electrical power analogy.
Once upon a time, everyone generated their own electrical power on site, where the power was to be consumed. There was no elasticity available, and no grid.
We learned pretty quickly what the shortcomings of that model were.
So it is with Cloud Computing. Clouds without elasticity may as well be the old model where the electricity is generated where it is to be consumed. Again, no elasticity. It makes no sense to call that a Cloud, unless you’re just pushing it as hype.
You haven’t made a believer out of me.
Cheers,
BW
[…] What is the Sound of One Cloud Thunderclapping?. […]
OK I see what Randy is driving at, I hope. That’s just from reading this post which I found fascinating so thank you both. To the supplier it is not elastic it is simply a bandwidth management and capacity management/utilization problem, over fixed assets or a “sunk cost”. Unless they are in a grid to a 3rd party cloud provider. To the consumer it is elastic. To the provider it is about capital and risk management, and the consumer about economies and responsiveness, sort of….
Walter Adamson @g2m
http://xeesm.com/walter
Bob,
Walter Adamson is correct. My point is that the cloud itself is inelastic, not the usage. A 10 MW power plant is a 10MW power plant. Elasticity is a benefit that emerges when 1) there is an abundance of a commodity resource and 2) the resource is tied into a distribution system that allows easy access.
Your example shows this. It turns out that it’s the combination of “cheap” *and* “easy to get” that turns any kind of business tech/infra into something that be a ‘utility.’ The side effect and a key benefit for customers of this change is elasticity. But there isn’t anything fundamental to electricity or a power plant that is elastic.
As Walter Adamson says, for the provider(s) it’s a capacity management problem.
Best,
–Randy
“The side effect and a key benefit for customers of this change is elasticity. But there isn’t anything fundamental to electricity or a power plant that is elastic.”
– except its business model.
But surely the context in which the output is delivered is part of the definition?
Or are we going to say things like, “there isn’t anything fundamental to currency that is spendable;” or “there isn’t anything fundamental to a hot dinner that is edible” ??
I too agree with Walter Adamson, and if Randy wants to define cloud computing in strictly technology terms with no reference to the context in which it’s consumed, then I guess I agree with him too. I think he makes a useful point but it seems rather academic.
Phil, this discussion is about the critical difference between a technology/product and a service. As you say, the context of consumption matters. It matters a lot.
When people say they are delivering “X” as a Service, there frequently is not a good understanding of the real difference between “X” as a Service and “X” as a product or technology.
Delving into that difference, both as it applies to this specific blog topic as well as how it applies to almost every “X” as a Service discussion, will be a topic for another Smoothspan blog post before too long!
Cheers,
BW