> I am curious because everytime I considered using it so far, the prospect of just any dev who might well not know all the intricacies of infra should maybe no

> I am curious because everytime I considered using it so far, the prospect of just any dev who might well not know all the intricacies of infra should maybe not build it. I guess some barrier to entry is something I would see as a benefit. First, your dev process should go through a review phase robust enough that beginners should be able to develop on things they are unfamiliar with confidence. Second, the infra being 'intricate', needing huge tooling etc, is a sign that it has become too complex; maybe because it is not well aligned with the application side, maybe because the 'devops' have been making an infra monolith, or maybe because it is making use of too low level features. For example we're on GCP, and we're making use of serverless tech such as cloud run, functions, cloud sql, pubsub, IAM, etc. Those are all high level building blocks that are very easy to configure & deploy using pulumi. Since the devs can for example add a cloud function for a feature & go to prod entirely on their own with just one language, they make use of it, so we get better architecture as a result. In a sense the cloud platform itself becomes the full stack framework. The cloud platform provided blocks also enforce good practice so it's harder for newcomers to shoot themselves in the foot. If we were using native k8s, self managed postgres etc, then it would probably not work as well. But yes, pulumi is less mature & we're hitting some bugs here & there, and we're completely locked into a cloud provider. But the upsides are impressive & IMHO worth it. I used to be a proponent of monoliths for dev speed, but now I've seen that you can match the prototyping speed with microservice/serverless & get a much better solution as a result.