News Archive


Application Definition with Heat

Steve Hardy (OpenStack Heat PTL) and I gave a talk today about the past, present and future of defining cloud applications with Heat. Since this may be of general interest to the OpenStack community, we are making the handout available for download.

An introduction to Heat templates, how they are used to define the configuration—particularly the software configuration—of an application and future plans for the template format.

An Introduction to OpenStack Orchestration

The forthcoming Havana (2013.2) release of OpenStack will mark the debut of orchestration as part of the official release. It arrives in the form of the Heat project, which kicked off in early 2012 and graduated from incubation into OpenStack-proper after the Havana Summit in March this year. Heat is so named because that’s what raises clouds, and it isn’t an acronym for anything, so y’all can give your caps lock keys a well-earned rest now.

The term ‘orchestration’ is often a source of confusion, but you can think of it as configuration management for infrastructure. It’s about symbolically representing various pieces of infrastructure (known as resources) and the relationships between them directly, rather than modelling only the actions you can perform on them. It’s swapping imperative programming for declarative programming; verbs for nouns. When you need to make a change to your infrastructure (including the initial deployment), instead of doing so manually or writing a single-use script to manipulate it, you write a template that describes the end result and hand it off to the orchestration engine to make the required changes.

Heat began life as an attempt to provide compatibility with AWS’s CloudFormation service. That remains an important goal—we want to give users who have invested in creating CloudFormation templates the choice to run them on an open cloud—but Heat has evolved into much more. In addition to the CloudFormation compatibility API and templates, Heat also sports an OpenStack-native Rest API, native representations of OpenStack resources, and a richer template format.

One of the big advantages of orchestration is the ability to treat infrastructure as code and take advantage of all the tools that that entails. You can check the source code for your infrastructure into version control alongside the source code for your software. That is one of the reasons Heat uses Yaml markup for templates rather than JSON (as CloudFormation does) or, worse, XML—it’s easier to read, write and diff. If you want to write software to manipulate templates automatically, that remains equally easy since Yaml syntax is a strict superset of JSON and templates can be translated with full fidelity in both directions.

There are numerous example templates available in the Heat templates repository on GitHub. The simplest examples involve spinning up a Nova server running WordPress and MySQL; others add in more resource types to demonstrate how to integrate them.

With the Havana release coming up in October, now is a great time to start investigating how orchestration can simplify your workflow and make your deployments more repeatable. Check out the getting started guides and let us know on Ask OpenStack if you have any questions.