Why Isn't Cloud Taking Off?

There's been some discussion in the press and from various pundits about how cloud infrastructure projects like OpenStack are "troubled", and how cloud hadn't taken off as expected, especially in the context of private clouds.

First of all, it's worth bearing in mind that in the quest for new news, the hype cycle of much of the media first tends to introduce something with great enthusiasm, make a lot of noise (and possibly overoptimistic predictions) about it, then when it fails to materialise according to the required new news schedule, announces a "failure" or otherwise turns against the original subject (you can see the same thing with reporting of celebrities).

So, cloud is still happening, and is probably inevitable even for the private cloud context at this stage, it's just not running to the timetable of noticeable results that the media would like to see.

But why is this? well it comes down to what "cloud" and especially "private cloud" really is.

At it's most fundamental, cloud computing is simply another way of handling operational management; that is, it's a methodology for organising your IT resources and making them available for use by your organisation.  Cloud computing is attractive because it promises to make more efficient use of resources (up to 80% utilisation, compared to approximately 50% for non-cloud virtualisation, or 30% for physical systems), and also because it promises more nimble access to those resources by project or business units via self-service. 

This efficiency and fast access relies on a number of factors, however. Firstly it relies on automation: without automation in systems configuration & service deployment, addition and access to resources is far too slow, and far to expensive. Cloud also relies on standardised templates for deploying services, even if those templates are as simple as "small", "medium", and "large" [1]. Without templates it's extremely difficult to apply rules to automatically assign workloads to the right systems, and also very hard to do proper pricing & chargeback. Thirdly, cloud relies on effective capacity management, so that new workloads don't suddenly choke the system - especially when end-users are able to self-serve their workloads.

If we look at these general needs of automation, templates, policy-based deployment, capacity planning and so on, we see that there needs to be a reasonably high level of operational maturity in an organisation to be successful at deploying cloud computing.

And this is where many organisations are struggling.

Research firm Gartner has an "operational maturity model" ranging from 0 ("running around with your hair on fire") through to 5 ("IT operations are integrated with the enterprise & provide additional value to the organisation").  The traits and mindset necessary to be truly successful with cloud computing exist around level 4, and perhaps an advanced stage of level 3.  Most IT organisations, for various reasons, usually operate in the region around level 2-3, with very few truly at level 4 and a vanishingly small number at level 5.

This is why, so far, private cloud computing deployments are few and far between: it is difficult stuff, and in many cases although organisations may truly want to adopt cloud operations, there remains a steep learning curve in many of the fundamental concepts that make cloud effective.

Organisations looking to implement cloud should look to develop their existing operational procedures, especially by making use of automation and tools that can handle templates, compliance,and capacity management.

Eventually cloud computing will become the standard method for operation, but there may need to be a generational change in organisational mindset, as well as in software & tools, before it can be fully realised.

Update:  this isn't the only reason, of course. Here's another thought.

1. Proper naming of service templates is important. Another article covers this.

Virtualization and Processor Capability

In the old days[1]  the big computer companies competed fiercely on processor performance: a few extra megahertz here & there could make the difference between winning that multimillion dollar sale & being relegated to the also-rans.  Applications and operating systems were monolithic, giant chunks of code that consumed vast quantities of the CPU's processing time, so the faster you could  run through that single-threaded code, the better.

These days, the "processor wars" are done & dusted. There's really nothing that the relatively low-volume-and-hence-high-price RISC processors found in the big UNIX systems from Sun, HP & IBM can do that the relatively high-volume-hence-low-price x86-64 processors can't. So unless you're looking for a specific niche solution (from Snoracle[2]) or especially clever I/O virtualisation (IBM Power), there's really not much reason to be putting your workloads on anything other than an x86-64  system.

In fact, processing capacity is so grotesquely huge these days (and has been for a while) that we chop that capacity up into little units & assign them to many operating systems at the same time. This is called "virtualisation" (stop me if I'm going too fast).   This leads to the question of whether we can get away with even less. Certainly in the dim dark ages of last century, we were able to run multiple web servers on a single cpu systems; even given the additional complexity of some web apps these days, there are many applications that don't warrant the full power possible even with virtualised x64, and certainly not the power & cooling requirements of those larger servers.

This is why people are interested in ARM and Atom processors - lower performance than the high-end x86-64, but with sufficient capacity to do the job, and much more attractive characteristics for power, cooling & price.

So the future of server selection could be much more about power consumption (& cooling costs) over its lifetime than raw performance.  In fact, it's almost certain.

1: Old days, for purposes of this article, are before about 2006. Bleh. I feel old.

2: Snoracle. Sun + Oracle. Also, possibly onomatopoeia .