Comment by catern | Hacker News Reader

Comment by catern | Hacker News Reader

Hmm, I was excited to see a former Midori developer working on a "cloud development platform". And I was even more excited to read:

>Using Pulumi, you author cloud programs using your favorite language, spanning low-level infrastructure-as-code to highly productive and modern container- and serverless-powered applications.

I'm enthusiastic about the prospect of using a real programming language to deploy and control a distributed system. It would be fantastic to have a library that gives me a nice, clean API for performing low-level distributed system tasks, manipulating and controlling hosts at the level of individual processes and sockets.

But I was disappointed to see that Pulumi doesn't seem to be designed to support deployment onto bare metal. In fact it seems to be just another layer of abstraction over various SaaS providers, or a huge dependency like Kubernetes. Why add another layer?

Today's systems are already heavily abstracted. For me, the value of using a really expressive programming language to implement a system, is that you can keep more of the abstraction in the language, and thereby avoid complexity in the underlying architecture.

To me, it is not very interesting to layer yet another library on top of the Kubernetes API. I'd be much more interested to see an attempt to replace the Kubernetes API with a library. This seems to be the former, and not oriented towards the latter, which is a bit of a disappointment.

> Pulumi doesn't seem to be designed to support deployment onto bare metal.

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.

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.

Reply on news.ycombinator.com