kentonv

My biased take as the architect of Workers: It's a classic Clay Christensen innovator's dilemma.

V8 isolates seem "worse" on their face (e.g. mostly incompatible with non-JS apps, more difficult to secure), while aiming down-market. The hyperscalers' biggest existing customers aren't asking for them; they are asking for more and better micro VMs to run their existing codebases. It's only the little guys looking to deploy greenfield apps with low ops overhead and on a tight budget that really appreciate the Workers model, and to AWS these seem like small potatoes. Meanwhile there's a huge amount of investment needed to build out this entirely new and different way of doing things (we've been working on it almost a decade now!). In the worst case, this investment is wasted, and in the best case, cannibalizes the existing product line.

There likely many people at AWS who recognize the dilemma, but still cannot push the organization in the right direction. Too much inertia, too many stakeholders who don't get it, because it's unintuitive. When orgs get big they just cannot take disruptive steps, even when they were built on disruption in the past. They only finally come around after the new disruptor is eating their lunch, but by then it's too late.

Hmm.

So, obviously it was a blog post about business strategy and not technical architecture. Maybe that's disappointing when people expect me to talk tech.

But I sort of thought the direct argument for open source and against lock-in as a business strategy would please the technical audience.

My role hasn't changed. I have always been simultaneously writing code, designing technical architecture, and also influencing product/business strategy. This particular piece of strategy is one I advocated and won support for, which is why I wrote the post.

Why would you expect that, when Deno Deploy was not open source?

(But I admittedly have not actually asked Ryan if he had long-term plans to add a multi-tenant scheduler so maybe I'm wrong.)

What makes it cringy?

I am again not sure what you are getting at.

My best guess is that you are suggesting that we should open source our multi-tenant hosting technology, along with workerd.

But this doesn't make sense. No popular JavaScript runtime includes multi-tenant hosting technology. Multi-tenant hosting is the responsibility of the hosting provider. workerd is compatible with other providers' multi-tenant hosting approaches. You do not need our specific technology in order to run Workers apps on other hosting providers, and in fact would not even be particularly useful for that purpose.

I'm not really sure what you mean here.

My best guess is you're talking about sandboxing, specifically how we defend ourselves against malicious tenants. Indeed, a lot of how we defend against that is not in workerd, and fundamentally can't be, because it's more than just some code, it's a process requiring active management.

However, you only need that if you have untrusted tenants.

If you are using workerd to self-host your own applications on non-Cloudflare infrastructure, then this isn't a concern for you. You don't have untrusted tenants.

If you are hosting untrusted tenants, then you can put workerd in a micro VM, the same as you'd do with any other popular runtime.

For what it's worth, workerd has some pretty aggressive sandboxing too. I'm a bit biased but ask your favorite LLM about it.

> You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).

Details remain to be worked out, but part of the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure.

In fact, celld has already done a lot of this.

> Ok, this peaked my curiosity. Would be great if you could share it!

You'll have to find me in person over drinks somehow. ;)

workerd is open source, you can run it on your own servers.

We don't completely know what it will look like yet either, but it will absolutely be open source -- as workerd and celld are both already.

I think it's well-known that we've been pretty focused on AI agent infrastructure for a while...