Original URL: https://www.theregister.com/2009/01/06/year_ahead_clouds/

A crack in the madness of clouds

Sanity check 09?

By Dave Rosenberg

Posted in Software, 6th January 2009 22:09 GMT

Besides providing some of the biggest technical innovation of 2008, the cloud also wins the award for most amorphous product definition. Few people define "the cloud" or "cloud computing" the same way, leading to market noise and a wealth of misinformation.

"The cloud" as a term really started as a metaphor for the "internet" and has since been bastardized to mean pretty much anything that isn't on-premise computing.

What will see in 2009? Sadly, not a miraculous understanding, but instead a glimmer of hope that the cloud can live up to the hype. In 2008 we were mostly able to break cloud computing (or the cloud - whatever you like) into the following segments:

Storage-as-a-Service hovered on the fringe in 2008 and I suspect that it too will become part of the cloud taxonomy in 2009.

Outside of cloud-y infrastructure we also have accessories such as tooling, including monitoring, configuration management and automation, as well as a never-ending supply of APIs to interact with every cloud service. These will become more relevant as cloud consumption increases. With this in mind, these are the masses of precipitation I think we should expect 2009.

Data-as-a-Service

Breaking away from database tables and silos, data-as-a-service will provide a way to consume disparate structured and un-structured cloud-based data across various networks.

For example, let's say I want to pull inventory data from Amazon S3 and user data stored in Google's Bigtable and join it in Salesforce.com through some kind of query. In the relational database world you would use SQL, but each cloud provider has implemented a slightly different database structure and API. Somewhere down the line this will have to get easier.

The ability to apply cohesion to disparate data regardless of what structure it's in or how it's stored could be the cloud's Holy Grail. Former Credit Suisse software analyst Jason Maynard has called this "data-as-an-answer" for its ability to provide insight beyond one silo.

I also think this could introduce a concept of cloud droplets, which will form micro-clouds or transaction points that form a larger computing environment.

In physics, a cloud droplet is very small compared to a raindrop. It takes about a million cloud droplets to make a single rain drop. In the same vein, I believe that we'll eventually get to a place where endpoints - or end-users - act as cloud droplets potentially in the form of peer-to-peer cohesion or possibly as a function of data federation.

Internal clouds

A "compute cloud" is a different animal according to the developers of Eucalyptus, an open-source, EC2-compatible infrastructure-as-a-service. Typically based on virtual machines, "cloud computing allows users to dynamically provision processing time and storage space from a ubiquitous 'cloud' of computational resources."

Does this concept apply to a corporate data center? Absolutely. Internal clouds will come to fruition as companies uncomfortable with the security or offsite nature of internet clouds start to figure out ways to achieve a high - if not infinite - level of scale internally. And considering that commodity hardware is cheap and often under-utilized, the cost basis won't necessarily be higher than running full-time on EC2.

While it's not realistic to build your own Amazon infrastructure - nor would you want to unless you are trying to directly compete - it will become possible to build and deploy internal clouds just as you would server clusters. You'll likely even interact with the internal cloud through APIs just as you would the external clouds.

Portability

We currently lack a standard for virtual machine portability though one is in the works. Of course that hasn't stopped many a vendor from deciding that their version is better than the standard, stifling progress.

Portability from one external cloud to another and from internal to external will get solved in several kludgey ways. For instance, I suspect that if you are running a single vendor solution such as VMware VMs and vCloud you'll be fine, but if you are running a mix of VMware and Microsoft's HyperV or the open-source Xen you're going to be unhappy.

This of course leads to a very realistic possibility of being locked-in to a single vendor. In the near term that probably doesn't matter as vendors duke it out in pricing. But sooner or later it will get you.

Capacity issues hit Amazon

Okay, this one is a little out there, but the fact is we have no visibility into how much computing power Amazon is currently using or has to offer. And considering that they are a retailer first and infrastructure provider second, I am sure they will favor themselves if a capacity issue comes to bear. This presents a potentially tricky situation mostly for new AWS customers and tool providers who are dependent on the Amazon infrastructure for their services.

Microsoft will kinda, sorta, maybe get it right

When I first read about Microsoft Azure Services Platform, I simply couldn't make any sense of it. Azure is ambitious as it is amorphous. It's a coud, it's a data center in a box, it's a piece of toast that looks like the Virgin Mary.

Here's what will work: Microsoft-oriented developers will continue to use Visual Studio and Microsoft will smoothly place an Azure deployment mechanism into the toolkit. Developers won't really care and Microsoft will get what they want: more lock-in.

This won't yet upset storage companies or other software vendors as the development and operations team will continue on business-as-usual. Sooner or later, Microsoft will make some cloud-y type system work.

It may not work for you and me, but it will certainly work for them during the next 12 months and beyond.

Dave Rosenberg is the co-founder and former chief executive of open source enterprise service bus and integration platform MuleSource. Dave is currently working on a new stealth start-up based in San Francisco.