Increasingly, Internet-scale sites need to do more with less. The rapid commoditization of IaaS/PaaS services is an example of race towards the leanest CapEx/OpEx possible.

This is not without risks. One’s own balancing act of risks vs. rewards can be captured in the spectrum that I show in the picture  below.  For this, I was inspired by some readings I did a while ago on complexity theory and adaptive systems. Beware of being caught at either end!

Ideally, one would want to play near the “edge of chaos”, with the confidence that there is a way and a time to step on the brakes, without ever crossing into chaos.

Some R&D projects fall in the realm of catalysts, in that they thrust towards greater risk/reward operating points. Examples include oversubscribing power, network, DR resources.

Some other R&D projects fall in the realm of “chillers” (which sounds less dire than the traditional inhibitor word). Service level management is an example. It may shape and/or rate limit traffic within a given service level envelope.

Has anyone developed similar taxonomies? Your thoughts?

In my Cloud-related outings, there are a couple of topics that I especially like to expand on (my view) or get hung up on (in all likelihood, my audience’s view :

Accountability (as in: where’s a throat to choke . In general, Cloud providers are not liable for any data loss, IPR loss, downtime, etc. For an enterprise, this is a key departure from outsourcing, hosting, B2B, … which all have some form of indemnification and a clear chain of accountabilities or escalation should things go horribly wrong (i.e., starting from the CIO nearest the boo boo). How will Fortune 500 enterprises overcome the fact that Cloud business rests on reputation only?

Availability: in my opinion, it’s one of two things. Either we think in terms of legacy applications and live by traditional KPI goals like three- or five-nines uptime that are comparable to (say) the dialtone service. Or else we come up with entirely novel application paradigms and stop looking at cloud availability with the glasses of the 1980s. After all, we have already settled for a much lower-quality wireless dialtone and can live with dialtone-less homes whenever power goes off (there was enough extra value for us to compromise on those). What we cannot do – I submit – is to run unchanged legacy applications on-Cloud and pretend to live by some new, lax KPIs.