4 ms·

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 a

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.

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.