I don’t think I’ve ever met someone that actually uses cloudformation unless a template was provided them to setup something like a lambda.
Why would you when terraform exists?
Why would you when terraform exists?
It has some nice things that terraform just doesn't have out of the box:
- Its a managed service, I don't need to setup a state bucket (or similar), I upload my template and it handles it. CI itself is not running CloudFormation, it just tells CF to do its thing. I could achieve this with other services with TF, but its not something I have seen out of the box.
- Drift Detection
- Stack Sets, the ability to deploy easily deploy a cloudformation stack to multiple AWS Accounts
- How sharing outputs works in CF between deployed stacks. There are protections in place if you have a stack that relies on a value your stack creates, you cannot modify or delete it without first changing your other stacks. I wish AWS could instead trigger a downstream change in any of those stacks, but it does not. (This is not for nested stacks, but for 2 completely separate stacks that just happen to need to share something)
However even without these, I struggle to see the point of going with Terraform if we are all in for AWS anyways. Especially when there are templates that we may want to use, so why not keep everything in the same place.
CloudFormation Drift Detection is very limited currently: it only supports a small subset of resources that you can create with CloudFormation. If your needs are covered by it, great, but it doesn't take much to go beyond its bounds. Also, it detects drift, but won't correct it.
Terraform both detects and corrects drift on almost every resource, on every application. Sometimes there are limitations. This does result in extra work, as you can't just ignore drift without capturing that in code (via ignore_changes), but to me this is absolutely a desirable thing.
We use CloudFormation to actually create the state resources to store Terraform state.
Terraform can share outputs between different states using the terraform_remote_state data source, though there isn't any restriction on what can be done there (no requirement to update other stacks/states).
Despite being an AWS-only shop, we've found the multi-provider support in Terraform to be really useful. For example, as part of our environment configuration, we store resources in Consul, create Pingdom checks, etc all from the same set of Terraform code.
With Terraform (unless there is functionality I am unaware of) you need the repo where the terraform is stored to be able to perform that check. Then you need to setup the system that does the periodic checks (yes I know a cron in CI is barely any work if thats your desire).
Ultimately like a lot of things, CloudFormation VS Terraform is a long list of tradeoffs. I just would not personally write off CloudFormation depending on I actually need.
TF actually doesn't have much edge over CF. When TF was released it fixed many pain points of CF, but since then CF fixed those problems.
The supposedly killer feature that you can use TF with multiple clouds is not that killer, since each cloud architecture is different so you can't just reuse your code.
With CF you have extra benefits:
- built in, no extra tool necessary
- integral part of AWS, so no need to worry about being discontinued
- available within AWS support
- no need to worry about synchronizing state between people
- import / export functionality, you can expose various variables, which following stacks can build on top of
- ability to implement custom states with lambda
- uses YAML or JSON, which means you can use existing tooling to generate config programmatically.
Haven't used yet, but it appears that CDK is built on top of that, and that's much more powerful than terraform.
Sorry I'm not familiar with Cloudformation but that's how I would approach it with Terraform.
I’m not sure I’d use either of these tools to roll out new code though.
CF roll-backs are on by default and will revert changes. Sometimes it can fail and be a real pain, but it’s overall been more of a help for myself than harm.
terraform is not the tool for the later, an ansible stack would be better suited for it
In a lot of situations infrastructure deployment and configuration management is deeply coupled in the AWS ecosystem (DB changes, Serverless technically is changing your infrastructure definition as application changes).
then terraform is probably not the right tool and cloudformation is a better suited solution