Two cloud industry heavyweights debate the pros and cons of OpenStack support for Amazon APIs.
If you were hoping for a barroom brawl, it was a severe disappointment.
At the same time, last week's debate between Randy Bias, CTO of Cloudscaling, and Boris Renski, CMO and co-founder of Mirantis, scored important points about the value of application programming interfaces (APIs) and cloud architecture. And it dealt at length with the wisdom -- or lack thereof -- of focusing on Amazon APIs while inside the OpenStack project.
The protagonists are two outspoken members of the cloud community. Bias is known for assuming leading positions in the industry without showing any vestige of faintheartedness. At one point during the debate he said he was advocating Amazon APIs because Rackspace was the source of two core sets of APIs already in OpenStack: those for the Nova compute and Swift storage services. Rackspace's influence is waning in the open source project, he noted, so he had chosen this moment to "kick it in the teeth" and try to correct Rackspace's early influence in the project.
Renski, who was more soft-spoken during the debate, is known as one of two OpenStack board members who voted against admission of VMware to the project on the grounds that its interests were incompatible with the success of OpenStack. He also predicted PayPal would become an all-OpenStack shop, replacing VMware, as consultants from the firm he founded, Mirantis, were attempting to make the first PayPal server conversions. PayPal contradicted his statement at the time and announced continued support for VMware.
APIs are the gateways through which outsiders call into a cloud service supplier. Amazon APIs amount to a de facto standard, many observers agree, while OpenStack is seeking to create services, and their APIs are recognized industry standards that are adopted by many companies.
The leadership of the open source code project has demonstrated a continuing antagonism toward Amazon Web Services. This "us versus them" mindset is misplaced, Bias said in his opening statement. He stated that OpenStack should support Amazon's APIs as a matter of course.
"When you look at AWS' APIs, it's a little ridiculous to say they stifle innovation," Bias added. "They've been extremely stable. Amazon controls them, but they very rarely break backward-compatibility. So we're just talking about adding new features and functionality [not fixing compatibility]. It's a fast follow strategy."
Bias has a vested interest in the matter. His firm, Cloudscaling, offers a re-engineered version of OpenStack, dubbed Open Cloud System, which includes both standard OpenStack APIs and support for Amazon Web Services APIs. It's a dual, or hedged, bet. But it has the potential of erasing for cloud users the great divide between Amazon's EC2 and OpenStack clouds. An application that could call up compute and storage in one cloud would be able to do so just as easily in the other with no changes required.
Renski, whose company, Mirantis, is the largest OpenStack consulting firm, countered that every successful open source project produces its own native APIs, and OpenStack should do so as well. It would thwart the project's capacity for innovation to be caught aping Amazon.
Bias swore that no one was more devoted to the OpenStack project than he. He pledged eternal faithfulness to the OpenStack code, if only its authors wouldn't be so developer-centric and pig-headed about AWS.
Putting the focus on Amazon was the wrong thing to do in a young OpenStack project, countered Renski. "Any system, in my opinion, has to have its own native APIs. Having a native API doesn't preclude you from making some sort of effort at being cross compatible with other platforms." Renski then stated that Bias was "muddying that focus" with his July 24 blog on the need for Amazon APIs. "In the original manifesto that Randy produced, it wasn't clear what we're talking about," Renski challenged. "Are we talking about throwing away the native OpenStack APIs?"
Predictably, the question was a match applied to a short fuse. "No, it was absolutely, crystal clear," Bias started to respond. "I've had to go back and read it multiple times..."
"You even went back and had to put a follow-on letter," jibed Renski.
Moderator Joe Arnold, CEO of SwiftStack, a cloud storage company based on OpenStack Swift storage, intervened to point out that an OpenStack technical committee said the project was going to support one set of APIs, and everything else would be outside of that. "Do AWS APIs need to be an official thing?" he asked.
Bias responded, "I'm OK if they [AWS APIs] are outside of the core [OpenStack code]."
Renski appeared to agree that it would be feasible to include support for more than one API set, provided the project leaders were clear which set was essential and received the primary effort.
Bias then returned to a favorite theme. "The first thing I ask is, I want the community to stop saying it's us against Amazon. I think it's a totally ludicrous attitude. It's like saying OpenStack vs. VMware. We need to go co-opt these systems. OpenStack should support the [VMware] vCloud Director APIs the same way it supports the AWS system ... that's my belief. Whether it's in core or not, I don't really care."
Renski insisted that maintaining compatibility with Amazon APIs should be left to third parties and not become a burden of the project. Experience has shown that third parties are the most reliable source of the translations needed between two competing ecosystems, he said.
In a flash poll conducted on Twitter after the debate, 30 respondents thought it was a good idea to include support for Amazon APIs; 10 thought it was a distraction and would diffuse the OpenStack effort.
In a follow-up comment to the debate, Alliancecloud founder John Seyer called it "insightful, but [it] also just scratched the surface of the subject."
Multicloud Infrastructure & Application ManagementEnterprise cloud adoption has evolved to the point where hybrid public/private cloud designs and use of multiple providers is common. Who among us has mastered provisioning resources in different clouds; allocating the right resources to each application; assigning applications to the "best" cloud provider based on performance or reliability requirements.