4 ms·

IIUC, this is using Elixir for the orchestration layer, but that layer is spawning processes in other programming languages, communicating with those processes

IIUC, this is using Elixir for the orchestration layer, but that layer is spawning processes in other programming languages, communicating with those processes over gRPC, passing state into short-lived requests in those processes, and then getting new state back in the responses. Please correct me if I'm wrong. IMO, that approach is irreparably inefficient, because state has to be passed back and forth, rather than being stored locally over the length of a longer operation. Yes, one has to checkpoint state to be able to recover from various events, but on the happy path, it should be kept in memory, in the same process as the code that's using it. I think something like Sandstorm's grains or Cloudflare's Durable Objects (used in conjunction with Cloudflare Workers) is a much better design. Of these two, Sandstorm grains were particularly interesting to me, because a grain could run arbitrary Linux programs. I hope that when Cloudflare finally reveals its edge containers product [1], it looks a lot like Sandstorm grains. [1]: https://blog.cloudflare.com/containers-on-the-edge/ https://blog.cloudflare.com/containers-on-the-edge/

weatherlight 4y ago
> it should be kept in memory, in the same process as the code that's using it how do you do that in a polyglot Environment? Also note, that Erlang processes are not the same as OS processes and are much lighter.
- derefr 4y ago
  > how do you do that in a polyglot Environment? Cloudflare Workers does it by using a WebAssembly runtime (https://developers.cloudflare.com/workers/platform/languages/ https://developers.cloudflare.com/workers/platform/languages...). You compile your C/Go/Rust/whatever code to WASM, and the embedded WASM runtime executes them at "almost native" speed. Whichever runtime they use (probably WAVM?), it has support for "isolates" in the V8 sense (https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_isolate.html https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_is...), which work effectively as sandboxes without requiring host:guest process isolation. The strong guarantee of isolation for WebAssembly in particular (stronger than that of isolates for Node.js code) comes from the WASM runtime's use of bytecode with no "escape hatch" to native code (no loading of native modules); and the WASM abstract machine's isolated memory model. Technically, though, I don't think this gets Cloudflare much in latency terms over doing efficient concurrent binary IPC over local Unix sockets, ala the Erlang "C node" model (https://www.erlang.org/doc/tutorial/overview.html#c-nodes https://www.erlang.org/doc/tutorial/overview.html#c-nodes). Due to the aforementioned isolated memory model, even a process-embedded WASM isolate will still require a memcpy(2) to exchange data into and out of the isolate. Unless Cloudflare have hacked up something custom, there's no way to do zero-copy SHM messaging with a WASM program.

weatherlight 4y ago

> it should be kept in memory, in the same process as the code that's using it how do you do that in a polyglot Environment? Also note, that Erlang processes are not the same as OS processes and are much lighter.

derefr 4y ago
> how do you do that in a polyglot Environment? Cloudflare Workers does it by using a WebAssembly runtime (https://developers.cloudflare.com/workers/platform/languages/ https://developers.cloudflare.com/workers/platform/languages...). You compile your C/Go/Rust/whatever code to WASM, and the embedded WASM runtime executes them at "almost native" speed. Whichever runtime they use (probably WAVM?), it has support for "isolates" in the V8 sense (https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_isolate.html https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_is...), which work effectively as sandboxes without requiring host:guest process isolation. The strong guarantee of isolation for WebAssembly in particular (stronger than that of isolates for Node.js code) comes from the WASM runtime's use of bytecode with no "escape hatch" to native code (no loading of native modules); and the WASM abstract machine's isolated memory model. Technically, though, I don't think this gets Cloudflare much in latency terms over doing efficient concurrent binary IPC over local Unix sockets, ala the Erlang "C node" model (https://www.erlang.org/doc/tutorial/overview.html#c-nodes https://www.erlang.org/doc/tutorial/overview.html#c-nodes). Due to the aforementioned isolated memory model, even a process-embedded WASM isolate will still require a memcpy(2) to exchange data into and out of the isolate. Unless Cloudflare have hacked up something custom, there's no way to do zero-copy SHM messaging with a WASM program.