"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

"Don't be snarky."

https://news.ycombinator.com/newsguidelines.html

Particularly please don't do this in Show HN threads. We don't want a putdown culture on HN, especially when people are sharing their work.

https://news.ycombinator.com/showhn.html

Not really - we are an _optional_ abstraction layer for infra-as-code. Terraform isn't really abstracting away infrastructure, it's a one-to-one mapping of every resource. A bit like assembly langugage.

We are a compiler of higher-level concepts into Terraform, with an option to just go and write Terraform if you need smth very custom.

Every high level programming language fits the same description. So that in itself is not inherently bad.

My problem with this product is selling you the idea that you can evade the responsibility of properly managing your AWS account.

Its a very understandable viewpoint. We believe that you not only can - you should. It may sound a bit utopian today, but look at what these managed cloud services really are: the new hardware. You had to manage every piece of hardware yourself in a mainframe system, because how else? Until you didn't have to. It's just so wasteful to require people do all this semi-manual work. It doesn't make any sense frankly. It has very little to do with the actual products people are building. Sooner or later in such arrangements higher-level concepts emerge and establish themselves. Just like web frameworks most recently, or hardware abstractions (drivers) in operating systems much earlier.

I think you can pay someone to provision infrastructure, then document very well what everything does and hand it over to a human... But completely hand it over to a third party service does not seem convincing to me.

Even if true, that's a normal progression. Consider something like a FaaS platform built on Kubernetes built on containers built on Linux.. it's turtles all the way down with everything now.

The normal, healthy version of this is building on things that are decent at what they do, but would be easier to work with for common use cases with another layer of abstraction.

Doing it primarily because multiple layers suck when used for their intended purpose may very well be useful, but it's not a sign of health.

This is like having three layers of assembly that are all horrible to write and are built one on top of the other, all operating at roughly the same "level" of the hardware/software stack, and then coming along and writing C for the third one, which will in turn generate the second, and that, the first, which will, finally, actually generate something a processor understands.

Whatever demand there is for this isn't this product or company's fault, but it's definitely a sign that something's not right. Config primitives being driven by orchestration scripts being driven by orchestration scripts being driven by orchestration scripts.

The product may be entirely fine, but the situation is ridiculous.

Exactly!