What does it mean to be Cloud-Class?

In the world of software and hardware infrastructure we routinely label things as personal, departmental, enterprise class, or carrier grade. So what does it mean to be a cloud class infrastructure? It’s clear that it’s not just a simple matter of performance. Rather than rehash a lot of weasel words like “robust”, “scalable”, and “reliable” let’s instead look at what features are valued by cloud builders. Many simply do not exist (or are much less important) at the other Quality of Service levels.

Multi-tenant – much of the cost benefit of the cloud comes from the religious adherence to the architectural principal of sharing common resources and never dedicating systems to specific users or groups (tenants). The simple fact that not every user is active at the same time is what makes this model work. However, multitenancy also means that cloud builders needs to play close attention to governance and security so that resource hogs and malicious users don’t adversely impact other clients. Tenants that don’t feel safe or well served in a shared space will simply choose leave.

Usage-based metering and accounting – making everyone pay their fare share of the usage is the model of most successful large scale utilities (gas, electricity, water, etc.). It’s what encourages conservation and allows the little guy to avoid being unduly taxed to make up for the wasteful practices of others. All-you-can-consume, per user, subscription models leads to over provisioning (read overpaying) and wasteful consumption (read overusing). Cloud builders can’t cop out on building the infrastructure required for detailed usage metering and billing without paying a price. That price comes in the form of either i) addressable market (ie. your subscription price builds in a buffer that prices out the long tail of little guys) or ii) cost of infrastructure (i.e. you are forced to pay the cost of servicing the unprofitable power users)

Automated provisioning and self-healing – Enterprises are teaming with service people to take your order, service your order, and comfort you when your order wasn’t handled right. There is no help desk in the cloud. No customer service representative to calm you down when your job didn’t execute. The users have to self service and the system has to automatically provision for them. Instances need to be stopped and started dynamically as demand, location, and availability demand. This is a level of automation rarely achieved on smaller scale systems.

Loosely Coupled – Systems need to be engineered and developed with minimal assumptions (coupling) between the components. Any large system of dynamically moving parts will grind to a halt quickly if the parts are too interdependent on one another’s location, version (format), or availability (time). Separation of application code from all underlying resources is of paramount importance to a cloud builder. The cloud must be a platform for continuous, non-disruptive upgrades and improvements.

Continuously available – 100% uptime of the entire system as a whole. Not 5 nines, or HA. The cloud can’t go down, ever. Just because a single components claims to be 99.999% available doesn’t mean when you add a bunch of them into the mix that you magically get 99.999% (or better) uptime. Usually it’s just the opposite. More things to fail often mean lower uptime, unless of course you architect it right. Even very well architected and tested systems are vulnerable to catastrophic systemic failures (like the famous AT&T SS7 crash, or the Ohio-Michigan electric grid meltdown in 2003).

These are some serious architectural goals to achieve, and these are just five off the top of my head. You can see why I have the utmost respect for cloud builders.