Originally post on the Intergen Blog

I’ve been spending a bunch of time of late thinking, working and talking about Cloud Computing platforms. There’s plenty of smoke and even a little fire too.

If you’ve been listening to the IT media for the past 12 months: Cloud Computing means many things to many different people but I tend to list 3 key attributes of most Cloud Platforms.

1. Elasticity
   The ability to turn capacity on and off as and when required
2. Infinite Scale (or the illusion thereof)
   The ability to scale up/out your solution as much as you want. It’s illusory in that Microsoft or Amazon do have a limited data centre resource, but it’s unlikely your application will be able to come even close to saturating it.
3. Pay for what you use
   In the cloud you only pay for the user accounts, or processor hours, or gigabytes of storage/traffic that you actually use. To a degree this goes along with elasticity- though the level of granularity is key.

From the various vendors there are Cloud Platform offerings with differing degrees of what I tend to think of as vertical integration.

• Software as a Service
  These are the likes of the Microsoft BPOS offerings or Salesforce.com. They’re fully packaged services- rock up with your credit card and you can have a seat of Salesforce or an Exchange mailbox. Your unit of scale is basically a user account- have as many user accounts as you want for as much scale as you want.
• Infrastructure as a Service
  At the other end of the spectrum are the big virtual machine clouds run by people like Amazon.com (EC2) or Rackspace (Mosso). Your unit of scale here is a Virtual Machine (complete with operating system). I also group things like Amazon S3 and Azure Storage in here. You can have as many virtual machines as you want in EC2- but, remember that scale doesn’t come for free, you’re still going to be looking after your operating system; keeping it patched and so forth.
• Platform as a Service
  This is the greyest of the categories. We’re talking here about platforms that provide you with some sort of abstraction atop multiple servers allowing you to scale out (elastically). The sorts of things that fall in here are Windows Azure Compute, Google Gears and Microsoft Live mesh. Arguably Salesforce, CRM Online and SharePoint Online fit in here to a degree too. The unit of scale here is a more abstract concept- these platforms generally require you to build a scale ready application from the outset; by taking this hit up front you get the benefits of not having to worry about things like the underlying operating system management.

So if that’s our taxonomy why do I say that elasticity is the key for early adopters?

Elasticity is the one thing that the cloud vendors can do that you can’t achieve in any other way. Being able to efficiently support users who want to turn things off an on all the time requires both scale and diversity. Scale, because you need to have a large enough customer base that a user turning off a hundred or so machines represents a mere fraction of your total capacity rather than the vast majority of it. Diversity, because you want to have different workloads with different peak demands running on your gear.

The parallels here with more traditional utilities should be obvious. The reason that the electricity system works is scale and diversity. Save for some very large industrial customers, who tend to have different contractual terms, dropping 90% of the demand for a given customer really doesn’t make a big difference to a utility. Their scale is such that individual customer load changes tend to wash each other out. Yes there are national changes in demand over the day but your power company turns capacity on and off in large (and relatively efficient to start/stop) generating units. One of the reasons that this model works is that the utility customers are a diverse bunch- if their entire customer base were residential customers, all of whom cooked roast lamb every night and all at 6pm exactly then the model wouldn’t work quite so well would it?

We’ve got a pretty nice data centre setup at Intergen. We can run applications very efficiently- we have a PUE of 1.62. We can run applications at great scale- need 1000 cores on a 12 month contract we can do that. We can keep you going 24/7/365- we’ve not had an outage since we moved to our new Terrace premises. What I can’t offer you though is 1000 cores for 4 hours one morning because you’ve got a big online sale happening- we simply don’t have the scale nor the customer diversity to make that happen. I’d hazard a guess that there isn’t an internal enterprise data centre in the world geared up for this sort of request. This is the sweet spot of the cloud vendors, particularly the Infrastructure/Platform as a Service people.

It basically comes down to your periodicity and differential of demand. If your application needs 100 cores during working hours and 10 outside working hours you’re a good candidate for the cloud but other options might suffice. If your application needs 10 cores for 360 days of the year and 100 cores for 5 days in that period then my submission is that cloud is your only sensible option here. Highly elastic workloads can only be cost effectively delivered through cloud computing.