3 ms·

I use CloudFormation currently, and it gets the job done just fine. It has some nice things that terraform just doesn't have out of the box: - Its a managed s

I use CloudFormation currently, and it gets the job done just fine. 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.

ReidZB 6y ago
Stack Sets are a killer feature, and so much easier than trying to do the same thing in Terraform. 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.
- nerdjon 6y ago
  Oh yeah, drift detection is very limited. However being able to run it periodically and trigger an alarm from a central service (going back to my first point) without needing access to the repo is a major plus. 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.

ReidZB 6y ago

Stack Sets are a killer feature, and so much easier than trying to do the same thing in Terraform. 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.

nerdjon 6y ago
Oh yeah, drift detection is very limited. However being able to run it periodically and trigger an alarm from a central service (going back to my first point) without needing access to the repo is a major plus. 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.