"Cloud Computing" - Stop the Weasel Words!

Posted by: Mahesh Paolini-Subramanya

Have you noticed the plethora of "Cloud-based" service providers out there? Its really starting to feel like the dot-com days, when everybody and their brothers re-badged themselves as as DotCom (and ok, promptly IPO-d to the tune of $300 million, which hasn't happened yet, but still). You know that pretty much any day now you're going to see ads for "Andy's Corner Deli - Now Cloud Based!", and so on.

I know, I know, there really are no hard and fast definitions of "Cloud"-whatever. If anything, it is a lot easier to describe it in terms of what it is not, as compared to what it is. Which is pretty much the point, as back in the day, there really was no such easy definition of dot-com, just a whole bunch of web-sites (and IPOs!). The following 6 rules - three against, and three for - are pretty much my take on what Cloud Computing should - and should not - be.

To begin with, lets assume that you are the Service Provider, i.e., you have something that you sell, make, give-away, whatever.

Rule 1 - If your service runs on a single humongous server, you are NOT cloud-based

This is effectively the first-generation rip-off of the dot-com methodology - the one where all you had to do was put up a web-site to be considered a dot-com. Nowadays, all you have to do is put up a public API, and Bob's your Uncle, you're cloud based! In most cases, the API already existed (something HTTP/REST based), and all you did was print up some marketing collateral that says fun things like Cloud, Distributed, Seamless, and Serving the Customer. At the end of the day, you, however, the score-card reads. Humongous server - Yes, cloud-based - No.

Rule 2 - If you can ever say "Client Foo is on THIS server here", you are NOT cloud-based

This is targeted more at the plethora of hosting services out there. Moving a client's server from their Server room to your rack does not suddenly make you a Cloud. Oh yes, you certainly do have a server farm, and possibly even a hosted one at that, but thats about it. The fact that their server isn't actually on their premises doesnt somehow miraculously confer cloud-capabilities to your hosting facility.
Yes, I know Amazon EC2, Skygone, etc. I concede that one end of the Hosting spectrum does end up in Cloud territory, but thats way over at *that* end of the spectrum...

Rule 3 - Being able to send things to the cloud doesnt make you cloud based

And yet, everybody does it. People are frantically updating their existing services, and rolling out the ability to tweet, send updates to facebook, etc. Mind you, this absolutely begs the question of why one needs to do this.

Rule 4 - To be Cloud-based, You MUST scale horizontally

Or put another way, "You want more capacity? Just rack another Box/Blade/Node/...". Mind you, there is a lot that is left unsaid here, e.g., how you bring the new node online, how load gets distributed, etc., but the bottom line is that the capacity should scale near-lineraly with the number of nodes. And, it must be noted, "capacity" doesn't only refer to the servers, it also includes the overhead associated with managing and maintaing the server infrastructure, back-office systems, etc.

Rule 5 - Your application layer MUST be abstracted from the hardware layer

There are actually two distinct dimensions in which this rule operates. If (per Rule 2) your clients are associated with specific servers, then by definition they are *not* abstracted from the hardware layer, and the overhead associated with scaling is decidedly not linear (e.g., managing your clients, moving them around, etc.). If, on the other hand, (per Rule 4), your application relies on the hardware semantics to function - e.g., it relies on a mySQL cluster, memcached, etc. for concurrency, then you are now reliant on their scaling, distribution, etc (which, trust me, is decidedly not linear).

Rule 6 - You SHOULD have a coarse-grained API

Ok, this is me being weaslely (nice word there!). What exactly *is* a coarse-grained API? Well, I could go on about SOA and granularity, but that's a rat-hole that we just don't want to go down - there are as many arguments for as against pretty much every point there. An easier way to picture it is from a usability perspective - the easier, more transparent, and more encapsulatable an API is, the more likely it is to be actually used by people. Note that this is why this Rule is a SHOULD, instead of a MUST. You don't *have* to do it. Its just that if you don't do it, odds are nobody is going to use it.