Hey all, quick question on the new GCP database Al...
# getting-started
m
Hey all, quick question on the new GCP database Alloy DB just launched at GCP IO 2022. Are we able to deploy and manage Alloy instances yet through Pulumi?
c
Not yet. I was looking at that very service myself. But you should be able to use it through the google-native provider as soon as the upstream Google Cloud OpenAPI spec has been updated. There is a nightly SDK generation in that repo and last night's automated PR doesn't seem to have it yet. The native package gets speedy, regular releases. If you are using the classic GCP provider that's bridged with the upstream TF GCP provider, then it depends on the upstream provider getting the new resource added first.
m
@clever-sunset-76585 Hey thanks for the reply. So key take aways is that GCP classic provider gets its updates from the Terraform upstream provider which gets updates nightly. So we're waiting on the Terraform provider to get its updates and then will roll down to Pulumi automatically as soon as that happens?
c
Yeah, assuming someone on the TF GCP provider team is working on that or a community contribution is made.
Note that you can mix and match providers in a single project. So you could technically start using it once the Google Native provider is updated in your existing project. I can't think of a huge downside to doing that, other than it being awkward to maintain perhaps?
m
Hey @clever-sunset-76585 I am pretty new to all this and also the duel provider (native and classic) what do you use mostly? I am currently using classic should I be switching?
c
@microscopic-flower-5848 I use GCP native where possible due to the fact that it is more "closer" to the cloud provider's API surface but my use cases have been small and non-critical. If you are already using GCP classic (aka TF-bridged provider), I would continue using that unless you have a very good reason to switch to the native provider. It is likely not a non-zero effort to switch, so I'd advice you to see if it is really worth making the switch. You might be better off using that resource from the native provider in the same project. Also note that the GCP native provider is in public preview and that means it can have breaking changes before reaching 1.x. So you should consider that and what your mitigation would be should there be breaking changes in some resource https://www.pulumi.com/registry/packages/google-native/ To get a sense of how one could use the classic and native providers side-by-side, have a look at the Azure Native migration guide. The Azure Native provider is more stable at this point and is in fact the recommended one over the classic https://www.pulumi.com/registry/packages/azure-native/from-classic/
m
Ok nice, so native the evolution of classic as in Pulumi moving away from TF bridges and integrating directly with the provider?
We are just starting out, so can switch to Native if that's the future, don't mind about the instability at the moment. Would like to position properly now rather than having to migrate later.
c
Yes, the native providers for the big 3 (Azure, AWS and Google) are intended to move away from the TF bridged providers. The native ones offer better API surface area. There are other longtail providers that are less likely to have a native provider version, though, still not out of the question.
m
@clever-sunset-76585 thanks so much for the info