[jcusch]

That's essentially the idea with nitric, you ask for cloud resources in an abstracted request. How that request is fulfilled is determined by the provider used. What "read" access in nitric means can be up to the platform engineers.

[oneplane]

To me, nitric seems to be a combination of TFCDK and the multi-provider abstraction (which limits you to the common denominator cloud resources -- generally not a good idea), which already exists, in multiple programming languages too. Even nitric itself already exists in the shape of pulumi.

[jcusch]

Common denominator implies you're restricted to some subset of the cloud's features. I'm curious what restriction you see, since nothing about nitric limits combining nitric code with existing cloud libraries or extending providers to change the cloud interactions behind the abstractions.

[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.