When OpenStack’s founders laid down a blueprint for an open IaaS project to create an interrelated, and happily symbiotic, pool of networking, processing and storage technologies, they did so with the aim of creating a pure new heartland. This newly formed nucleus for open cloud computing excellence would shun the proprietary world of vendor lock-in, as it forged a new community of über-healthy openness.
Although OpenStack founding father NASA used Amazon EC2-compliant APIs in Nova (the compute element of the stack), Rackspace made a decision before the project launch to position its own APIs into the fabric controller instead. The question arises now (and there is much current debate on this topic) as to whether OpenStack should open up to Amazon API compatibility; a move that would surely create an environment for greater cross-cloud interchange and interconnectedness for all.
It would make good sense, wouldn’t it? Why build OpenStack as pure virgin territory without APIs to connect to AWS? Yes, OpenStack under the Apache Licence is essentially a rebuttal to the propriety model, but open standards call for openness at all levels. Heck, even Microsoft has an open computing division these days.
NASA has since departed OpenStack but that’s OK say the some 200 or so companies currently involved in the project. “NASA is a big organisation with a huge amount of diverse interests and the fact that it has been part of the inception and formation of OpenStack is great,” said any vendor spokesperson out of 200 you care to choose from.
Crucially though, these same OpenStack commentators will also remind us that NASA helped “turned OpenStack back to the community” i.e. not helped OpenStack reach a plateau at which point it could then integrate with Amazon for commercial necessity.
The OpenStack Amazon crossroads
So where should firms turn now if they feel caught at the OpenStack Amazon crossroads? David Fishman of OpenStack consulting and engineering firm Mirantis says that cloud developers might really “dig the idea” of common APIs in the short term. But ask any cloud operator - public or private - and they'll tell you that the proof of the pudding is in the implementation, not through any opening of APIs.
“In the long term, OpenStack's killer feature is in the implementation transparency i.e. something you can't get with AWS. This means that you can control what's running behind the APIs - that's what helps make it really work for you,” Fishman adds.
“Consider this example from the old relational database world, JDBC and ODBC seemed mostly portable at development time. But once you got to production, different implementations really undermined compatibility, so you'd struggle to jump from MySQL to Oracle to Sybase and back.”
Fishman asserts that the situation with OpenStack and Amazon is similar to the cross-database implementation challenges of old. That is, OpenStack is its own product. “Trying to pin it to the third-party API with which it is not compatible and which it does not control, isn’t a good idea,” Fishman adds.
"OpenStack must focus on its own roadmap and design excellence and have its API available to the outside world for people to integrate with it.”
There will be (and already are) companies who focus on creating tools that unify all clouds such as Enstratus, Rightscale and so on and there will be further unification happening through the efforts of IBM et al.
Mark Tomlinson is CTO for IBM’s UK and Ireland cloud computing division. He reminds us that open source projects such as Apache DeltaCloud and LibCloud have provided mechanisms to map between different cloud APIs for some time - including OpenStack, Amazon EC2 and the DMTF CIMI standard. “The use of approaches like these appear to be a sensible solution to the problem, rather than implementing proprietary interfaces in the OpenStack core,” he says.
AWS APIs no longer the cloud 'lingua franca'
IBM’s cloud group points out that IBM's SoftLayer cloud service hostcabi.net now hosts six per cent of websites worldwide. So as far as Big Blue sees it, AWS APIs are no longer the 'lingua franca' of the cloud anyway.
For a group and technology foundation so dedicated to openness from the start, OpenStack certainly had its critics and challenges. This in and of itself is perplexing in some ways. Firms need to run a heterogeneous mix of information technology systems, so (it is 2013) shouldn’t cloud interoperability have been something of a “baked in” given by now?
Chris Haddad is vice president of technology evangelism at WSO2, a platform and service framework vendor whose offering runs on both OpenStack and Amazon AWS. Haddad suggests that, just as IBM Tivoli or HP OpenView users need to manage multiple operating system instances, today’s cloud management platforms need to provide a complete view of cloud operations spanning both OpenStack and AWS cloud zones.
“Just as organisations want their chosen application server to run on both Microsoft Windows and OpenSUSE Linux, they want PaaS framework software to run on Amazon AWS, OpenStack or Windows Azure,” he says.
Would end-user companies benefit if OpenStack IaaS software presents an Amazon AWS-compatible interface and delivers a common view to cloud management platforms and PaaS frameworks? Probably not, Haddad suggests.
Interface compatibility is not the problem
The cloud evangelist continues, “Cloud management and PaaS frameworks already commonly rely on abstraction layers, such as the one offered by Apache jClouds, to support both multiple IaaS APIs. By keeping the OpenStack API and Amazon AWS API ‘pure’, the competing IaaS technologies can continue to innovate on both interface and implementation.
Adopting today’s IaaS solutions is not dramatically inhibited by cross-service provider interface compatibility, but by incompatibility with policies and service provisioning sequencing that live below, or are orthogonal with, the interface.”
Where we might see OpenStack and Amazon converge in harmony is on a single set of provisioning, metering and management interfaces i.e. rather than some more granular code-level API gateways. This could work well as we have already seen cloud providers further ‘up the stack’ who have built abstraction layers to try and deliver what they like to call “baseline interoperability” to users.
These mollifying suggestions will not stop Eucalyptus CEO Mårten Mickos saying (as he did) that OpenStack “will probably never take API compatibility seriously” as it forges ahead its own.
Mickos is quoted on Jaxenter as saying that this stubbornness will, ultimately, come back to haunt the OpenStackers. “For workloads to be able to move between clouds, APIs must be compatible,” he says.
“For hybrid clouds to happen, APIs must be compatible. OpenStack is now heading for hybrid cloud only within the narrow set of OpenStack clouds and a number of them are not even internally and mutually compatible.”
Echoing this tune is Randy Bias, acting CEO and co-founder of Cloudscaling. Bias says that he has made no secret of his belief that the lack of a differentiated set of APIs will harm OpenStack. Perhaps it already has?
In what he calls an open letter to the OpenStack community Bias wrote: “Embracing Amazon serves the interests of all community members by positioning OpenStack as the best choice for enterprises and SaaS providers that want an ecosystem approach to public cloud, one in which their applications can move to the infrastructure best suited to the job at that time.”
On the one hand we have Cloudscaling’s Bias saying that the time has come for the OpenStack community to choose a public cloud compatibility strategy that will position the project for dominance in the private and hybrid cloud markets. On the other hand, we have Rackspace’s Robert Scoble with his retort where he says that not a single startup has told him that they won't go with OpenStack because of API compatibility issues.
Do we have a definitive answer, concluding argument or clear way forward here then? I’m afraid not. We do, at least, have a reasonable balance on both sides of the equation. One almost wishes there had been a more open software architecture discussion at the start, but that would have necessitated total cross-industry buy in.
And that’s a compatibility Nirvana beyond anybody’s realistic reach.
