[truetuna]

Terraform is great but there are certain things that I still use Cloudformation for (simply because you can't do it right now using Terraform). One example is rolling updates on your ASGs. Last time I checked you can't do it via the aws_autoscaling_group resource.

[webo]

For this we have been creating the CloudFormation in Terraform itself. CF is a giant mess to work with.

[devonkim]

A lot of people including myself have used tools to generate CF or Heat templates in the absence of a need for cross-cloud compatibility that Terraform offers. You can use Troposphere, Stacker, or anything else that can intelligently generate and manage component information as a JSON or Yaml file and get much of the power of Terraform - perhaps more given the option of a full language rather than an external, declarative DSL. I still haven't found an idiomatic, elegant API that can manage all those template references.

The primary advantage Cloudformation has for myself is a lack of need to manage the state that Terraform spends so much effort upon. In fact, Cloudformation does this fairly opaquely but was much more obvious when I tried to deploy a CF stack when S3 was down a while ago - being able to use an alternate state file location would have been handy then.

[akurilin]

In fact our very own jdreaver wrote a Haskell EDSL for generating CloudFormation templates, this seems to be not uncommon among companies who want to do infrastructure as code with that ecosystem: https://github.com/frontrowed/stratosphere

[truetuna]

Yeah, agreed.

Unfortunately when you inevitably make changes to your CF config, `terraform plan` doesn't help because it's likely you changed something inside the `template_body` and Terraform just knows the string has changed and doesn't tell you what part of the config changed. Parameterising as much as you can helps.