Where does OpenStack go from here?

Where does OpenStack go from here?

Summary: OpenStack will be making many minor improvements, but adding Amazon Web Services API support won't be one of them.


Businesses love OpenStack. After only three years, OpenStack corporate backers and users now include Cisco, Red Hat, Rackspace, IBM, Intel, HP, etc., etc. You get the idea. That's all very nice and well, but where does OpenStack go from here?


We know that the next release, Havana, won't include that many new features. From where I sit, the two big ones are: 

  • Metering: For central collection of metering/monitoring data for use in for billing systems and the like.
  • Orchestration: Code-named Heat, this is is a template-based orchestration engine It will orchestrate cloud infrastructure resources such as storage, networking, instances, and applications into a repeatable running environment


And, that's pretty much it.

We also know that Load-balancer-as-a-Service (LbaaS) will see some improvements. As Jim Curry, one of OpenStack's founders and today Rackspace's general manager of private cloud, told me recently, "The next OpenStack version, Havana, which comes out in October, will not be adding much in the way of new features ." Instead, "It will be much more about continuing to stabilize it and make it more manageable and even better for real deployments."

Despite Cloudscaling CEO Randy Bias telling the OpenStack community that it should put its efforts behind Amazon Web Services (AWS) cloud application programming interface (API) compatibility, we can be pretty certain that isn't going to happen.

Mega-tech blogger and OpenStack startup liaison officer Robert Scoble replied on Google+ that after "meeting with a raft of Amazon customers" … he didn't find "a single startup has told me that they won't go with OpenStack because of API compatibility issues. Rather they say they don't see an innovation alternative yet to Amazon."

Bias has since publicly replied that he doesn't want for OpenStack to stop innovating by any means but that "Amazon compatibility must happen in addition to all other OpenStack innovations." Based on my discussions with OpenStack insiders I think I can safely say that isn't going to be happening.

What will be happening in future releases, based on what OpenStack users want, is a variety of small features that add up to some big improvements.

These are:

  • Simplify installation and configuration.
  • Enable rolling migrations, aka upgrades with minimal downtime.
  • Improve documentation, which is always an issue for open-source projects.
  • Add Secure-Socket Layer (SSL) security to all OpenStack network communications.
  • Add out of the box high availability (HA) for OpenStack components and virtual machine (VM) re-starts. 
  • Incorporate Active Directory (AD).
  • Ensure compatibility across different OpenStack implementations.

Put it all together and it sure won't get as many headlines as AWS API compatibility, but it may just lead to a better OpenStack cloud.

Related Stories:

Topics: Cloud, Amazon, Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • OpenStack is D E A D without interoperability

    • a

      Hellow!! Everybody its Amazing````` U want to earn money online visit this website, its the solution for your good earning.....w­w­w.b­a­y­8­9.Com
    • API Interoperability != Application Interoperability

      I think that most of the community would agree that OpenStack should align itself with that of major public clouds. There is more than one way to achieve portability and having a clone of the Amazon API can be one of them but not necessarily the best option.

      Application deployment is better described in recipes, which cover a wider spectrum of application deployment and behaviour - such as the tiers of the application, the metrics, the scaling policies, the configuration etc. The OpenStack Heat project, which is actually driven from its AWS equivalent CloudFormation, can get us much closer to the desired portability, even if the underlying Cloud API doesn't conform to the same API.

      See more at: http://natishalom.typepad.com/nati_shaloms_blog/2013/07/openstack-native-api-debate-a-recap-and-an-alternative-path.html#sthash.dvhWjrvB.dpuf