Terraform is terrible compared to Cloudformation. Its selling point is multi-cloud support, but you'll never get it, clouds are too different.
- Good CF template is 10x less code for the same solution.
- No corrupted state problems.
- Native tool, supporting all properties of resources
Writing good CF templates takes good AWS knowledge, and system thinking, you group resources that belong together, it actually teaches you good architecting.
I think Terraform's multi-cloud support is a bit better than Cloudformation's. Jokes aside, I don't think the multi-cloud part is really the biggest selling point, the biggest selling points, for me, are:
- Much better than Cloudformation at telling you what it's going to change before you apply the changes and the ability to record those changes. (much better than those dreaded 'conditional' changes)
- The ability to import changes if you found some that were done outside of Terraform. It's not perfect, or easy, but mostly doable.
- The ability to look at the code, the state file and the plan to get a good representation of what's actually deployed.
Those three are more significant than it looks, but together it makes sure you:
- Don't get into a situation where automation is broken and you can only recover by rebuilding the stack.
- Don't get unexpected downtime because a change replaces a resource unexpectedly.
- Being able to track, record and manage changes in easy to read diffs and plans.
The changesets feature of cloudformation allows users u to do most of what you mention here. Also take a look at resource deletion policies and Lambda custom resources.
Unless they fixed it though it didn't work well in certain situations, like with nested stacks, and often doesn't provide nearly the same level of detail as to what EXACTLY is changing and why.
Would you be willing to share a CF template that is 10x less then the equivelent terraform ? It has been my experience that terraform is much less verbose and much more reuseable via modules. Cloud Formation I have seen has always seems excessive and quite convoluted to do simple tasks.
Can’t get much less verbose than cloudformation yaml in combination with usage of only required parameters for a resource. For example, write a cloudformation yaml template that creates an automatically named S3 bucket.
Terraform gives a consistent _workflow_ across clouds, not a consistent codebase. I know personally of many teams using Terraform for significant multi-cloud deployments consisting of thousands of resources. Several switched from CloudFormation and saw their codebase size dramatically reduce.
Furthermore, the other comments on this post should disabuse you of the notion that there are "no corrupted state" problems with cloud formation: they happen all the time.
Disclosure: I worked on Terraform for quite some time at HashiCorp and am still a (community) maintainer of the AWS provider.
Food for thought, but I've never had CloudFormation break because a patch level upgrade changed a regular expression to 1) disallow previously legal inputs, and 2) disallow inputs AWS allows. I've also never had it forget a resource (probably due to race conditions when deleting failed resources).
CFN has its warts, but I full-stop don't trust HashiCorp's operations or their attempt at a SDLC and I wouldn't trust my business's health to them as a company (and if the results of using it weren't enough, their clownshoes sales team's bad attempts to upsell would cinch it).
Totally agree. I don’t care how much less verbose terraform may be (this claim is questionable IMHO). The most important part of infrastructure engineering is being able to debug and fix things quickly by isolating issues to the smallest possible domain. The additional layer of highly unstable terraform source code does not decrease the debugging surface area.
Serious question: how do you go about debugging a CloudFormation stack that's in a broken state, without involving AWS support?
I mean, it's weird, because I agree with your statement that "The most important part of infrastructure engineering is being able to debug and fix things quickly by isolating issues to the smallest possible domain." And that's why I so strongly prefer Terraform, because I actually have control over the state file, how Terraform interacts with it, and I can move things in and out, and change things in-situ if necessary.
Weird. I haven't compared byte sizes of CF templates and Terraform code, but just as far as readability, HCL works a lot better than YAML. YMMV.
As for state, I'm not sure what you did to corrupt your state, but we use Terraform to manage thousands of resources across dozens of AWS accounts for the past three years and haven't had any state corruption, except when a human messes up editing a state file by hand. Obviously in that case you back things up first (or hopefully you are using remote state with some kind of versioning). But the fact that you are _able_ to manipulate the state with the CLI tool, or by hand in extreme cases, is itself a huge advantage over CloudFormation, which has no such capability.
As for coverage, my experience has been that Terraform often has coverage of new resource types and properties _before_ CloudFormation. And it's extremely rare for any new features to take very long to show up in the AWS provider. Anything significant is usually picked up in 2-3 weeks from the API release at most.
I'm skeptical of your 10x less code claim. You can definitely get into broken state problems in CloudFormation - with no recourse but to blow it all away and start over. And despite being a native tool, CloudFormation support for new features and services in AWS is often spotty/missing.
That said, my experience has been that both CloudFormation and Terraform are irritating, just in different ways; they both are warty.
I do ultimately prefer Terraform - even in a single-cloud setup.
Some specific services (namely Data Pipeline) aren’t supported in Terraform. However, some parameters like Enhanced VPC routing in Redshift clusters is supported by Terraform but not CloudFormation.
The rule of thumb that you should generally stick to CloudFormation if you are full bore invested into AWS has some truth.
My issues with CloudFormation are lack of control over rollbacks, missing features for existing and mature services like the above, and forcing me to use custom resources to do anything that vaguely resembles coding that Terraform does just fine like IP address math functions.
Terraform is a much nicer way to deploy your CF templates than with the AWS CLI though. You can get the best of both worlds by deploying the templates with Terraform.
The AWS CLI for CF is simple and consistent with other AWS CLI's. You can also use one of the language specific SDK's such as boto3 or use AWS CodePipeline to create/update stacks.
- Good CF template is 10x less code for the same solution.
- No corrupted state problems.
- Native tool, supporting all properties of resources
Writing good CF templates takes good AWS knowledge, and system thinking, you group resources that belong together, it actually teaches you good architecting.