It’s OSCON week, and three years since OpenStack was officially launched – in that time it’s built a vibrant ecosystem, real world customers and more debate than anyone would have ever imagined. There are some notable critics, none so vehement as Simon Wardley who has opined time and again that OpenStack is a “dead duck”. Wardley – a keen observer of competition and organizational evolution is also, interestingly enough, an adviser to CloudScaling. Interesting indeed since CloudScaling is a strong OpenStack partner and CTO Randy Bias has been on board with the initiative since day one. Wardley’s strongly held view is that OpenStack should capitulate in the face of Amazon’s dominance, a view countered in the strongest way by Rackspace OpenStack evangelist Scott sanchez:

Anyway, the already complex situation is being notched up a decibel or ten today with a publication of an open letter penned by Bias to the OpenStack community in which he advocates an immediate and purposeful embrace of Amazon and the AWS API by the OpenStack community if the project is to survive. Bias is well known for big grandiose statements that are designed to generate significant attention and controversy – this post is likely to similarly be a spark to howls of protest from some and agreement from others.

In his letter Bias not so subtly criticizes the members of the OpenStack community (most notably Rackspace) who, for their own commercial reasons, hold the view that OpenStack should build it’s own set of differentiated APIs. Bias details the history of the OpenStack project and then calls for members to assert their control of the project and to follow a strategy that, in his mind, is in all members best interests, not just those of a single contributor (ie Rackspace).

Bias rightly points out that AWS dominates the public cloud race and suggests that the only way for OpenStack to ensure it is well positioned in the private and hybrid cloud space is to embrace the AWS API set. He also writes of the apparent growth of Google’s own cloud services and contrasts the rise of both AWS and GCE to the marked plateauing that Rackspace is suffering – he then draws the conclusion that AWS and GCE are the natural strategic alignment direction for the OpenStack community. When referring to AWS’ amazing innovation speed, Bias states that:

In 2010, some argued that standardizing on the Rackspace public cloud APIs would allow OpenStack to control the innovation curve instead of Amazon. Since then, Amazon has continued to push new features into production at a breathtaking pace. They are, quite simply, in control of the innovation curve in public cloud. Every public cloud feature added by an AWS competitor is measured directly against what AWS has already built.  OpenStack can be in control of the innovation curve in private and hybrid cloud, but doing so requires that we support the services that are leading the innovation curve in public cloud. For OpenStack to dominate innovation in private and hybrid, it must embrace the public clouds to which enterprises want to federate.

Finally Bias makes a number of proposals:

  1. Embrace major public cloud
    1. APIs: GCE, AWS, Azure, and possibly vCloud
  2. Rename the Nova API to the Rackspace Cloud Servers API
  3. Create a new low level API and move to the bridged API model
  4. Expand testing and the work around refstack
    1. Refstack should focus on public cloud interoperability & hybrid cloud
  5. Embrace existing AWS interoperability testing frameworks
    1. The Cloudscaling aws-compat and the Eucalyptus eutester library are examples

MyPOV

Well, firstly I’d love to be a fly on the wall of the Rackspace executive offices when Bias’ post hits the wire – it’s not going to be a comfortable place. But beyond Bias’ obvious rabble rousing rhetoric, his comments do raise some logical issues – AWS is beating all challengers on both market share AND innovation. GCE, while not disclosing real customer metrics has a significant following for all appearances.

Put simply, the question is whether the OpenStack ecosystem is sufficiently broad to give customers the full continuum of their cloud needs – while there are multiple example of both public and private cloud vendors within OpenStack, if there’s no one delivering a compelling public cloud offering, then the default position for customers is to go for AWS. While Rackspace, HP and others would point to their own public cloud products as being well regarded by customers, as Bias points out – all the public cloud providers together a tiny compared to the AWS onslaught.

Further questions lie about the long term make up of enterprise IT. If the future is, as I suspect, made up of enterprises using lots of different cloud offerings (not so much in a hybrid/cloud migration model but more of a discrete multi cloud approach) then there is less of an urgent need to resolve to one common API set. So long as there are products that give visibility and management over these discrete resources (and this is where Dell, with its recent acquisition of enStratius and dropping of its own public cloud play, is thinking) the actual interoperability or commonality of the different products API sets is secondary.

There’s no denying that life would be easier for many if the AWS API was the industry standard, it’s not however and I’d be surprised if many from the OpenStack community embraced Bias’ call. The balance of power, while much more even then three years ago, still lies with some vested interests so, in the meantime at least, Bias’ letter will get much attention and discussion, but little action.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

