State
I've been trying to learn more about AWS CloudFormation. One thing I've run into when diving in is having my expectations collide with similar tools I've used in the past. In this case it's the IaaC tool Terraform.
With Terraform, you can create a template and run terraform apply to create your cloud infrastructure. What if you want to make a change in that infrastructure? Just make your edits to the template, run terraform apply again, and you're off to the races. How does Terraform do this? State. Here's how the docs describe its purpose:
The primary purpose of Terraform state is to store bindings between objects in a remote system and resource instances declared in your configuration. When Terraform creates a remote object in response to a change of configuration, it will record the identity of that remote object against a particular resource instance, and then potentially update or delete that object in response to future configuration changes.
The beauty of Terraform is in how it handles state. I emphasize “handle” here, because a service like CloudFormation also handles state. It just does so in a different way. Coming from the world of Terraform, I thought it would be something akin to running the same command again. But CloudFormation requires a different approach. You need to declare the changes you are making in a separate API call. What's more, you can create change sets. Here's how AWS describes them:
When you need to update a stack, understanding how your changes will affect running resources before you implement them can help you update stacks with confidence. Change sets allow you to preview how proposed changes to a stack might impact your running resources, for example, whether your changes will delete or replace any critical resources, AWS CloudFormation makes the changes to your stack only when you decide to execute the change set, allowing you to decide whether to proceed with your proposed changes or explore other changes by creating another change set.
What's interesting here is that, again, we have a separation of duties in CloudFormation for something that Terraform tells you when you run the terraform apply command — it lets you know the resources you're going to change and asks if you're okay with those changes (of course you could run terraform plan to do this as a separated step but hey, living life on the edge).
At first I thought how CloudFormation handled state and updating stacks was a knock against it. But more and more I see it as a separate approach that has equal merit. Separating out the steps for updating cloud infrastructure is something I am not used to. Getting used to it can only help expand my experience.
Sometimes colliding with your expectations is a good thing.