5 ms·

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

by tbrock 6y ago

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?

devonkim 6y ago
Terraform doesn’t support rollbacks (handy for application roll-outs) and if your shop is heavily invested in AWS CF is a perfectly fine tool. I’ve maintained and started up tens of thousands of lines of both TF and CF and they both have their strengths and weaknesses.
- damagednoob 6y ago
  Aren't rollbacks handled by the VCS that you check your Terraform files into? Sorry I'm not familiar with Cloudformation but that's how I would approach it with Terraform.
  - takeda 6y ago
    CF can detect an issue while deploying, and then automatically go back to previous state (it is configurable, but that's the default behavior).
- tbrock 6y ago
  Sure it does? Revert your code and apply. It’s not atomic but I’m guessing neither is CF. I’m not sure I’d use either of these tools to roll out new code though.
  - devonkim 6y ago
    That’s more of a GitOps style intervention requiring a source change and the workflow to revert a change could certainly be done but is by design not a first class construct in Terraform providers (not every provider supports every feature such as importing of resources). To respond to a Cloudwatch (heck, Prometheus, Grafana, ELK, etc) alarm saying your error rate went up because of a Route53 change it’s not out of the box with Terraform (would be a custom providers or null resources probably). And as a CLI application (granted, it’s run more like an RPC style architecture) there’s no obvious way to signal different failure levels and to respond to different failure modes of different resources. 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.
- gchamonlive 6y ago
  are you not mixing infrastructure deployment and application deployment? terraform is not the tool for the later, an ansible stack would be better suited for it
  - devonkim 6y ago
    Once upon a time people would put applications delivered baked into AMIs as a deployment approach. Using a combination of CloudFormation metadata, Cloudwatch Alarms, cfn-init, and other tools applications could be deployed end to end with a single tool immutably. Many people are stuck with this rather coupled approach because trying to pull it apart would take more effort than is worth to the business. 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).
    - gchamonlive 6y ago
      indeed then terraform is probably not the right tool and cloudformation is a better suited solution
      - devonkim 6y ago
        It’s not an either/or situation for tools thankfully. The author of Terragrunt has even advocated before in a blogpost for using Terraform to deploy CloudFormation stacks to make changes to AutoScaling groups and perform blue-green deployment approaches.
nerdjon 6y ago
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.
  - 6y ago
takeda 6y ago
If you are on GCP or Azure you definitively want to use terraform, because alternative is either POS or doesn't exist. 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.

by tbrock 6y ago

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?

devonkim 6y ago

Terraform doesn’t support rollbacks (handy for application roll-outs) and if your shop is heavily invested in AWS CF is a perfectly fine tool. I’ve maintained and started up tens of thousands of lines of both TF and CF and they both have their strengths and weaknesses.

damagednoob 6y ago
Aren't rollbacks handled by the VCS that you check your Terraform files into? Sorry I'm not familiar with Cloudformation but that's how I would approach it with Terraform.
- takeda 6y ago
  CF can detect an issue while deploying, and then automatically go back to previous state (it is configurable, but that's the default behavior).
tbrock 6y ago
Sure it does? Revert your code and apply. It’s not atomic but I’m guessing neither is CF. I’m not sure I’d use either of these tools to roll out new code though.
- devonkim 6y ago
  That’s more of a GitOps style intervention requiring a source change and the workflow to revert a change could certainly be done but is by design not a first class construct in Terraform providers (not every provider supports every feature such as importing of resources). To respond to a Cloudwatch (heck, Prometheus, Grafana, ELK, etc) alarm saying your error rate went up because of a Route53 change it’s not out of the box with Terraform (would be a custom providers or null resources probably). And as a CLI application (granted, it’s run more like an RPC style architecture) there’s no obvious way to signal different failure levels and to respond to different failure modes of different resources. 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.
gchamonlive 6y ago
are you not mixing infrastructure deployment and application deployment? terraform is not the tool for the later, an ansible stack would be better suited for it
- devonkim 6y ago
  Once upon a time people would put applications delivered baked into AMIs as a deployment approach. Using a combination of CloudFormation metadata, Cloudwatch Alarms, cfn-init, and other tools applications could be deployed end to end with a single tool immutably. Many people are stuck with this rather coupled approach because trying to pull it apart would take more effort than is worth to the business. 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).
  - gchamonlive 6y ago
    indeed then terraform is probably not the right tool and cloudformation is a better suited solution
    - devonkim 6y ago
      It’s not an either/or situation for tools thankfully. The author of Terragrunt has even advocated before in a blogpost for using Terraform to deploy CloudFormation stacks to make changes to AutoScaling groups and perform blue-green deployment approaches.

nerdjon 6y ago

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.
- 6y ago

takeda 6y ago

If you are on GCP or Azure you definitively want to use terraform, because alternative is either POS or doesn't exist. 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.