Building Durable Microservices with WebAssembly by John A. De Goes @ Wasm I/O 2024

Wasm I/O 2024 / 14-15 March, Barcelona
In this talk we’ll look at how we have used WASM to create durable microservices that pick up right where they left off after hardware failures or redeployments. We’ll also talk about how we have been building an ecosystem around this to let these services talk to each other, all powered by WASM.
-
WebAssembly (“WASM”) is still in its early stages and one of its challenges is how to go from a compelling technology to a compelling solution for businesses outside the existing WASM ecosystem.
At my company we have been working to provide at least one solution to this in the form of Golem. Golem allows you to deploy WASM based microservices that not only automatically scale up but are also durable, meaning that if the server they are running on fails or is redeployed the application will automatically be restarted on another server and resume execution in a way that is seamless to the outside world.
Taking advantage of some of the features of WASM, including its sandboxed execution environment, we are able to provide this guarantee regardless of what language the user writes their code in. In this talk we’ll be diving into some of the details of how we do this, including using our own implementations of WASI to track all interactions a program has with the outside world in an “operations log” and smart snapshotting to address some of the common problems that can arise in durable computing.
We’ll also look at how much more is needed for users to be able to deploy their applications with WASM and how we’re working to contribute to an open source ecosystem that makes it easy to communicate with WASM based workers, let them talk to each other, and monitor them, among other things.

[@Holobrine]

This is why having a good error model is really important

[@hopeunome]

Guys, a nitpick - the intro music is just too loud in all the videos, for the purpose it serves (viz. nothing). Thanks for uploading them.

[@meyou118]

you mean BEAM + Erlang?

[@joseluisvazquez5126]

Too much magic going on here. I wonder how does recovery actually works, specially for time sensitive workloads or random internal inputs: - Your WASM program dies, so it needs to be resurrected on another node. - How many events need to be replayed on the cloned WASM program to get to the state the program was when it crashed? - How long does it all take? - What happens if the program was running for days, months or years before crashing? won't you have a long down time until it resumes somewhere else? - What if the running state of the crashed program involved calculations using time or random data (auto generated keys) as sources and those did not interact with the host, but were only internal to the WASM program memory? is the WASM running memory being replicated or snapshoted? that seems expensive BTW. Very interesting how that could be done thought. I do not think the app running on Golem can be completely oblivious to the constraints the platform imposes: apps that might reply differently to the same inputs depending on randomly generated data or the wall clock will not be reproducible, so they should be negated those somehow, or they should asume reality does not really exist for them... If the platform is going to intercept random source generator interactions or private key generation to replay and fake it later, that is a security issue, for instance. You cannot fully isolate apps from reality. And in reality, shit happens. Another thing, you are NOT deleting databases, you are just hidding them from app developers. Databases will be used to store the events that will have to be replayed as needed. Same goes for Kubernetes or network serialization, that will still exist in a way or another on the Golem platform level. or below It might be a good simplification and might reduce duplication and increase overall productivity, but someone will still have to write and maintain databases, schedulers and network serializations.