OpenStack and Cloud Foundry
OpenStack and Cloud Foundry
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
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.
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.
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.
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.
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.- See more at: http://www.activestate.com/blog/2014/05/openstack-and-cloud-foundry#sthash.PgxvbWPp.dpuf
Published at DZone with permission of Phil Whelan , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.