11 ms·

The only thing that spending time with Cloudformation teaches me is how much it makes me prefer doing things with Terraform. I think Cloudformation is consider

• Dunedan 8y ago
  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.
  • artellectual 8y ago
    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.
    • Dunedan 8y ago
      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.
      • dcu 8y ago
        no, you and your team have to worry about not making a change that could render your whole stack useless
      • nawitus 8y ago
        This "implementing/setting up syncing of state" requires only a few lines of Terraform config.
        • deboflo 8y ago
          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.
    • deboflo 8y ago
      "there are many options for state storage too" Just, no.
  • cmonfeat 8y ago
    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).
    • Dunedan 8y ago
      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.
    • deboflo 8y ago
      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.
  • dcu 8y ago
    additionally you can run it from a single management host (or Jenkins), for example, so the state is always up to date
  • liveoneggs 8y ago
    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
  • deboflo 8y ago
    Exactly. This is a HUGE point of interest that, in complex multi AWS account or multi region scenarios, can make or break your infrastructure.
• geggam 8y ago
  Amen
• auslander 8y ago
  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.
  • jen20 8y ago
    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.
    • eropple 8y ago
      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).
      • deboflo 8y ago
        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.
• laumars 8y ago
  I want to love Terraform but it's such a horrible platform to code on: * Error messages are overly verbose yet cryptic, and sometimes even unrelated to the actual error raised by the cloud provider themselves. Coupled with the lack of line numbering or other helpful identifier aside the unnecessarily long module hierarchy and debugging those scripts is a massive exercise in frustration and usually far more time wasted than really should ever be necessary. * HCL is a hateful "language". The fact you cannot order stuff procedurally means you're constantly running into dependency issues on larger deployments. And dont even get me started on the "count" kludge to work around a lack of proper iteration. * There is a lack of internal consistency with the support of different methods. Eg "count" does t always work with all resource types. Some resources cannot have properties defined with variables. * Using calling modules requires so much bootstrapping code. It's just painful. I get Terraform is the best we have for multi-provider deployments but their idea to create a superset of JSON only to then compile that back down to JSON anyway was such a poor decision in my personal opinion. I get the point was to have something that was accessable to non-programmers while still expressive enough for developers to use; however instead what they've created is a monstrous language that is too complex for the former group and too irrational for the latter. I've been been very tempted to write my own Terraform alternative based on my experiences using it (and CloudFormation) - I even already have another programming language that Ive written a parser for and would be well suited for this type of application. But my time is pretty limited at the moment so I struggle on Terraform.
  • ReidZB 8y ago
    Funny thing is, HCL isn't actually a superset of JSON. For example, { "foo": { "bar": 1 } } can't be represented in HCL. (Even Consul had to add a kludgy hack to support HCL config as a result.) Instead, they call HCL "JSON-compatible", which I think means JSON can be written to represent any equivalent HCL structure (HCL is a subset, essentially). That said, you might be interested in Terraform 0.12 [0], which will be using some new HCL v2 that actually has first-class expressions and dynamic blocks (for loops). And, finally, a ternary operator that short-circuits. Unfortunately, the dynamic block stuff looks like it's based around for-loops and doesn't support just regular if-statements... but we'll see where that goes. [0] https://www.hashicorp.com/blog/terraform-0-1-2-preview https://www.hashicorp.com/blog/terraform-0-1-2-preview