There are a growing number of so-called cloud operating systems, meaning cloud-enabling software, or middleware if you prefer, that allow pretty much anyone to create cloud infrastructure. Service providers can use these frameworks to make public clouds and enterprises can use them to construct their very own private clouds. On the proprietary side, the most popular such cloud OS is VMware’s vCloud product – but the real action lately is on the open source side. And here there are four main players: OpenStack, CloudStack, Eucalyptus and OpenNebula. While all of these Infrastructure-as-a-Service (IaaS) frameworks are focused on the general enterprise space, they are also suitable for HPC workloads to varying degrees.

The trending topic the last few weeks – and the debate has actually been going on for much longer – is cloud APIs. OpenStack aims to create a unique standard, while the other three are basically in favor of supporting a de facto standard, which is Amazon’s API. To be precise, though, OpenNebula says it is “fully API-agnostic” – implementing both de facto and de jure standards.

The API-clone supporters say this will foster interoperability between solutions and help create portability across cloud providers. However Rackspace President and the OpenStack champion Lew Moorman vehemently disagrees, as he has expressed in numerous talks and interviews over the preceding weeks. He says the Amazon API supporters miss the point of true cloud interoperability – because the API is just the outside layer – the true value lies inside.

Writes Moorman:

APIs are just an adapter between your app and the cloud. They show you how to ask for things and what to expect. But it’s the actual cloud, all the back-end technology, that delivers the results. To match the performance of AWS, you need the technology of AWS — not just the APIs. And that technology, the thing that really matters to your application, is unavailable. It’s closed and proprietary.

So there are these competing ideas – the pro-Amazon API cloning side says compatibility with the Amazon API is critical because 30 percent of cloud developers are already using AWS APIs – so it’s the de facto standard regardless of its actual merits. And on the other side, we have the OpenStack camp saying a de facto standard is not an actual standard – and that we need real innovation which adopting this “closed API” will thwart.

This is not to give the impression that OpenStack is alone in its opinion. The project has some big name industry support. Besides Rackspace, there’s AT&T, Canonical, Hewlett-Packard, IBM, Nebula, Red Hat, and Suse – and these are just the platinum members. There are 180 participating organizations in all, many of whom would like to knock Amazon off its perch, which is to say these are not neutral parties.

Public cloud provider Rackspace is set to transition to the OpenStack codebase on August 1, while HP is also pinning its cloud dreams on OpenStack. While difficult for any one cloud provider to compete with Amazon, by combining resources the members of the OpenStack foundation increase the odds of a successful coup. Looked upon in the light of pure capitalism, Moorman’s rigid anti-Amazon API stance is more utilitarian than ideological. Rigidity or not, even OpenStack uses Amazon API clones, although the Rackspace president says these are inward-facing.

The poster child on the pro-Amazon API cloning side is Eucalyptus Services. The open source cloud management platform is the only one in its class that has a licensing agreement in place to use the Amazon API. Asked what that entails, CEO Marten Mickos explained that on the technical side, Amazon gives the company guidance and advice on how to be more API-compatible, but does not provide any code. On the market side, the two parties work together to help customers build a hybrid solution.

The Eucalyptus CEO points out that standards are what customers adopt not what vendors would have them adopt, then adds that the AWS API is what their customers are requesting. While Eucalyptus remains committed to their API choices, they are also open to adopting any other leading standards that emerge, although the CEO emphasizes that right now there is only one leading API.

“We cover 80-90 percent of the public cloud market today with our API compatibility, and we’ve publicly said that whoever next gets to 30 percent of public clouds, will be supported by Eucalpytus – whether that’s Google’s Compute Engine, Microsoft, VMware, or OpenStack or somebody else,” says Mickos.

Eucalyptus Chief Technology Officer Rich Wolski echoes the CEO’s sentiments, opining that standards are application-driven not vendor driven. They come from development groups, he says, recalling the early 90s machine-to-machine communication standards and the MPI standard that evolved based on developer and application needs.

While a single API standard makes it easier for integrators to write-once and run-anywhere, even the AWS APIs fall short in some areas. Take CloudSigma, a global cloud provider, based in Switzerland. They offer an SSD storage option in their cloud, but Amazon does not have SSD storage, ergo there is no Amazon API for this. In a conversation earlier today, CloudSigma’s Manager of Enterprise Solutions Architecture Michael Higgens, proposed the use of a cloud API abstraction layer that fits between the application stack and the cloud service. While this is certainly a possible workaround, and one that has been suggested before, abstractions have performance penalties. An acceptable tradeoff, perhaps, for a single small workload, but these “API APIs” can be showstoppers at scale, and are probably not suitable for the most performance-sensitive apps (i.e., HPC).

I’m not sure anyone has the ultimate answer, although I appreciate Mike Fratto’s tough love stance:

Guess what, kids – integration is hard. Get over it. It doesn’t matter too much how many developers are on a project or how many lines of code there are. It matters that a cloud service provides value to customers. If cloud software providers make integration difficult or apply unacceptable (legal) restrictions on API use, then developers will flee and the cloud service provider will wither.

While these cloud API wars will likely rage on, that might not be a bad thing. Agreeing on standards too early in the technology development cycle can stifle innovation. The cloud space, especially IaaS, has reached a pivotal stage, like a teenager on the brink of adulthood, full of energy, drive and potential. Amazon is still in the lead, but all these competitors – Microsoft, HP, Google, IBM – are throwing down the gauntlet. Alongside the propriety solutions, there’s this healthy open source market springing up, all reaching production-ready maturity at roughly the same time. Suffice to say, it’s an exciting time for cloud watchers.