Hi, I'm a total beginner. Pulumi sounds awesome! I love that I can use my favorite language (Go). I looked through https://www.pulumi.com/registry/ and it seems like something is missing. I want a package that abstracts the provider. So the Pulumi developer doesn't need to know anything about the concrete provider. AWS, Azure, and GCP (etc.) are all different, but there are many cloud resources from cloud each provider that are similar enough to be interchangeable. For example if I want to provision a new object store (e.g. AWS Simple Storage Service, Azure Blob Storage, GCP Cloud Storage) First, my code looks like:

pulumi.Run(func(ctx *pulumi.Context) error {
        // Create an object store resource
        bucket, err := abstractProvider.NewObjectStore(ctx, "my-object-store", nil)
        if err != nil {
            return err
        }
})

Then, there is a separate layer which determines which provider to use or to use multiple providers for multi-cloud redundancy. (Example selection criteria: price, data center geography, real time service outages) Does such a thing exist? Essentially, why should a Pulumi developer need to hard code the provider into the IaC? Also, looking at https://www.pulumi.com/blog/tag/native-providers/ it seems there has been no blog posts about native providers since the original blog post on Apr 20, 2021. Is this a sign that the native providers are not being prioritized?

Does such a thing exist?

Not really, we did start working on something like this (https://www.pulumi.com/docs/tutorials/cloudfx/) but there wasn't really much user value to it. It kinda forced targeting lowest common denominator which often wasn't enough for users.

Essentially, why should a Pulumi developer need to hard code the provider into the IaC?

As above, but this is also the same for I think all other IaC tools on the market. Having said that at least it's possible with pulumi to write an abstraction like cloudfx if this did turn out to have value to someone.

Is this a sign that the native providers are not being prioritized?

Not at all! Our current set of native providers continue to be worked on as a top tier providers, and we're working on improving the foundations of writing providers to make it easier for the community to start writing native-providers as well.

I’m addition to this one of the big challenges comes not just with the development of a universal Pulumi implementation that would cross multiple providers but the lack of universal standard of how Cloud providers create their APIs I think it goes without saying that all competing cloud providers know we will live a multi cloud World. But the very design of their cloud networks alone leads to a lot of differences in design and implementation that can’t easily be universalised in a single Pulumi “wrapper” (for want of a better word). Take for example Networking. Cloud networking is software defined and in Azure a VNet is regional. In GCP a VPC is Global but subnets are regional. In addition IAM would be come increasingly complex and as would resource grouping as Azure uses the concept of Resource Groups and GCP uses Projects. Building a universal process around these conflicting constructs would be very difficult and to find the point of interoperable I expect would result in a reduction in the API coverage for Pulumi. (Which is the opposite direction of Native API providers in Pulumi)