Rethinking Virtualization for Backends
shuttle.rs
Rethinking Virtualization for Backends
1–10 of 37 posts
Re: Rethinking Virtualization for Backends
#2Hey 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, but over time they have also created a lot of problems too.
For the way most people use them in deployments of web apps, containers are too heavy. 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. This has significant repercussions for the developers that have to deal with containers, IOW most backend developers.
Our view is that by restricting the scope of virtualization to something more specific to web app backends, we can build a tool that is much better for the job than containers. With WASM and WASI becoming stable, this is more possible than ever.
We’re very excited to share our ideas with you and would love to get your thoughts on this!
Re: Rethinking Virtualization for Backends
#3Super exciting news -- shuttle has been a really nice breath of fresh air after dealing with containers and such. I write a lot of rust-based backends and it was a pain that even for a simple service like fly.io I still had to manually write docker files... shuttle made that a LOT easier. Love to see them moving forward!
Re: Rethinking Virtualization for Backends
#4Super exciting news -- shuttle has been a really nice breath of fresh air after dealing with containers and such. I write a lot of rust-based backends and it was a pain that even for a simple service like fly.io I still had to manually write docker files... shuttle made that a LOT easier. Love to see them moving forward!
Same. Used shuttle for https://endler.dev/2022/zerocal/ lately and was super happy with the experience. I no longer have to worry about hosting and can focus on the product instead.
Re: Rethinking Virtualization for Backends
#5This 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 balancer and left running? In Darklang we just keep the AST in the DB and fetch it each request, but at some point we'll want to do better.
Re: Rethinking Virtualization for Backends
#6[deleted]
Re: Rethinking Virtualization for Backends
#7Congrats, this looks super cool!
In the example, is the .await in get_article run in a tokio executor inside wasm, or is did you write a way to poll the future across the wasm/host boundary? I'm curious if you could do something like tokio::spawn, or tokio::join from within the wasm code.
Re: Rethinking Virtualization for Backends
#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.
Re: Rethinking Virtualization for Backends
#9> 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.
Everything old is new again!
Re: Rethinking Virtualization for Backends
#10Congrats, this looks super cool! In the example, is the .await in get_article run in a tokio executor inside wasm, or is did you write a way to poll the future across the wasm/host boundary? I'm curious if you could do something like tokio::spawn, or tokio::join from within the wasm code.
Hey, Damien here, author of the article! Real happy you like it!
We initially thought about running tokio in wasm (they've added support for WASI recently as well IIRC), but elected against it because we found it just moved the compile time problem from one compilation target to another.
So in the end we decided to go with the second option. So when the guy in the example `.await`'s, context can go back to the runtime. But inside wasm this is not tokio, this is our own shim to the executor running on the outside.