Hmmmm ... So, Terraform redux with a JavaScript facade?<p>The associated blog post[1] makes a case for infra-structure as code and not much of a case for this particular intermediary. On the other hand, given that it seems to me most uses of Terraform are wrong, a more opinionated approach might be beneficial.<p>The difficulty with, say, giving an app an S3 bucket is not in whether you run `new cloud.Bucket()` or something else ... The difficulty is in correctly configuring it for the current use case while enabling adaptation to future use cases. This is the kind of thing not solvable at the language level (people creating the thing need to understand the implications of the decisions and how to update implementations as conditions change). After that, they can write organization or project specific object storage implementations and only create buckets through that implementation. If the requirements fit with the object storage facility of all cloud providers, one can even make this all cloud-agnostic so that the consumer of the object storage creation facility need not worry about cloud specific details.<p>But, none of the things that matter are known to a language designer.<p>I use and advocate for Terraform not because it is great, but because it gives me a decent solver and acceptable uniformity in declarative syntax.<p>[1]: <a href="https://medium.com/@hackingonstuff/cloud-why-so-difficult-%EF%B8%8F-4e9ef1446a64" rel="nofollow">https://medium.com/@hackingonstuff/cloud-why-so-difficult-%E...</a>