4 Comments

Summary:

CloudScaling CTO Randy Bias argues that Amazon Web Services APIs are already the lingua franca of the cloud and supporting them is key to OpenStack success.

Amazon Web Services
photo: Flickr/Will Merydith

Brace yourself. The religious wars between those who believe support of Amazon Web Services APIs is critical to cloud success and those who think the OpenStack players need to forge their own path, are about to flare anew. That’s thanks to a new blog post – just in time for OSCON Open Source Convention – by Cloudscaling CTO Randy Bias, who is definitely in the pro-Amazon API camp.

Randy Bias, CTO of Cloudscaling.

Randy Bias, CTO of Cloudscaling.

His take is that Amazon– and perhaps Google Compute Engine — will be the public cloud forces to reckon with and that OpenStack players need to support those dominant APIs to succeed broadly. Bias wrote:

“It is clear that AWS (and quite likely GCE) will utterly dominate the public cloud race. But more importantly, who cares? Dominance by AWS and GCE does not mean that OpenStack fails. In fact, OpenStack is clearly on a trajectory to ‘win’ the private cloud race, and a rapid embracing of Amazon will put OpenStack in the pole position to dominate hybrid cloud.”

Cloudscaling itself pledges support to both key AWS and GCE APIs. Rackspace on the other hand, sees OpenStack as a rival architecture to AWS in the public cloud, as well as the foundation for private and hybrid cloud implementations.

The issue, in his view, is that Rackspace, which launched OpenStack with NASA more than three years ago, is hurting OpenStack’s cause by dissing AWS APIs and pushing what are in effect Rackspace’s own APIs as OpenStack APIs.

The original OpenStack back in 2010 had no so-called native APIs in the Nova compute component that came out of NASA. Indeed, Nova at first supported (wait for it) Amazon’s EC2 APIs. Rackspace later added its own APIs to the mix, he writes. On the other hand, the Swift storage component of OpenStack, which Rackspace supplied, supported APIs created by Rackspace for its Cloud Files service.

As Bias wrote: “… OpenStack originated with ‘native’ APIs, where one half was AWS compatible (Nova) and one half was Rackspace public cloud compatible (Swift).” OpenStack, which is now governed by a multi-vendor foundation — not Rackspace — should embrace the dominant cloud APIs and stop pussyfooting around, in his view.

“It is clear that AWS (and quite likely GCE) will utterly dominate the public cloud race. But more importantly, who cares? Dominance by AWS and GCE does not mean that OpenStack fails. In fact, OpenStack is clearly on a trajectory to “win” the private cloud race, and a rapid embracing of Amazon will put OpenStack in the pole position to dominate hybrid cloud.”

Rackspace, for its part, has repeatedly said such AWS support is a non-starter. As Rackspace CTO John Engates told me last year,

“We don’t need to be compatible with the AWS APIs … OpenStack itself does have some compatibility with the Amazon APIs but Rackspace is not exposing that compatibility in its public cloud … mapping to AWS APIs restricts innovation. If you have to wait for Amazon and reverse engineer [what it does], where’s the innovation? We want to spur innovation.”

Bias, who will speak at Structure: Europe in September,  has long held this “support the dominant API view” and has written about it repeatedly. So why a new blog post now? Bias said via email that he felt the need to clear up misinformation about the “so-called ‘native’ APIs [because] people don’t understand that OpenStack not only has AWS APIs but that it STARTED with them before Rackspace APIs were added.” (Emphasis is his.)

“I am also pointing out Rackspace’s failure in leadership in this regard. By trying to get OpenStack to formulate an opposing standard to the de facto AWS standard, they are, in fact, taking the community down a dangerous course that could lead to failure.”

Your move Rackspace.

  1. OpenStack indeed started out with EC2 compatibility (which they later abandoned): the first incarnation of OpenStack Nova was a fork of an early Eucalyptus release.

    Eucalyptus has been AWS API compatible all along. Today we support EC2, S3, EBS, IAM, ELB, CloudWatch and AutoScaling. That’s why Netflix’s ChaosMonkey and other tools run not only on AWS but on Eucalyptus too. That’s why AppDynamics, Mosaik Solutions, Nokia Siemens Networks and others can move workloads effortlessly between AWS and Eucalyptus.

    The AWS ecosystem and user community is absolutely enormous, and it makes good sense to be compatible. That *is* the hybrid opportunity of the cloud world.

    Marten Mickos, Eucalyptus

    Share
    1. > OpenStack indeed started out with EC2 compatibility

      true

      > (which they later abandoned)

      maybe

      > the first incarnation of OpenStack Nova was a fork of an early Eucalyptus release.

      false. The first incarnation of NASA’s Nebula cloud was a Eucalyptus fork, the first incarnation of what became Nova replaced the Eucalyptus in Nebula but still used EC2 APIs. Details matter.

      Share
      1. Thx for the clarification!

        Share
  2. It’s surprising, Mr. Mickos, that you would bring up OpenStack Nova’s origin in that context. It begs the question why was it a fork? It has a similar smell of the technical forks of MySQL, because of partners and customers inability to get MySQL AB to accept fixes without licensing issues.

    To suggest that EC2 compatibility has ever been abandoned by OpenStack is offensive, and I’m disappointed a competitor would make that claim without providing strong supporting data.

    Although I have many reservations about how Rackspace has led the OpenStack project, AWS APIs are not open and during this time there was a real fear that a court could rule APIs copyrighted, see http://en.wikipedia.org/wiki/Oracle_v._Google .

    I fully agree that all open Cloud OSs should support as much of the dominant APIs as possible, but for complex products implementation always leaks into the APIs. There are always *native* APIs.

    Lloyd Dewolf, Piston Cloud

    Share

Comments have been disabled for this post