Is OpenStack Heat Really Compatible With CloudFormation ?
ELECTION NIGHT
I was at an election viewing party last week; yes, that election! And I just happened to run into the Director of a cloud services company. A nice guy from Big Sky country, who’s running an OpenStack shop.
After the usual talk about Docker, Containers, and the Cloud — we started talking about Cloud orchestration. For those not in the know, cloud orchestration is the arranging, and coordinating of automated tasks, which ultimately results in a consolidated process or workflow. In essence, It’s the way to ensure that automated tasks happen in the correct order, and at the right time; scaling up when needed and scaling down when needed.
There are a lot of startups offering Cloud orchestration solutions, and during our conversation — it came up that I use AWS CloudFormation for orchestration, while he uses OpenStack.
Which made me wonder, what are the differences between AWS and OpenStack Cloud orchestration? And in particular, templates?
OPEN STACK & CLOUD FORMATION
For orchestration, I use CloudFormation templates to define the architecture of what I’m building; Cloud Formation templates are defined in a regular text file called at the template. Since it is a text file, it can easily fit into your current workflow, source control, and peer review, etc.
These template files define your instances, how they work together and how your app will scale. AWS defines CloudFormation templates as a JSON formatted file (and recently added YAML), OpenStack uses Heat to define templates in a CloudFormation compatible JSON file, as well as a YAML-based template called HOT (Heat Orchestration Template).
Heat is the main project in the OpenStack Orchestration program; it implements an orchestration engine to launch multiple composite cloud applications, this is based on templates in the form of text files that can be treated as code.
OPENSTACK HEAT
AWS CloudFormation and OpenStack Heat has a lot in common, both OpenStack Heat and CloudFormation templates treat “infrastructure as code”. Both support test template files and support CloudFormation formatted template files.
While the two have a lot in common, they also have differences. The question becomes what are the differences between CloudFormation templates, and CloudFormation formatted Heat templates? Remembering that HEAT templates are not designed to be an exact clone of AWS but as a compatibility layer for CloudFormation templates.
I expected some differences and the first thing I noticed was the difference in the number of resources that are available to use in templates. Resources are a section in your CloudFormation template that lists AWS/OpenStack resources, such as block storage, or compute servers, which you want as part of your stack.
While the format is the same, the resources available in AWS and OpenStack are not, specifically, a lot of resources that you can use in your CloudFormation template are not 100% complete or missing entirely in Heat.
A lot of the missing resources are optional resources, in fact, just glancing over the OpenStack documents, I saw a few things that were not there. These were not show stopper issues and could be worked around, for example, Heat is missing a HealthCheckGracePeriod for the autoscaling resource (AWS::AutoScaling::AutoScalingGroup).
When you are starting up instances, sometimes the instance has to perform some action or warm up before it’s ready. The HealthCheckGracePeriod tells auto scaling to wait a certain amount of time before performing a health check on an instance.
WRAPPING UP
OpenStacks Heat seems to be very compatible with AWS CloudFormation for simple CloudFormation templates. Heat natively supports CloudFormation templates which will help those familiar with CloudFormation to get up and running on OpenStack Heat quickly.
If your CloudFormation template happens to only use the resources that are available in OpenStack, then they should work with little modification in OpenStack Heat.
Was this post interesting? If so, please click the ❤ below to let me know , it really does help. Greg Coleman is a freelance consultant based in Annapolis, Maryland. Currently waiting for the first snowfall of the season. If you are looking for a contractor, you can contact me here https://gregorycoleman.github.io
