Choosing the right cloud platform

The emergence of a number of self-proclaimed 'open' cloud platforms presents any would-be cloud adopter with a confusing plethora of choice. Rackspace's OpenStack initiative, unveiled last week, is the latest, but it's by no means the only one [disclosure: Rackspace hosts my business and personal websites free of charge]. There are also portability initiatives like VMware's 'open PaaS' which, except in its use of the Spring stack, seems to be open in much the same way that Windows Azure is open (it's a published standard and you have a choice of hosting partners).

For cloud adopters all these offerings, in their various ways, hold out the promise of pursuing a hybrid strategy. They're attractive because they provide the option of putting some assets in the cloud while keeping others on trusted terra firma — or at the very least, a user can reserve the option of pulling their IT back off the provider's cloud if they ever need to, avoiding lock-in to a single provider.

I'd like to dig into the multiple reasons why this can be attractive. But first let me pause for a moment to highlight a huge problem in all of this. There's a very strong risk that all this choice merely serves to obscure the bigger picture of why people should choose a cloud platform in the first place. Too often, people get fixated on technology attributes like virtualization and IT automation. While these are useful, money-saving features, they aren't the main point. Cloud computing is valuable because it's in the cloud, where it benefits from all the advantages of running on infrastructure that's shared by a broad cross-section of users and is ready to connect seamlessly to other cloud resources. See my earlier discussion, Cloud, it's a Web thing.

Having said all that, there are a number of reasons why you might still want to adopt a cloud platform that, at the same time as having all that cloud goodness, allows you to move your applications somewhere else should you wish to:

That all-important comfort feeling. You may never move off the platform — experience shows that most cloud users stay put, even if they originally planned to go back in-house at a later date — but there's a huge comfort in knowing that, if you ever need to, you can. Back in the late 1980s, I used to sell Compaq kit. The company had some humungously large disk arrays in its price list. A Compaq product manager once told me the company virtually never sold any, but had found it was essential to have them in the price list because buyers wanted to know they were there if they ever needed them. The existence of an off-cloud option serves the same role for cloud buyers.

Architectural portability. Yes, yes, yes, you know that your cloud provider offers the kind of scalability, availability and performance that you could only dream of. But just occasionally, there are architectural tweaks that would make a specific application run better in certain use cases. When it matters, you want the flexibility to be able to move to a host that offers that architecture.

Operational portability. The trouble with having only one choice of provider is that you're stuck. If the provider jacks up its prices, starts offering poorer performance or bad customer service, or simply becomes less competitive over time, you have nowhere to go. You may also have needs that vary depending on the time of year, the type of application or even the geographic location of users (eg to comply with data privacy laws). An open platform gives you a choice of different hosts — including in-house — that you can move between in line with your operational needs. This is especially important when you're using a cloud provider for sporadic burst capacity.

Service level flexibility. Although cloud providers may offer more service level granularity in the future, today they mostly offer just a single service level (in many cases, it's not even specified or guaranteed). So the only way to select variable service levels — for example, to put certain applications on five-nines availability while others do perfectly well on a cheaper three-nines platform — is to use more than one provider. That's a lot more complex to manage if each one has its own proprietary platform rather than one standardized, open stack.

Is all this just a matter of APIs? It depends what you need to specify and how sophisticated the APIs are. At present, the APIs don't offer the granularity to cover a tenth of the needs I've outlined above — nor is it in the established providers' interests to give away too much flexibility to move between platforms any sooner than they need to.

What we're witnessing here is a struggle for market advantage between three separate contingents; first movers hold the field but there could be an opportunity for others to dislodge them by winning the mantle of most open or, perhaps, most vanilla.

Among first movers, Amazon holds a pre-eminence that some are already arguing is unassailable. Others still fancy Microsoft because of its installed base and its developer community, while some still rate Google or Apple because of their cloud presence in other areas.

The mantle of most open is being fought over by a crowd of contenders. Rackspace turned a neat trick by launching its claim with a useful sprinkling of NASA spacedust. Despite its proprietary core, VMware has made a strong play, aligning itself with Java developers and building on its credibility as a virtualization platform. Some of the lesser known second-tier players could quickly win mindshare by teaming up with a big telco or hardware vendor.

Either camp could claim the mantle of most vanilla. This is an attribute that works best in the cloud environment (think SOAP vs REST). The victor is likely to be the platform that does the best job of evolving to become an elegant, simple and straightforward mechanism that satisfies market demands for interoperability and portability — irrespective whether it achieves that through open APIs or a more extensive open framework.

Either way, the predominance of vanilla in the cloud environment stacks the odds against anyone who teams up with a telco or big systems vendor, since these are the players with the least skills or confidence in reducing systems to their simplest primitives. Most people who understand the cloud environment instinctively realize that this hands the advantage to Amazon, Google and other cloud-native players as the most likely long-term victors.