[hnlmorg]

That’s definitely the “correct” way of doing things if you’re writing infra professionally. But I do also get that more casual users might prefer not to incur the additional costs nor complexity of having CloudFront in front. Though at that point, one could reasonably ask if S3 is the right choice for causal users.

[gchamonlive]

S3 + cloudfront is also incredibly popular so you can just find recipes for automating that in any technology you want, Terraform, ansible, plain bash scripts, Cloudformation (god forbid)

[gigatexal]

Yeah holy crap why is cloud formation so terrible?

[gchamonlive]

It's designed to be a declarative DSL, but then you have to do all sorts of filters and maps in any group of resources and suddenly you are programming in yaml with both hands tied behind your back

[gigatexal]

Yeah it’s just terrible. If Amazon knew what was good they’d just replace it with almost anything else. Heck just got all in on terraform and call it a day.

[mdaniel]

This may be heresy in an AWS thread, but as a concept Bicep actually isn't terrible: https://github.com/Azure/bicep/blob/v0.37.4/src/Bicep.Cli.E2...

It does compile down to Azure Resource Manager's json DSL, so in that way close to Troposphere I guess, only both sides are official and not just some rando project that happens to emit yaml/json

The implementation, of course, is ... very Azure, so I don't mean to praise using it, merely that it's a better idea than rawdogging json

[hnlmorg]

I’ve heard so many bad things about bicep on Azure that I’m not convinced it’s an upgrade over TF.

The syntax does look nicer but sadly that’s just a superficial improvement.

[hnlmorg]

They do contribute to the AWS provider for Terraform.

Also that have CDK which is a framework for writing IaC in Java/TypeScript, Go, Python, etc.

[gigatexal]

Meh. The CDK doesn’t look terrible. It’s still not ideal. But even if this compiles to a mess of CF it’s still better than writing CF by hand and that’s only because CF is so bad to begin with.

https://dev.to/kelvinskell/getting-started-with-aws-cdk-in-p...

[mdaniel]

As for "go all in on terraform," I pray to all that is holy every night that terraform rots in the hell that spawned it. And that's not even getting into the rug pull parts, I mean the very idea of

1. I need a goddamn CLI to run it (versus giving someone a URL they can load in their tenant and have running resources afterward)

1. the goddamn CLI mandates live cloud credentials, but then stright-up never uses them to check a goddamn thing it intends to do to my cloud control plane

You may say "running 'plan' does" and I can offer 50+ examples clearly demonstrating that it does not catch the most facepalm of bugs

1. related to that, having a state file that believes it knows what exists in the world is just ludicrous and pain made manifest

1. a tool that thinks nuking things is an appropriate fix ... whew. Although I guess in our new LLM world, saying such things makes me the old person who should get onboard the "nothing matters" train

and the language is a dumpster, imho

[hnlmorg]

There's a lot wrong with Terraform but I don't think you're being at all fair with your specific critisims here:

> 1. I need a goddamn CLI to run it (versus giving someone a URL they can load in their tenant and have running resources afterward)

CloudFormation is the only IaC that supports "running as a URL" and that's only because it's an AWS native solution. And CloudFormation is a hell of a lot more painful to write and slower to iterate on. So you're not any better off for using CF.

What usually happens with TF is you'd build a deploy pipeline. Thus you can test via the CLI then deploy via CI/CD. So you're not limited to just the CLI. But personally, I don't see the CLI as a limitation.

> the goddamn CLI mandates live cloud credentials, but then stright-up never uses them to check a goddamn thing it intends to do to my cloud control plane

All IaC requires live cloud credentials. It would be impossible for them to work without live credentials ;)

Terraform does do a lot of checking. I do agree there is a lot that the plan misses though. That's definitely frustrating. But it's a side effect of cloud vendors having arbitrary conditions that are hard to define and forever changing. You run into the same problem with any tool you'd use to provision. Heck, even manually deploying stuff from the web console sometimes takes a couple of tweaks to get right.

> 1. related to that, having a state file that believes it knows what exists in the world is just ludicrous and pain made manifest

This is a very strange complaint. Having a state file is the bare minimum any IaC NEEDS for it to be considered a viable option. If you don't like IaC tracking state then you're really little better off than managing resources manually.

> a tool that thinks nuking things is an appropriate fix ... whew.

This is grossly unfair. Terraform only destroys resources when:

