Feel free to raise a request on our github for this though, I don't think we've got anything publicly tracking this.

For simple microservices that are basically event-based and maybe have an API Gateway, YAML seems like a much better approach for operations.

On the other side of the coin, we have projects that absolutely need a general purpose progamming language because of the complexity.

This is how awsx works.

With the exception of autotagging and VPC resolution, and an RDS wrapper. Otherwise, we've been duplicating the long-form level 1 resources to promote more autonomy while staying aligned.

An example of a huge pain in the ass for this pattern was the MAJOR aws provider upgrade that changed how the provider reads configuration, essentially breaking portability between v4 and v5. It was a tedious and carefully planned upgrade that needs to happen same day across all the projects. You don't want to end up with a mix of v4 and v5 aws providers. We had to worry about upgrading

pulumi-components

,

pulumi-policy-packs

, then our microservices and finally

shared-infrastructure

. Then you have to deal with the breakage and conflict between shared dependencies. If your components package also uses awsx, you're probably going to have a bad time if your versions mismatch between the consumer and the library.

Doesn't matter for us so much any more because we use SSO in an interesting way that lends itself to us being able to drop our shell wrapper script.

This is like a welcome mat though... literally the pulumi command is broken for users that setup their AWS IAM in a secure way. I get that it's really an issue with the underlying Terraform provider, but that's not a great excuse. Onboarding for devs was not a good look, I think it could have impacted sentiment, "Copy this shell script to make the IaC program with a funny name work"