9 Comments
  • Greg Knieriemen |

    I can appreciate Randy’s concern here, but I keep coming back to this point: Is there sufficient customer demand for an AWS API within CloudStack? I’m not hearing it – I think it’s inferred from a spirit of offering a complete cloud experience. Nothing in Randy’s post points to customer requirements and needs. Rather it looks more of a philosophical / political disagreement. And philosophically, I think he’s right but I don’t believe OpenStack would have the ecosystem it has if it provided an AWS clone.

    Philosophically, I also believe competitive public cloud solutions are good for innovation.

  • The two most influential open source projects in history are Linux and MySQL. In each case, their success flowed from a very simple mission: to provide an open source implementation of an existing standard API (POSIX and SQL). Constraints are good: they provide focus, they allow you to distinguish between core features and optional elements, and they provide a clear set of shared goals.

    Greg asks whether the demand is there. Back in 2009 I was reading one RFP after another that asked for a NIST-style IaaS cloud with an AWS API. The question of alternatives didn’t arise until Rackspace pushed it.

    And while competition is nice, it’s worth remembering that many OSS markets devolve into a monopoly. Linux effectively killed OpenSolaris and FreeBSD. (Arguable PostgreSQL survived only because we knew Oracle would screw up MySQL.)

  • Ben

    I tend to agree with your bottom line:

    “If the future is, as I suspect, made up of enterprises using lots of different cloud offerings (not so much in a hybrid/cloud migration model but more of a discrete multi cloud approach) then there is less of an urgent need to resolve to one common API set.”

    The challenge of having a common API is that this common API needs to support all the aggregated features of all the API’s. Given AWS and GCE speed of innovation the complexity of continually chasing their API’s is underplayed in Randy’s post.

    Also the reference to CloudStack AWS computability isn’t accurate – To the best of my knowledge most of the CloudStack users don’t use the AWS bridge so in fact the CloudStack reference tells the opposite story than the way it was presented in the post.

  • Randy took to a public Crowdchat.net (a hosted, timed, public conversation) to address to the world his point of view. Here is the transcript from the thought leaders in Cloud and OpenCloud

    http://www.crowdchat.net/oscon

  • While I once panned the term , I have long believed that private and public clouds needed to look similar and connect if we’re to have massive cloud adoption. We are now seeing enterprise customers demand a hybrid cloud solution: a private cloud connected to a public cloud so they can run workloads in both places and generally have choice and control that drive positive economics and business agility.

  • Great! Finally the real discussions about interoperability are starting. Some are saying let’s adopt de factor standard, some are talking about their own standard (what is great about standards is that I can have one of my own), others are talking about open standards. For your information, cloud computing is about software engineering: a software engineer is able since decades now to remap any API into the one useful for his business. Only the quality of the behavior of the API counts. Today we are able to build interoperability by design and to make abstraction of any provisioning system whatever the service is (IaaS, PaaS, SaaS, XaaS). In CompatibleOne as in other tools such as Enstratius or Cloudify, these debates does not matter: you want EC2 you get, you prefer Nova you get it, OCCI you get it, CIMI let’s wait a bit it is ready ;). It’s all about software design and architecture. People saying it’s impossible are just trying to slow down progress for some obscure (or very clear) reasons. If the question is about remapping the latest gadget supplied by the API of one or the other, it will just be business as usual i.e. it will depend on customers’ demand. Do the customers need this new feature or do they prefer to keep a minimum set of features enabling their workloads to be portable from one provider to another? I suspect most customers would rather prefer to keep some independence whatever the brand, the success or the cleverness of the service provider.

  • De facto standards sometimes prevail …

    Furthermore, there is no reason for OpenStack to not support the AWS API. We in the software industry have supported APIs other than our own for quite some time, adding value by extending and improving and differentiating.

    There are more than technical issues at stake here. Training of people, development of services that span clouds, both local and public, etc. If OpenStack wants to be the player it believes itself to be, I think it needs to think a bit beyond itself …

  • Ben

    I think that most of the community would agree with the general sentiment behind Bias’ call that OpenStack should align itself with that of major public clouds. Now zero-in on the Nova API as the means for portability – this is where the debate lies and where I feel that Randy may be wrong in his assessment – See more at: http://natishalom.typepad.com/nati_shaloms_blog/2013/07/openstack-native-api-debate-a-recap-and-an-alternative-path.html#sthash.GxMFDLeM.dpuf

    Note that i was referring to your POV and later extended on that idea as a possible alternative approach for portability.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.