1. you remove those resources from the source. Which is sensible because you're telling Terraform you no longer want those resources

2. when you make a change that AWS doesn't support doing on live resources. Thus the limitation isn't Terraform, it is AWS

In either scenario, the destroy is explicit in the plan and expected behaviour.

[gchamonlive]

All Terraform does is build a DAG, compare it with the current state file and pass the changes down to the provider so it can translate to the correct sequence of interactions with the upstream API. Most of your criticism boils down to limitations of the cloud provider API and/or Terraform provider quality. It won't check for naming collision for instance, it assumes you know what you are doing.

Regarding HCL, I respect their decision to keep the language minimal, and for all it's worth you can go very, very far with the language expressions and using modules to abstract some logic, but I think it's a fair criticism for the language not to support custom functions and higher level abstractions.

[SvenL]

Amen, and I would add to that list “no, just because you use terraform doesn’t mean you can simply switch between cloud providers”.

[stogot]

Isn’t that what CDK was for?

[SteveNuts]

Last time I tried to use CF, the third party IAC tools were faster to release new features than the functionality of CF itself. (Like Terraform would support some S3 bucket feature when creating a bucket, but CF did not).

I'm not sure if that's changed recently, I've stopped using it.

[tkjef]

I have been on the terraform side for 7 years-ish.

eksctl just really impressed me with its eks management, specifically managed node groups & cluster add-ons, over terraform.

that uses cloudformation under the hood. so i gave it a try, and it’s awesome. combine with github actions and you have your IAC automation.

nice web interface for others to check stacks status, events for debugging and associated resources that were created.

oh, ever destroy some legacy complex (or not that complex) aws shit in terraform? it’s not going to be smooth. site to site connections, network interfaces, subnets, peering connections, associated resources… oh, my.

so far cloudformation has been good at destroying, but i haven’t tested that with massive legacy infra yet.

but i am happily converted tf>cf.

and will happily use both alongside each other as needed.

[dragonwriter]

Because its an old early IaC language, but it works and lots depends on it, so instead of dumping or retooling it, AWS keeps it around as a compilation target, while pushing other solutions (years ago, the SAM transform on top of it, more recently CDK) as the main thing for people to actually use directly.

[baby_souffle]

> Yeah holy crap why is cloud formation so terrible?

I can't confirm it, but I suspect that it was always meant to be a sales tool.

Every AWS announcement blog has a "just copy this JSON blob, and paste it $here to get your own copy of the toy demo we used to demonstrate in this announcement blog" vibe to it.

[damieng]

I'd argue putting CloudFront on top of S3 is less complex than getting the permissions and static sharing setup right on S3 itself.

[hnlmorg]

I do get where you're coming from, but I don't agree. With the CF+S3 combo you now need to choose which sharing mode to work with S3 (there are several different ways you can link CF to S3). Then you have the wider configuration of CF to manage too. And that's before you account for any caching issues you might run into when debugging your site.

If you know what you're doing, as it sounds like you and I do, then all of this is very easy to get set up (but then aren't most things easy when you already know how? hehe). However we are talking about people who aren't comfortable with vanilla S3, so throwing another service into the mix isn't going to make things easier for them.

[crinkly]

It's actually incredibly cheap. I think our software distribution costs, in the account I run, are around $2.00 a month. That's pushing out several thousand MSI packages a day.

[hnlmorg]

S3 is actually quite expensive compared to the competition for both storage costs and egress costs. At a previous start-up, we had terrabytes of data on S3 and it was our second largest cost (after GPUs) and by some margin.

For small scale stuff, S3s storage and egress charges are unlikely to be impactful. But it doesn’t mean they’re cheap relative to the competition.

There are also ways you can reduce S3 costs, but then you're trading the costs received from AWS with the costs of hiring competent DevOps. Either way, you pay.

[oblio]

With CloudFront?

[tayo42]

>S3 is the right choice for causal users.

It's so simple for storing and serving a static website.

Are there good and cheap alternatives?

[MaKey]

Yeah, your classic web hoster. Just today I uploaded a static website to one via FTP.

[fodkodrasz]

Really? If I remember correctly: My Static website served from S3 + CF + R53 by about 0.67$ / mo, 0.5 being R53 from that, 0.16 being CF, S3 being 0.01 for my page.

BTW: Is GitHub Page still free for custom domains? (I don't know the EULA)

[daydream]

GitHub Pages are still free but commercial websites are forbidden.