Thursday, December 15, 2011

Clouds and scalability

This post comes from an online exchange with Roger Sessions (@rsessions on twitter) Leo de Sousa (@leodesousa) and Chris Potts (@chrisdpotts).

Roger makes the point that the various cloud vendors make their case on "scalability" without defining the term sufficiently. As marketing (almost) always does. So he has a point. The question for me then is, "What scales?". It is my firm commitment that when using terms that you intend to quantify, you had better get the dimensions correct. Is scalability a benefit? Of course that depends on what it means. It feels good, hits us in the unthinking (or as Daniel Kahneman calls it "System1") area. It's only when we look more deeply we realize that we have no idea what it means. Yes I'll have 7kg of scalability please.

It all gets to the economics of what you think you want to do. Here are some examples:
  • I want to be able to increase the workload that my system is capable of without having to buy, provision, manage a bunch of servers - Scaling for workload
  • I want to be able to add lots of new users without having to.....- Scaling for users
  • I want my system to be available and priced according to the actual usage. Kinda like electricity. So when all my users are signing in, I want to allocate lots of capacity because that's intensive. But when it is running along smoothly I need less. Scaling for peak demand
  • I want to empower a demonstration team so they can bring up new instances of a standardized template and demonstrate something to a customer/prospect and then tear it down while incurring as little cost as possible. - Scaling for efficiency of people
  • I want to be able to add new functionality with less effort/cost than previously. Scaling for functionality
  • I want to reduce the burden on in house departments (finance, legal, HR or other "overhead" departments) in the deployment of equipment. - Scaling for organizational effectiveness
While I am about it, I wonder what the effective scaling order looks like. For example, maybe I want to scale linearly for workload. In other words as demand increases, supply increases at the same rate. No effective reduction in cost/transaction.

Or I might be prepared for slightly more - the ratio is for each increase in demand, I get a 1.1 increase in cost of supply.

Or I might want to see a reduction - for each increase in demand, my cost goes down .

So as Roger observed, make the vendors of the cloud services be specific about what they are selling when selling scalability

1 comments:

Konrad A. said...

Chris,

A few thoughts in this context if I may. Scalability is a property of the System. System is composed of application code and its infrastructure. While Clouds declare to provide "scalable" infrastructure the ultimate scalability includes application as well. So even if your cloud scales (whatever that means) your application in given cloud may scale or may not. Also, it may scale better if moved away from given cloud. The question becomes: are certain scalability features provided by given cloud aligned with my app current / future design and goals. Also, do I want to become dependent on certain scalability features of this cloud.
So to me as the System desinger the question is not only what scalability of the cloud is, but how it is realized and what additional technical constraints does it impose on my System.

--
Best regards,
Konrad A.