Found a wonderful post by Greg Papadopoulos in which he postulates the trend towards interclouds. Greg argues that Amazon's AWS BYOS/IaaS (Bring Your Own Stack) is the perfect marriage of simplicity and functionality that it will be with us for a long time. SaaS is the new delivery norm of software, and PaaS is the needed productivity layer to hide the complexity of IaaS. The proliferation of SaaS on top of PaaS on top of IaaS is the wrath of early technology adoption when most of the functionality is still in its infancy.

As Greg writes:
"Productive and in-production are different concepts, however. And as much as AWS seems to have found the lowest common denominator on the former with IaaS, how at-scale production will actually unfold will be a watershed for the computing industry.

Getting deployed and in production raises an incredible array of concerns that the developer doesn't see. The best analogy here is to operating systems; basic sub-systems like scheduling, virtual memory and network and storage stacks are secondary concerns to most developers, but are primary to the operator/deployer who's job it is to keep the system running well at a predictable level of service.

Now layer on top of this information security, user/service identity, accounting and audit, and then do this for hundreds or thousands of applications simultaneously and you begin to see why it isn't so easy. You also begin to see why people get twitchy about the who, where, and how of their computing plant.

Make no mistake, I have no doubt that cloud (nee network, grid) computing will become the organizing principle for public and private infrastructure. The production question is what the balance will be. Which cloud approach will ultimately win? Will it be big public utility-like things, or more purpose-built private enterprise ones?

The answer: yes. There will be no more of a consolidation to a single cloud than there is to a single network. "

He goes on to say the cloud will organize much like the energy business with a handful of very large networks supported by hundreds of regional and national companies. In this comparison, Greg finds an analogy in the internetworking development. Connecting all these federated entities together has created tremendous value, and thus it is reasonable to expect that the cloud will organize as a federated system as well. But to accomplish that, the cloud community needs to develop the right standards, just like the Internet community did for internetworking so that nobody has to be afraid to become an isolated island.

Putting on my developer's hat, this fear of becoming isolated is what is holding me back to commit to Google Apps or Microsoft Azure: they feel too proprietary in this age of open source and federated clouds. One of my core requirements for cloud applications is that the application could migrate from private cloud to public cloud and vice versa. When the economic value of the application goes up or down I want to be able to allocate it on the right infrastructure to maximize profit or minimize cost. Closed environments like Salesforce.com, Google Apps, or Microsoft Azure are a concern as these environments create a fierce lock-in for my application. Encapsulating it in an OVF virtual appliance provides me much greater flexibility at the cost of not having productive elastic computing services. That capability is maturing as we speak as its value is as obvious as it is needed.