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

11–20 of 37 posts

Re: Rethinking Virtualization for Backends

#11

Post by spkk »

pbiggar wrote: post #5

This is really cool. In a sense, this is also the approach we took with Darklang. We are running the runtime layer (http servers, DB drivers, OS runtime, etc) so all that needs to be deployed is the core of your app, as opposed to your app plus your language runtime plus your OS etc etc. I'm curious what shuttle does once your app is deployed? Is a container cloned with the app injected, then connected to a load bala…

Oh, that's really interesting!

We've got containers running for each instance of the runtime a user needs. And for now we just keep them running forever as long as the project is up. But that's very inefficient, and we're definitely looking for a better way to do it.

Re: Rethinking Virtualization for Backends

#13

Post by [deleted] »

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,…

[deleted]

Re: Rethinking Virtualization for Backends

#14

Post by tokinonagare »

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 containers. There's a lot of buzzwords (WASM, Rust, Cloud, etc.) but at the end of the day nothing that isn't easy to do with a modern "boring" stack like .NET.

Re: Rethinking Virtualization for Backends

#15

Post by anderspitman »

Long 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.

Re: Rethinking Virtualization for Backends

#16

Post by fulafel »

The "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 world can be traced back to that very simple statement: containers are often too heavy for the job.

Why not use small lightweight containers? You can just have a layer with the WASM runtime.

Re: Rethinking Virtualization for Backends

#17

Post by Dowwie »

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,…

You don't support actix-web applications? There was a closed attempt at integrating it as a feature in the Summer and nothing since then.

Re: Rethinking Virtualization for Backends

#19

Post by Dowwie »

anderspitman wrote: post #15

Long 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.

It won't be pushed aside. It just won't be adopted for the next project someone works on. When this is done by enough people, great changes can happen quickly

Re: Rethinking Virtualization for Backends

#20

Post by enos_feedler »

fulafel wrote: post #16

The "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, responsible and stable. It is basically a trade off between writing that logic at say the k8s operator / custom resource layer, or placing that logic inside containers running on k8s that each run wasm binaries.
Post reply on HN