Pulumi – A new open-source cloud development platform

> congrats on the launch.

Thanks -- we're very excited to be out and talking to the community!

> What is difference in the use case for Pulumi compared to scripting infrastructure using vendor provided libraries

The major difference is that Pulumi does immutable infrastructure. The code describes a goal state and our system manages your environment to ensure that it matches the goal state. This means you can preview changes before making them, and that, if you do make them, you've got a full audit trail of who changed what and when. Rollbacks are trivial because you just point us at an old goal state worked and we can chew on it until your live environment matches. We can even detect drift, so if someone manually updates in the cloud console, we can tell you about it. As a result, we always have a full object graph of your cloud resources, and can tie it back to the source code which created it, opening up some unique diagnostics capabilities.

The difference with scripting libraries, like AWS's Boto, or the Azure PowerShell SDK, is that they mutate cloud resources directly, and in an ad-hoc manner. So, you don't know what they are going to do before you run them. And in the event of failure, you're more likely to be in a corrupt state and unable to recover. Rollbacks are difficult. There's also no audit trail beyond the cloud access logs, and information like dependencies are lost, so resources end up disassociated from the code and workflow that created or updated them. Many people encounter these problems and need to build complex systems on top to address them. Or they end up using a solution like CloudFormation or Azure Resource Manager, which eschews code in favor of JSON/YAML/templates.

The hope here is that we've landed on a sweet spot between immutable infrastructure and fully programmable languages.

I can't speak for the GP with certainty, but maybe the source of the disappointment is that with Midori, you built a new OS from the ground up, throwing out all the accumulated cruft and doing it all in an elegant, unified way. On the other hand, Pulumi is just another layer on top of a cloud stack (or stacks) that many people see as too complex already.

I see the wisdom in it, though. Most developers these days aren't shipping their own servers off to a data center. And for those that want bare metal, there are providers that offer bare metal servers provisioned through a CRUD API, so Pulumi should be able to work with those.

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.)

All I know is the fonts on HN now look weak and puny compared to the the fonts used in the blog.

I don't mean this as a joke, I am seriously having issues looking at HN fonts after reading the blog. Even my emacs fonts are broken to me now.

How can a site just steal my ignorant bliss away and ruin my entire system with something as simple as fonts!

Joe mentions working with "existing language package managers". That probably doesn't include nixpkgs, but perhaps it could.