> Each web framework squarely fits somewhere on that line. React, the most popular front-end web framework out there, is wholly client-side.
Might need to check again! :)
Rethinking Virtualization for Backends
21–30 of 37 posts
Re: Rethinking Virtualization for Backends
#22The "why not containers" is quite thin here, considering the incumbent position would be just to run your WASM things in containers: > The heavier your containers are, the more difficult everything else becomes. They take longer to build, they need more resources to run, they are more expensive to store, etc. > At shuttle we're convinced that a lot of the pains experienced by software engineers in the post-Docker wor…
because a web backend has a particular pattern of deployment that you can exploit and bake into your system that changes less often than the meat of your web app itself. You could either build out that pattern using container orchestration or using programs running inside container orchestration that in turn orchestrate the more lightweight wasm binaries. I think what you would find is the later to be faster, respons…
For the more fixed configuration viewed as an alternative to using K8s... I think most people using containers don't need or want K8s, and most people using K8s wouldn't see this as replacing it. And besides this the service configurations would seem orthogonal to the runtime.
As far as faster, responsible and stable - WASM currently is slower and less stable, and the container world has good options to provide improvements sandboxing/isolation (like gvisor, firecracker, etc).
Re: Rethinking Virtualization for Backends
#23This 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
I'm still waiting to see the service worker api for a backend server.
Re: Rethinking Virtualization for Backends
#24I don't know if this is _the_ answer, but it’s worth trying to find _an_ answer.
Re: Rethinking Virtualization for Backends
#25This 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
Yeah that's the thing with all modern stuff.
"you know how good software performs really well?"
"yeah"
"let's make our thing not like that, and use JavaScript."
"great idea."
Re: Rethinking Virtualization for Backends
#26Long term, I would love to see more software ported to/rewritten for Wasm, and I think greenfield projects should seriously consider it. But the reality is that containers and VMs work well enough that I think it's going to be a long, long time before the huge backlog of working software we have today gets pushed aside.
wasm is bad for efficiency though. if you're running stuff at even moderate scale on a server you should compile to machine code.
Re: Rethinking Virtualization for Backends
#27I think people on twitter, and some here as well, forget that Docker adds layers to restore functionality that was lost because of deliberate decisions from OS manufacturers.
Windows, Linux, Mac, BeOS, Solaris, whatever else; they have different binary formats solely because they didn't want to allow binaries written for other systems to run. (there's more to it than this, but not much more) Docker just brings back what was taken away by abstracting those decisions out of the execution path and uses Linux instead. The stuff that was taken away? were those things taken away for a good reason? Not at all. incompatibility solely for incompatibilities' sake.
Why can't we just revisit that decision to introduce incompatibility on top of identical hardware? I feel like that is the correct way forward, rather than WASI. WASI will just replace Docker as a runtime for these things, and it will incur a performance penalty well beyond what Docker itself experiences, because it lives on top of the OS rather than using virtualization or isolation to go around the OS, in a manner of speaking.
Everyone these days seems to want necessarily worse performance at every opportunity. It is amazing what even a single core on my laptop can do in one second, but it takes a handful of seconds to launch any graphical application on my computer... apparently things are still too fast for the people stewarding this stuff.
Re: Rethinking Virtualization for Backends
#28> 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 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.
Re: Rethinking Virtualization for Backends
#29This 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?
Re: Rethinking Virtualization for Backends
#30Long term, I would love to see more software ported to/rewritten for Wasm, and I think greenfield projects should seriously consider it. But the reality is that containers and VMs work well enough that I think it's going to be a long, long time before the huge backlog of working software we have today gets pushed aside.
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 machine then deploy a working/signed artifact directly to ARM servers.