Pulumi – A new open-source cloud development platform

You should be able to read the source of the script directly at https://get.pulumi.com/ or even download it yourself, inspect it and then decide if you want to run it or not. You can also follow the manual install instructions which are listed a little further down on our install page at https://pulumi.io/install/, if you want total control over where it is installed.

I also just opened a pull request to our docs website: https://github.com/pulumi/docs/pull/430 to explain in a little more detail what we're doing with the scripts.

In principle, there is no reason we couldn't support bare metal, provided we have an orchestrator. Pulumi bottoms out on raw CRUD operations that can do anything. It turns out that, when targeting existing cloud providers, that means invoking their APIs. As you say, this is just a layer of abstraction, but the key aspect at the center here is diffable immutable infrastructure.

I was, in fact, inspired to pursue Pulumi in part because of the experience of building a distributed OS that ran on bare metal. Many of the same challenges Pulumi solves around configuration, composition, and the application model, were inspired by this experience, and we've taken some of those lessons and applied them to cloud programs.

> you can keep more of the abstraction in the language, and thereby avoid complexity in the underlying architecture.

I look at other ways we've integrated with systems as inspiration here. For instance, we can productively code using tasks, and async await, these days, and reap the benefits of concurrency, despite there being massive differences between threading, I/O, and scheduling behavior across different systems. There was abstraction in the language, but it bottoms out on a set of primitives.

In a sense, I view the current APIs we're using as the syscall layer for a given cloud, Kubernetes included. (Also note, we don't require depending on Kubernetes.) That's not to say everybody will want to eschew the syscalls -- there's always a time and a place -- but we can be more productive by using the abstractions.

I believe that frameworks are languages, in that they give you a set of nouns and verbs you can use to express yourself. I do think there's opportunity for language-level innovation here, but if there's one thing I've taken away from our industry experiences building PaaS's, it's that it's a losing battle to bet against the incredible momentum of the public cloud vendors.

> I'd be much more interested to see an attempt to replace the Kubernetes API with a library.

We are just getting started, so expect to see a lot more progress in this direction in the weeks to come. The foundation of languages is a huge enabler for us, and we already have several projects in the works that I think will make you happier than this initial release.

YMMV, this is just my opinion, and I really love hearing the feedback. Thank you for sharing. This is a vibrant space and time and I'm enjoying the diversity of perspective.

An approach that goes back to relying on procedural programming languages as a primary means of configuration seems like it defeats the purpose.

I am working in this space, mainly focused on configurations: https://youtu.be/4yepPOznakk

The approach we've adopted is to maintain the declarative presentation while providing a way to plug in procedural language programmability without using templates or other similar concoctions (ksonnet..etc).