ActiveBlog

OpenStack and Cloud Foundry
by Phil Whelan

Phil Whelan, May 21, 2014

Last week I attended the OpenStack Summit in Atlanta, which was a great opportunity to further understand the relationship between Cloud Foundry and the OpenStack ecosystem.

Cloud Foundry seems like a contentious issue in the OpenStack camp with "it's not OpenStack" being the main theme of discussion when discussing PaaS. Should PaaS be fully integrated with one specific IaaS or should there be a clear separation between IaaS and PaaS?

Cloud Foundry clearly defines and provides a PaaS that will run very well on any OpenStack deployment. Stackato has shown that Cloud Foundry will also work equally well on any infrastructure such as Amazon EC2, CloudStack, vSphere or KVM.

Solum

I attended a few sessions on the OpenStack application deployment project Solum and its related technologies. Architecturally it is different to Cloud Foundry and heavily leverages existing OpenStack technologies. For instance, it uses Heat for managing images of staged applications. It uses Murano for cataloging staged applications and then uses this catalog as a source of services which can be provided to other applications.

There was some debate in a design session on how applications and their services should be assembled. For instance, if I deploy Wordpress can I assemble it with either MySQL or PostgreSQL? Where are the limitations on how these can be mixed and matched? Should the person deploying an application really be making these decisions or should it be constrained by the developer - who actually knows what the application is compatible with? I think this is a problem that Juju solves (see below).

As Solum defines its space in the OpenStack ecosystem, it is careful not to step on the toes of other components. I often hear the phrase "well, doesn't X already do that?". This results in keeping the OpenStack architecture DRY ("don't repeat yourself"), but it also means that the PaaS solution is heavily dependent on other OpenStack components. PaaS becomes less of a separate layer on-top of IaaS and instead is integrated so deeply with it that there is no distinction between the two. Do we want OpenStack to be IaaS+PaaS or "everything that is private cloud"?

The future of Solum plus Murano plus Heat? I think it's unlikely that Solum and Murano will dissapear, no matter how widely adopted Cloud Foundry is. These pieces may still make sense in an OpenStack context. As long as these building blocks remain distinct in function they could be repurposed in different ways. They may even be used to complement OpenStack plus Cloud Foundry deployments in the future. This building block nature of OpenStack is one of its strengths.

But when it comes to adoption, I have to ponder why large players in the industry would make the investment and take a risk on Solum as a PaaS solution when Cloud Foundry is so far ahead and moving so quickly.

HP Helion

Nick Walker - HP Helion - YouTube Nick Walker from HP introduced us to how PaaS fits into their new HP Helion solution with his talk "Cloud Foundry, OpenStack, and the Enterprise Developer".

HP has committed a billion dollars to ensuring the success of HP Helion.

While short on implementation details, Nick did go into the reasoning behind choosing Cloud Foundry over a solution like Solum. Maturity and adoption were factors, plus their existing knowledge and investment in Cloud Foundry.

HP Helion will look at bridging the gap between OpenStack and Cloud Foundry, by integrating OpenStack's Keystone authentication and high-level authorization system.

HP will also integrate some of their other data services for use with Cloud Foundry deployed applications. The new Cloud Foundry v2 service architecture simplifies this integration and we are seeing improvements to this with each point release of the service API.

Juju

At Canonical's Ubuntu OpenStack evening event during the OpenStack Summit, I was given a demo of Ubuntu Juju, which I thought showed real promise. The GUI showed simple wiring together of components for provisioning an entire architecture. Each component defines what it provides and what it requires and the two are married together to deploy complex systems.

For an example of how a deployment might be constructed, Wordpress requires "mysql" and a filesystem. MariaDB provides "mysql", so it can be a drop-in replacement for MySQL. Juju handles the glue, networking and infrastructure allocation.

With Juju you can deploy Ubuntu OpenStack straight on top of hardware using their MaaS (Metal-as-a-Service). Cloud Foundry can also be deployed with Juju charms, although this is still in development. I am definitely interested in the work that Canonical is doing here with Cloud Foundry deployments.

You can find an online example at jujucharms.com.

Conclusion

Right now there are clear leaders in private IaaS and private PaaS: OpenStack and Cloud Foundry respectively. You can definitely run Cloud Foundry without IaaS and there is no requirement to run a PaaS when running OpenStack. But if you are looking at full stack dynamic cloud architecture to deploy applications, then OpenStack plus Cloud Foundry is the way to go. That's not my opinion; that's the way the industry is going.

HP is committed to this pairing with HP Helion. Canonical is also committed to Cloud Foundry with its inclusion in Ubuntu OpenStack as Juju charms. We also see many large players in the OpenStack camp, such as IBM and RackSpace signing up for the Cloud Foundry foundation and pledging resources to ensure its success.

So what is the fastest way to get up and running with Cloud Foundry on OpenStack? You can download the Stackato virtual appliance for OpenStack or deploy Stackato on HP Cloud.

Title image courtesy of peddhapati on Flickr under Creative Commons License.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

Phil Whelan has been a software developer at ActiveState since early 2012 and has been involved in many layers of the Stackato product, from the JavaScript-based web console right through to the Cloud Controller API. Phil has been the lead developer on kato, the command-line tool for administering Stackato. Phil's current role is a Technology Evangelist focused on Stackato. You will see Phil regularly on ActiveState's Blog. Prior to coming to ActiveState, Phil worked in London for BBC, helping build the iPlayer, and Cloudera in San Francisco, support Hadoop and HBase. He also spent time in Japan, where he worked for Livedoor.com and met his wife. Phil enjoys working with big data and has built several large-scale data processing applications including real-time search engines, log indexing and a global IP reputation network. You can find Phil on Twitter at @philwhln, where you can ask him any questions about Stackato. Alternatively, email at philw at activestate.com