Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking Virtualization for Backends

shuttle.rs

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Rethinking Virtualization for Backends

#31

Post by Serow225 »

tokinonagare wrote: post #14
jeremyjh wrote: post #8

> Whereas all your service logic, database and endpoint code build into lightweight WASM modules that are dynamically loaded in-place by this global persistent process This sounds like J2EE application servers for WASM instead of Java byte code.

It's exactly what it is, except there is also a browser implementation without plugin. Which also means that WASM/WASI is not a total replacement for containers: just like there as JVM image there will be WASI images. The argument of size given in the article isn't very convincing, when images like Alpine exist. The problem addressed in the post is more about getting around Rust slow build time than phasing out conta…

The model they describe is pretty much exactly how .NET Azure Functions works. (which is however currently switching to a slightly different hosting model)

but that wouldn't bring in VC money lol

Re: Rethinking Virtualization for Backends

#32

Post by msoad »

omginternets wrote: post #29
msoad wrote: post #18

This is the same line of thinking as Deno. Turns out the browser sandbox model is a solid foundation to build systems in which processes share resources in a secure way

Embarrassing question: what exactly is "the browser sandbox model"? What I mean is, what are the first principles behind it? What makes it different from other sandbox models?

These two come to mind for me:

* Using URL origins

* Not allowing any sort of host access

Re: Rethinking Virtualization for Backends

#33

Post by infogulch »

dohguy wrote: post #2

Hey HN, since our pivot earlier this year we have been working with the alpha users of our product shuttle (YC S20) on creating the best backend development experience possible. Interacting with hundreds of developers, we have become convinced that the time has come to rethink the virtualization layer that we are all so used to - containers . Don’t get us wrong, containers have improved development in a lot of ways,…

What do you think of WAGI [1], which is basically CGI for WASM modules.

[1]: https://github.com/deislabs/wagi/blob/main/docs/writing_modu...

Re: Rethinking Virtualization for Backends

#34

Post by jeremyjh »

anderspitman wrote: post #28
tokinonagare wrote: post #14

Earlier quoted context omitted.

It's exactly what it is, except there is also a browser implementation without plugin. Which also means that WASM/WASI is not a total replacement for containers: just like there as JVM image there will be WASI images. The argument of size given in the article isn't very convincing, when images like Alpine exist. The problem addressed in the post is more about getting around Rust slow build time than phasing out conta…

> The argument of size given in the article isn't very convincing, when images like Alpine exist For a lot of uses you can go even smaller than Alpine. Static executables for example don't require standard Linux tools to operate. I expect WASI would be similar. Just drop the runtime and your Wasm files into a scratch container.

Busybox or other distribution tools are there for debugging purposes.

Re: Rethinking Virtualization for Backends

#35

Post by tokinonagare »

anderspitman wrote: post #28
tokinonagare wrote: post #14

Earlier quoted context omitted.

It's exactly what it is, except there is also a browser implementation without plugin. Which also means that WASM/WASI is not a total replacement for containers: just like there as JVM image there will be WASI images. The argument of size given in the article isn't very convincing, when images like Alpine exist. The problem addressed in the post is more about getting around Rust slow build time than phasing out conta…

> The argument of size given in the article isn't very convincing, when images like Alpine exist For a lot of uses you can go even smaller than Alpine. Static executables for example don't require standard Linux tools to operate. I expect WASI would be similar. Just drop the runtime and your Wasm files into a scratch container.

True. A static executable doesn't even need Linux in the first place, that can be done with a unikernel. It's a tradeoff about familiarity, size, performance, documentation and technical level.

Re: Rethinking Virtualization for Backends

#36

Post by moralestapia »

anderspitman wrote: post #30
the8472 wrote: post #26

Earlier quoted context omitted.

wasm is bad for efficiency though. if you're running stuff at even moderate scale on a server you should compile to machine code.

Is it projected what the eventual performance loss will be long term? Honestly if it's at least 80% of native and lets me use the same binaries across all architectures and in the browser, I'd probably consider it worth it. You're probably right when it comes to scale though. Portability is more important for apps than services. That said, it would be cool to be able to develop a Rust service locally on my x86 machin…

>a Rust service locally on my x86 machine then deploy a working/signed artifact directly to ARM servers

That's the kind of thing you can do with Rust -> WASM -> WASI (or something like that).

Re: Rethinking Virtualization for Backends

#37

Post by the8472 »

anderspitman wrote: post #30
the8472 wrote: post #26

Earlier quoted context omitted.

wasm is bad for efficiency though. if you're running stuff at even moderate scale on a server you should compile to machine code.

Is it projected what the eventual performance loss will be long term? Honestly if it's at least 80% of native and lets me use the same binaries across all architectures and in the browser, I'd probably consider it worth it. You're probably right when it comes to scale though. Portability is more important for apps than services. That said, it would be cool to be able to develop a Rust service locally on my x86 machin…

Rust can cross-compile. I.e. you can build on an x86-machine and target aarch64.

> Is it projected what the eventual performance loss will be long term?

I don't know, but my understanding is that wasm ir is optimized for fast JIT compilation and not ideal for AOT workloads.

And compiling on demand on a target machine isn't great either because that means you're burning CPU cycles on compilation. Of course that can be worked around by turning wasm into machine code and distributing that to target machines. But then it's better to compile straight to machine code.

Post reply on HN