Comment by hnlmorg | Hacker News Reader

Comment by hnlmorg | Hacker News Reader

Parent Full thread

I'm not the biggest fan of Terraform either but it would be naive to deny that Terraform doesn't still offer a lot of advantages over CloudFormation even if you're not writing cloud agnostic code (even though I do actually agree with your point that Terraform doesn't make your infra cloud agnostic).

Terraform offers far more constructs than CloudFormation and there is still a lot to be said for using the same language from describing your AWS infra as GCP, Github, any on prem infra, etc (even if the resources differ between providers requiring bespoke code for each). It's a bit like those who advocate node.js because it means the same developers can right frontend and backend code and in the same language.

If you like the tooling around CloudFormation in AWS then you're better off with serverless (`sls`) or even Amazon's own CDK (https://aws.amazon.com/cdk/) over YAML-based CloudFormation stacks in my opinion.

That's not to say I don't think Terraform doesn't have its warts: properties are non-guessable, IDE integration is pretty mediocre, and it's overly verbose in calling modules (so bad that sometimes the calling code has just as many lines as the module itself!) but I do still think it is the least worst tool available at the moment. And one can always use a 3rd party tools like Terragrunt if you want to fix some of the shortcomings of Terraform while still taking advantage of it's benefits (though personally I'm on the fence about whether the industry really needs yet another transpiler that compiles to code that needs to be transpiled....it's starting to feel like it's just abstractions all the way down....)

I agree with this. Terraform is definitely the least-bad tool, especially in that it integrates with so many more services than CloudFormation and has far fewer bizarre limitations than CloudFormation (e.g., you cannot pass objects in CF, and arrays can only be simulated as comma separated strings). Terraform isn’t great, but CF is awful, and even the AWS folks will point you at the CDK instead.

Agree CF is crap.

Each clouds SDK in the language the team is most familiar with is by far the best option.

State can be stored in git. Any version of my infrastructure is a git checkout away.

I use Go, and the documentation for the AWS SDK includes copy-paste examples

Try and checkout Terraform from 6 months ago and run it? Frequently I cannot even get someone’s tutorial example written a week prior to work without edits.

I checked out a year old commit in my infra repo; rebuilt an entire ECS stack deprecated 18 months ago.

Just be programmers. The cloud ops scene is just reselling the same delusions as Unix grey beards and Windows server admins. It’s about making hardware do the right thing, not hand wavy semantics.

Most of the people I work with just regurgitate memes. Very few actually test them for truth.

I disagree with using the SDK directly because the SDK doesn’t have any reconciling capability, and that’s not something easily built correctly.

Creating resources with the SDK is easy—keeping them in the desired state is very hard.

Instead, we use a real language to generate a description of what we want (in YAML or HCL) and a reconciliation engine takes over from there.

Terraform Language server together with VSCode is working quite well.

That's what I use and it is better than nothing but nowhere near as finely tuned as other language servers:

1. It's slow to return results

2. sometimes the only way you can generate a list of available properties is to type the first character, which is really annoying if you don't even know what the first character might be

3. it offers suggestions for properties that aren't even valid for that resource

4. there is no description against any of the properties so you're still left guessing (or having the docs open in another window) anyway

Reply on news.ycombinator.com