Writing CloudFormation templates becomes difficult to manage once you start using it heavily. Whether it is one complicated template or multiple simple templates, maintaining the templates are a decent amount of work. This post talks about why I built a tool called lono to help manage and generate a large amount of CloudFormation templates.

How It Starts

When I first started using CloudFormation, I worked with a colleague who showed me how CloudFormation worked. He built out 10 CloudFormation template and things were humming along great. One day, I requested that we change the user-data script to write the name of the stack to a file upon launch. For those who have not heard about the user-data script, it is a script that EC2 runs at launch time that allows you to do anything you want on the newly launched instance. It provides a nice hook into the bootup process of an instance.

The idea was that our chef recipes would be able to use this file that contained the CloudFormation stack name and perform conditional logic based on it. For example, if it was a web server vs a worker server then the chef recipes would do different things.

My colleague quickly agreed that this made sense and proceeded to go update the 10 CloudFormation templates. 4 days later, he came back to me and mentioned it was all coded, tested, and ready to roll out!

Of course, at that point, I thought of another change that we needed to make to the user-data script globally again. My co-worker gave me a wide eye look, shrugged his shoulders, sighed and reluctantly agreed that the change requested made complete sense. It was obvious that the way we were manually managing CloudFormation templates was not sustainable and it could not continue.

Enter Lono

So instead of maintaining the CloudFormation by hand, I wrote a tool called lono to generate the CloudFormation templates. The initial version was written over a weekend. That Monday I showed it to my colleague, and ask him if it would help make his life easier. He happily used lono because it made it easier for him to manage the CloudFormation templates. Lono was built directly from real life use cases and asking the right questions.

DSL vs Generator

I’ve put a lot of thought into whether or not to use a DSL to write CloudFormation templates. There are plenty of DSLs out there for CloudFormation that are really great. Here are just some examples:

I have lean on using a generator over a DSL because of the development workflow that I’ve usually seen with CloudFormation. When building CloudFormation templates, I’ve seen engineers search the internet, find an example CloudFormation template that is closed to what they are looking for, modify it ever so slightly so it works for their business use case, and then run with it.

With this development flow, a template generator results in less work because you do not have to end up having to translate the raw template into the DSL syntax.

Results

Ultimately, we were able to go from barely being able to manage 10 CloudFormation stacks to efficiently managing over 250 CloudFormation stacks based on 4 main core templates. Without lono we it would had been a copy and paste nightmare and a very painstaking and brittle process. Lono made it possible. Hope this helps and you check out lono for your own project! If you have any questions about it feel free to contact me!

In a follow up post, I’ll cover how lono works in detail: Generating CloudFormation Templates with Lono.