Share this post:

With the introduction of OpenStack Heat, you can now deploy an entire cloud application, defined as a template, in a single shot. Before Heat, OpenStack cloud resources needed to be provisioned individually and combined together to build the application. For example, you would request two compute resources separately, and then you would need a network resource to connect them.

In the OpenStack Dashboard, a Heat template can be provisioned by passing a file, a URL or direct input.

But how can you provide governance over the templates that are being used? Meet IBM UrbanCode Deploy with Patterns, where an application developer can design a Heat template using a graphical or text editor, as shown in the following image:

UrbanCode Deploy with Patterns then can persist and catalog all the templates that have been defined.

Now, how can you expose these templates to a user in a self-service interface?

IBM Cloud Orchestrator provides a platform where cloud applications can be deployed as a sequence of orchestration steps and exposed in a self-service user interface, as you can see in the following picture:

This combination enables a powerful DevOps environment in which the application developer utilizes UrbanCode Deploy with Patterns to design and persist the Heat templates, and the user requests them in Cloud Orchestrator. This allows the governance of the Heat templates on the development side, and a clear delimitation on the applications a user can provision on the operational side.

What are your thoughts? Please leave a comment below or get in touch with me on Twitter at @patrocinio