[oneplane]

You are indeed restricted to some subset, which is the only reason multi-cloud abstractions exist to begin with. The problem isn't punching through the abstractions, it's the pointlessness of the abstractions as a whole. Generic public cloud abstractions don't really work because the value is in the specificity. If you don't need that, don't use the public clouds since those are really expensive and impractical versions of resources for generic consumption.

If your project or BU is too small to make use of the specifics of a cloud, just don't use them. And if you are big enough to do so, you're also big enough to not be helped by some application specific IaC flavour of the day.

[jcusch]

The reason for the abstractions is that the behavior of equivalent services from different clouds is functionally the same, but offered through subtly different APIs. If you think the value of each cloud is how unique their object storage (S3, Cloud Storage, etc.) is, you’ve missed the point entirely - the value is being able to store and retrieve data. The same is true for all the services nitric abstracts.

Saying they’re expensive and impractical because they’re not unique is obviously wrong. They’re valuable because they’re easy to use, safe, scalable, etc. while requiring almost no maintenance from the user. Storing data or sending messages, etc. aren’t uniquely valuable components worth spending time on for most applications. They’re basic building blocks, so why not minimize the effort and time to use them as much as possible?

There are unique and valuable services offered by cloud providers, those aren’t what nitric is focused on. I’d rather spend my time dealing with those unique, valuable tasks instead of wasting it on the basics.