Comment by politelemon | Hacker News Reader

Comment by politelemon | Hacker News Reader

Read this bit again, it feels very bizarre to me and is like they're misunderstanding how server side development and containers work...?

> The whole isolation model that keeps WebAssembly from being able to attack the hosts through the browser was the same kind of [security] model we wanted on the cloud side,” Butcher explained.

I then went to the fermyon.com website, and their first line says

> WebAssembly-powered cloud tools

And later in the page leads to the WASM 'component model' at https://github.com/WebAssembly/component-model/blob/main/des... which actually mentions that!

> Embeddability: design components to be embedded in a diverse set of host execution environments, including browsers, servers, intermediaries, small devices and data-intensive systems.

So now I'm extra confused. WASM lets you run compiled languages like C# in the browser. You can already run that on the server side. You can run it in a container. What problem is WASM solving here? Unfortunately the language is hard to follow so even if they have answered it, it's not very accessible.

> What problem is WASM solving here?

My understanding is that it's mostly solving sandboxing for multitenant cloud operators. I don't know how right they are, but if they are it's a big deal, because virtualizing and isolating users from one another is very costly today (containerization is not strong enough for isolation – you need vms or something like gvisor). A large portion of that cost comes from overprovisioning, since vms don't scale up and down quickly or cheaply. If wasm holds up to its ambitious aspirations, it could act as a packaging format, a sandbox across users and it could even run in kernel mode (let's pretend spectre and I guess side-channel attacks in general doesn't exist for a moment).

For the customer, it's a compile target, which is a promising direction and means in theory that you can mix and match languages at a granular level, but in practice of course this has countless unknowns (did I hear anyone ask about ABIs?). It's more nimble than containers – you no longer need to think or care about the OS and all it's gritty details. At the same time it's also unclear where exactly the runtime boundary lies. File descriptors? A full https stack? And so on. I've come to believe that this boundary is extremely important, and difficult, to get right.

So yeah, dreamy and utopian, never failed us before right? If you put on rose tinted glasses it could have implications ranging much further than just cloud. I, for one, am crossing my fingers (and yes, I know how naive I sound).

The article is so obfuscated it's hard to know what they're actually selling. My guess is that it's something similar to Cloudflare Workers + WebAssembly (https://blog.cloudflare.com/webassembly-on-cloudflare-worker...), meaning a serverless function. In Cloudflare's case, the main worker itself works in JS, but can import WASM modules.

In Fermyon's case, you can compile directly to WASM, skip the JS layer, and the framework will set you up with HTTP endpoints to handle requests. Why WASM? It's faster, and lets you transpile from other common backend languages so you don't have to write JS, I guess.

So like they containerize WASM for you into serverless functions that you don't have to micromanage yourself. Send it some data-intensive task and get back some data. Like a remote procedure call, almost?

Or at least that is my GUESS. No idea if any of that's right... the article and website aren't clear at all.

> You can already run that on the server side. You can run it in a container. What problem is WASM solving here?

As I understand it, they let you run your code on their servers. Their proprietary WASM solution is used for isolation of different processes instead of containers, virtualization & stuff.

Isn't it open source?

Reply on news.ycombinator.com