Cloudflare as workers to run serverless code without using containers:
They run the code in what they call Isolates:
Isolates are lightweight contexts that group variables with the code allowed to mutate them. Most importantly, a single process can run hundreds or thousands of Isolates, seamlessly switching between them. They make it possible to run untrusted code from many different customers within a single operating system process. They’re designed to start very quickly (several had to start in your web browser just for you to load this web page), and to not allow one Isolate to access the memory of another.
We pay the overhead of a Javascript runtime once, and then are able to run essentially limitless scripts with almost no individual overhead. Any given Isolate can start around a hundred times faster than I can get a Node process to start on my machine. Even more importantly, they consume an order of magnitude less memory than that process.
So I am not an expert on the Beam, but I want to ask to the experts what are the conceptual similarities and differences between the Beam and Isolates?
I know they may be considered for sure different different beasts, but curious if they have some overlaps, and where they diverge conceptually in that same overlaps?
So this is very close to a BEAM process, although there’s no “mutation” exactly
This sounds like how the BEAM schedulers (there’s usually one or two per CPU) handle running many processes.
This is where they diverge some - it’s technically true that BEAM processes can’t “access each other’s memory” (in the sense that they can’t change things) but any process can send messages (including ones like :sys.get_state) to any other process.
In its current state, process isolation in the BEAM is very weak and most definitely not intended to keep code with different levels of trust or from different sources from interfering with one another.
Some ideas have been tossed around in the past, perhaps most famously the SafeErlang paper ('97). More recently I saw this proposal, which seems interesting.
The problem with any such proposal is that it’s going to require support from the Erlang/OTP core team, because they’re going to have to commit to maintaining the functionality in the BEAM going forward. Whether they are willing to do so depends in a large part on whether they have an internal (or paying customer) use-case for the proposed feature. For comparison, see the recent discussion on support for HiPE…
This is it. Once code is running on the BEAM there is nothing stopping it from interacting with (or killing) any other proces on the VM, so it’s not safe for multi-tennant workloads like this. Isolates are all about restricting running code in order to make them safe to run together.
The only thing I am seeing in this idea is that somebody doesn’t seem to get the message that Javascript is not the future.
“Stop trying to make JS happen. It’s not going to happen.”, as one meme goes.
The JS runtime is awful. As much as you try to fine-tune it it will inevitably spill its guts at the first sign of trouble. People spent weeks hand-crafting a Phoenix-like case for 1-2 million connections on a single server and it was a back-breaking work.
