Hacker News Reader

Comment by Dunedan | Hacker News Reader

What I don't like about Terraform is that the state of your resources is stored locally, which might lead to consistency problems depending on your setup. With CloudFormation state is handled by CloudFormation itself, so you can be confident that stack updates operate on the latest state.

View on HN

I store terraform state in s3 with dynamodb locking. It looks like this:

    #backend/state uses less priv keys
    terraform {
      backend "s3" {
        bucket     = "mystatebucketisunique-tf"
        key        = "states/tf/tf.tfstate"
        region     = "us-east-1"
        lock_table = "lock-tf"
        profile    = "aws_tf_s3-prof"
      }
    }

So for an entirely new env I have to setup that bucket and the dynamodb table

That's only the default. Terraform supports storing state remotely, with locking. Most folks I know who use Terraform at scale recommend using this feature (if they store state at all).

Thanks for the information. Apparently my knowledge about state handling in Terraform did predate the introduction of remote state. I should've checked that first.

Then choosing where and how to store state using Terraform becomes another point of possible inconsistency in your infrastructure and thing to worry about. In CloudFormation, the state is coupled with the service, and you don't have to worry about it. It just works.

You can store the state remotely there are many options for state storage too. You can use s3 or dynamo db or even create your own web service that accepts web hooks from terraform.

Of course you can implement/set up syncing of state on your own, but that's something you don't have to worry about when using CloudFormation. I'm not sure how the options for Terraform handle race conditions when trying to deploy updates in parallel, but again, something you don't have to worry about with CloudFormation.

no, you and your team have to worry about not making a change that could render your whole stack useless

This "implementing/setting up syncing of state" requires only a few lines of Terraform config.

Lines of code is irrelevant when you are in the middle of a production deploy and you just want the highest visibility into what is going on. In cloudformation, there are only two possible places for resource state: 1) The actual resource state in AWS and 2) The desired state stored in CloudFormation.

"there are many options for state storage too"

Just, no.

Exactly. This is a HUGE point of interest that, in complex multi AWS account or multi region scenarios, can make or break your infrastructure.

additionally you can run it from a single management host (or Jenkins), for example, so the state is always up to date

Reply on news.ycombinator.com