I just stick CloudFront in front of those buckets. You don't need to expose the bucket at all then and can point it at a canonical hostname in your DNS.
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
The syntax does look nicer but sadly that’s just a superficial improvement.
Also that have CDK which is a framework for writing IaC in Java/TypeScript, Go, Python, etc.
https://dev.to/kelvinskell/getting-started-with-aws-cdk-in-p...
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
> 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.
Incorrect, ARM does too, they even have a much nicer icon for one click "Deploy to Azure" <https://learn.microsoft.com/en-us/azure/azure-resource-manag...> and as a concrete example (or whole repo of them): <https://github.com/Azure/azure-quickstart-templates/tree/2db...>
> All IaC requires live cloud credentials. It would be impossible for them to work without live credentials ;)
Did you read the rest of the sentence? I said it's the worst of both worlds: I can't run "plan" without live creds, but then it doesn't use them to check jack shit. Also, to circle back to our CF and Bicep discussion, no, I don't need cloud creds to write code for those stacks - I need only creds to apply them
I don't need a state file for CF nor Bicep. Mysterious about that, huh?
That’s Azure, not AWS. My point was to have “one click” HTTP installs you need native integration with the cloud vendor. For Azure it’s the clusterfuck that is Bicep. For AWS it’s the clusterfuck that is CF
> I don't need a state file for CF nor Bicep.
CF does have a state file, it’s just hidden from view.
And bicep is shit precisely because it doesn’t track state. In fact the lack of a state file is the main complain against bicep and thus the biggest thing holding it back from wider adoption — despite being endorsed by Microsoft Azure.
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.
This isn’t a limitation of TF, it’s an intended consequence of cloud vendor lock in
Which is to say both of you are correct, but OP was highlighting the improper expectations of "if we write in TF, sure it sucks balls but we can then just pivot to $other_cloud" not realizing it's untrue and now you've used a rusty paintbrush as a screwdriver
But maybe I’ve just been blessed to work with people who aren’t complete idiots?
I'm not sure if that's changed recently, I've stopped using it.
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.
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.
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.
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.
It's so simple for storing and serving a static website.
Are there good and cheap alternatives?
BTW: Is GitHub Page still free for custom domains? (I don't know the EULA)
- signed url's in case you want a session base files download
- default public files, for e.g. a static site.
You can also map a domain (sub-domain) to Cloudfront with a CNAME record and serve the files via your own domain.
Cloudfront distributions are also CDN based. This way you serve files local to the users location, thus increasing the speed of your site.
For lower to mid range traffic, cloudfront with s3 is cheaper as the network cost of cloudfront is cheaper. But for large network traffic, cloudfront cost can balloon very fast. But in those scenarios S3 costs are prohibitive too!