[autotune]

Every client has different requirements so it varies. CloudFormation is common but strongly prefer Terraform when possible for creating infrastructure, and use Ansible or chef-solo for config management, pre-baked AMI method and deploying to ASG Launch Config for deployment. Use Python and Lambda for scripting out things like backups and common security tasks or anything else that may need to be scripted out.

[guitarbill]

I generally love Hashicorp's tools, but never really got using Terraform over CloudFormation.

I found the cloud-agnostic claim to be a bit of an exaggeration, plus most clients are happy to stick to one provider. Sure, CloudFormation is a bit slow, and the JSON is awful, but with YAML it's okay. And I don't need yet another tool. What am I missing?

[dmlittle]

I'm not too familiar with using straight up CloudFormation JSON definitions. Are you able to create reusable modules in CloudFormation?

In Terraform you're able to create modules that you can use to setup uniform infrastructure. For example, you could have an RDS module that aside from setting up the database it also sets up a replica, a dedicated KMS encryption key, IAM policies, security groups, parameter groups, etc. So instead of setting all of this up for every database you have, you can just reuse a custom module that does all of this for you. These modules can also be versioned such that you can upgrade and change them as needed without breaking all your current infrastructure.

[guitarbill]

Arguably you can create a stack that does this and exports the DB identifier to be used in other stacks. It doesn't sound as convenient though, and child stacks have some annoying limitations.

[laurentl]

> Are you able to create reusable modules in CloudFormation?

Not out of the box but Cloudformation templates (jinja2) + Ansible works really well.

[jeffnappi]

For most cases CloudFormation is great. And if you're wondering why you'd want to use Terraform you probably don't need it :)

If you do choose to learn and implement Terraform however, you gain the knowledge of a tool that can support many cloud providers and can even manage environments that span multiple providers. e.g. CloudFlare + AWS, etc. In addition, you can package up your solutions as modules and share them with others.

I chose Terraform because I have services running on multiple clouds and I also prefer to use tools that have value outside of a single ecosystem.

[autotune]

CloudFormation, last I checked, doesn't support actually showing what your changes are going to be in full with nested stacks, which means you are changing things blindly with Change Sets. Imagine having 100's of security groups, you change 3 of them, but someone else changed one of them earlier and now you have no idea what's being modified. That's my primary beef with CF in addition to planning for the future possibility of being HA across cloud providers in the future, and code readability.