I may be wrong, but from what I can tell this is really a souped-up framework for working with clouds. Most of it looks like primitive for immutable infrastructure, so Terraform but as a library. As far as can tell, there's no deployment system, no orchestration etc. -- a "Pulumi app" doesn't know how to deploy itself. Is that accurate?
So if, for example, you're running an app on GKE, then you can tell the Kubernetes API about the resources you want, but there's no system for building your app (Docker build + push to GCR), no way to do supervised rolling updates, and so on. If you're doing CI/CD, then presumably you have to build, push, then let the Pulumi code inject the right image and tag.
I like the idea of declaring the infrastructure with extensible code (as opposed to a DSL like Terraform where you're completely dependent on upstream support for all the objects you want to manage), but I'm a bit skeptical about crossing the bridge from ops to applications.
Typically applications aren't self-contained enough that they can, or should, declare all their resources. So presumably then you have to centralize common stuff (e.g. your central Postgres server) in a shared module that all your apps import. Now you get into versioning hell as your app depends on an old version of the "common" module and "pulumi update" tears down your Postgres 10 install and creates a 9.6 install instead. (Presumably it asks first. But still. Versioning has got to be a challenge here.)
So if, for example, you're running an app on GKE, then you can tell the Kubernetes API about the resources you want, but there's no system for building your app (Docker build + push to GCR), no way to do supervised rolling updates, and so on. If you're doing CI/CD, then presumably you have to build, push, then let the Pulumi code inject the right image and tag.
I like the idea of declaring the infrastructure with extensible code (as opposed to a DSL like Terraform where you're completely dependent on upstream support for all the objects you want to manage), but I'm a bit skeptical about crossing the bridge from ops to applications.
Typically applications aren't self-contained enough that they can, or should, declare all their resources. So presumably then you have to centralize common stuff (e.g. your central Postgres server) in a shared module that all your apps import. Now you get into versioning hell as your app depends on an old version of the "common" module and "pulumi update" tears down your Postgres 10 install and creates a 9.6 install instead. (Presumably it asks first. But still. Versioning has got to be a challenge here.)