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.
This is why having a good error model is really important
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.
you mean BEAM + Erlang?
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.