Instant Cloud With Stackato Cloud Foundry and Mirantis OpenStack

[This article was written by Navrup Johal.]

 Using a Platform-as-a-Service (PaaS) based on Cloud Foundry and an Infrastructure-as-a-Service (IaaS) based on OpenStack is fast becoming the de facto standard in cloud computing. Cloud Foundry has revolutionized the application development paradigm while OpenStack has transformed infrastructure management and operations. Both platforms are powerful, complex, and cutting edge – helping to deliver high quality software projects faster, better, and more efficiently.

Recently at an OpenStack Online Meetup John Wetherill, ActiveState Technology Evangelist, and Georgy Okrokvertskhov Mirantis Architect, OpenStack Platform Products demonstrated how Cloud Foundry and OpenStack technologies can work together. In the presentation, John and Georgy introduced some basic concepts around IaaS and PaaS, then showed how Murano created a cluster of Stackato instances and could be used to deploy applications to Stackato. With a few clicks and typing in a few fields, they were able to provision a full multi-node PaaS cluster and get going with production development.

Below is a recording of the online meetup, background information about the Murano project and some Q&A during the session.

The Murano Project on OpenStack

Mirantis is a pure play OpenStack company. They distribute OpenStack open source solutions to their clients, as well as providing professional services and support for OpenStack. OpenStack is an open source cloud platform which provides the coordination of compute, networking, and storage resources. Georgy demonstrated Murano, an application catalog implementation in OpenStack.

"The Murano Project introduces an application catalog to OpenStack, enabling application developers and cloud administrators to publish various cloud-ready applications in a browsable categorized catalog."

Georgy describes project Murano as follows: "This is an open source project, which is guided by the OpenStack community. It follows all OpenStack development processes rules. You can find this repository under https://github.com/stackforge/murano. The idea of this application catalog is to actually simplify the on-boarding process for applications which should be run on software with OpenStack infrastructure. This catalog provides a way for application developers to publish their application, and to share their applications with other cloud users."

Stackato: ActiveState's Private PaaS

We are known in the development community for our ActivePython, ActivePerl, and ActiveTcl language distributions. In addition, we also provide Komodo IDE and Edit for development. Recognizing that developers needed an easier way to deploy apps to the cloud, we created Stackato. Stackato is a PaaS based on Cloud Foundry and Docker that's fully enterprise ready and hardened. In the presentation, John provided a demonstration of how developers and ops people can make use of Stackato on top of any infrastructure, particularly OpenStack.

As John sees it, PaaS is rapidly becoming one of the biggest disrupters in software development in the enterprise today. In comparison to a few years ago, when nobody had heard of PaaS, most companies are at least moving towards using it. Similar to where source code management was, let’s say, 10 years ago where everybody started to hear about it, but not many people used it. Now, it’s unheard of to build a software project without SCM. PaaS is moving at that same level. enables much faster for getting code out the door, much higher productivity, and it gives you security.

Q&A During the Presentation

Q. When something is selected from this catalog, like WordPress, it’s taking care of building up the entire infrastructure for you, is that correct? You can specify the resource requirements that are needed. For example, the allotted memory and things like that, is that how that works? (7:12)

A: Yes. That is correct. When an application developer uploads an application...it actually uploads specific files, like manifest file, which actually defines what the application is, what are the flows to deploy it, what is the Heat configuration needed (which should be used to generate Heat templates) which will be used to provision OpenStack resources. By that, you can actually define the whole stack: starting from the infrastructure level requirements, what are the networking requirements, what are compute, storage requirements and then ending up with the application configuration part, which also will be done by this application catalog.

Q: You said Murano is capable of doing things that Heat itself isn’t. What’s one example of what Murano can manage that Heat is not capable of doing?(18:20)

A: urano exposes high level abstractions like the application, application interface, application requirements, and application capabilities. Those entities do not exist in the Heat level because the Heat level is very granular and it is specific to the resources. So you can see and manage some compute resource, IP address, floating IP, but this is sometimes too low level to define your application dependencies from each other. For example, you can say that I have my Java application, and it requires a database and a Tomcat instance to be deployed on it. In the Heat world, you will actually do the full stack definition, saying this is a VM, we just place it to this network, and this is a software component that should be placed on this VM. The dependency will be between resources, but not between applications. Murano is at an additional high level abstraction, representing more high level dependencies between applications without actually digging into the resource level stuff.

Q. The YAML used looks like standard YAML, yet it also looks like some sort of object oriented coding. It actually looks like you’re calling methods on objects. Can you say a little bit about that? It’s not normally how I would expect to see YAML. (33:53)

A: So Murano uses its own DSL, or Domain-Specific Language, which was specifically designed to orchestrate deployments on top of OpenStack, and it exposes the easy way of manipulation with the Heat templates, which will be generated under the hood. The security group manager will just go to the Heat templates and update the security group portion of this template. And you’re right. This is a YAML format, so you can use it to actually embed Heat template snippets directly to this workflow. You can have a Heat resource, defined here as a variable, and use it to update Heat templates with this Heat template snippet.