Over the last while, I’ve written quite a bit about the technical side of building flexible and reusable CloudFormation templates. However, I want to discuss something more difficult in this article - your template strategy.
As is the case in most situations, the technology side is ‘easy.’ Processes are entirely different.
You may think it’s easier to start with a simple strategy - everything in one giant, hard-to- understand/troubleshoot template - however, you should consider this an anti-pattern.
Let’s all agree you want to avoid going down this path. Instead, let’s approach templates like we would when designing a modern application. We’ll create small, focused templates and then connect them to build our entire solution.
The analogy I like to use when thinking about template strategy is a restaurant menu. A typical restaurant menu contains many options. You pick and choose items based on any number of criteria. So let’s build our CloudFormation templates like they’re menu options in your favourite local restaurant.
Here’s an example. You need to build an EC2-based, public-facing web application with a relational database in the backend. Here’s just one way you could break that into small components:
I know what you’re thinking - that’s a lot of templates for a relatively simple solution - and you’re right. However, you have to remember that by breaking your solution up as I did in my example, you end up with smaller, easier to maintain, more flexible templates that you can reuse across multiple projects, tying them together in different combinations.
There may be a bit more work up front, but you’re setting yourself up for more streamlined future deployments over the long term.
We have two strategies to tie these templates together - nested or chained stacks - but we’ll save that for another post.
Like what you read? Why not subscribe to the weekly Orbit newsletter and get content before everyone else?