Because each service runs in its own isolate, it can be built and deployed independently of the others. So if some other team's code is broken at HEAD, that doesn't stop your team from deploying. Also you don't have to agree with other teams about exactly what versions of dependencies you use, you can monkey-patch APIs without braking anyone else, etc. So, all the usual development workflow benefits of microservices, without the network overhead.
LD_PRELOAD is calling. There are advantages and disadvantages to this approach: shipping one single binary means that you don't have to worry about testing compatibility between versions of your microservices/libraries. We went through this with dynamic/static linking a long time ago. Static linking seems to have generally won.
We are curious about this set of solutions for allowing clients to run their own code on our system.
For example, a client wants to write a workflow but has a custom step that integrates with their system only. They can write the code and run as part of our workflow without us worrying about them writing something nefarious and breaking out of the sandbox.
That said, the workerd github says that this can't (yet?) be relied on to be a security sandbox.
workerd ensures that a Worker cannot access protected resources by accident or negligent programming. What it can't protect against (on its own) is intentional exploitation of security bugs.
If your clients are people whom you've spoken to face-to-face and signed contracts with, then you can probably trust that they won't exploit a V8 zero-day to break the workerd sandbox, because if they did, it would clearly be a crime and you could prosecute them.
If your clients are random people who can sign up on the internet without talking to anybody, then they may be able to evade such identification and therefore prosecution. In that case you need a stronger sandbox to contain them.
It’s people we talk to and have contracts with but the devs they might have working on it, lesser known quantity.
But still isn’t the Wild West.
It would likely be more of a “this person wrote crappy code that’s bringing down everyone else’s worker” or “this client wants to know if we have proper guards on their data”
An isolate is a runtime thing, not a deployment thing.
A regular javascript module can be deployed independently. And have its own version of dependencies. I'm just not seeing what this really adds over existing widely available, well understood options.
I guess protection from other teams uncontrolled monkey-patching is something (I don't think there's probably any legitimate reason to monkey patch something yourself in normal production -- why wouldn't you patch or replace the problematic thing?), but there might be other ways to deal with that short of a new runtime environment.
I'm a little worried truly independent updating... imagine starting a request with one version of the auth module but finishing it with another. Not sure people really want to have to account for that. (Maybe that's accounted for, so maybe an unwarranted worry.)
