So, I like this idea, I really do. At the same time, in the short-term, WASM is relatively messy and, in my opinion, immature (as an ecosystem) for prime time. But with that out of the way (it will eventually come), you'll have to tell people that they can't use any code that relies on threads, so they better know if any of the libraries they use does it. How do you foresee navigating this? Runtime errors suck, especially in this context, as fixing them requires either live patching code or migrating execution logs to new code versions.
Yeah, looks like Golem went similar route - using WASM Component Model and wasmtime.
There is always this chicken and egg problem on a new platform, but I am hoping that LLMs can solve it partially - the activities are just HTTP clients with no complex logic.
Regarding the restrictions required for determinism, they only apply to workflows, not activities. Workflows should be describing just the business logic. All the complexities of retries, failure recovery, replay after server crash etc. are handled by the runtime. The WASM sandbox makes it impossible to introduce non-determinism - it would cause a compile error so no need for runtime checks.
I understand what you mean by being able to fully sandbox things and guarantee determinism, a must for the workflows and not the activities (using temporal lingo).
When you say that the runtime handles, for example, retries, doesn't that require me to depend on your HTTP client component? Or do I also need to compile activities to WASM and have obelisk running them because they are essentially background jobs (that is, you have workers pulling)?
Finally, do you see the component's interface as the right layer for capturing IO? I'm imagining people attempting to run managed code (Java, python, ruby, etc.). The VMs can do thousands of syscallls before they start executing they user's code. Logging them one by one seems crazy, but I also don't see an alternative.
EDIT:
I RTFM and found the answers to my first two questions in the README :)
Yes, currently all activities must conform to the WASI 0.2 standard. This is the simplest for deployment, as you only need the obelisk executable, toml config file. The webhooks, workflows and activities pulled from a OCI registry on startup.
To support native code I plan to add external activities as well, with an interface similar to what Netflix Conductor uses for its workers.
> Finally, do you see the component's interface as the right layer for capturing IO?
An activity must encapsulate something much higher level than a single IO operation. So something like "Configure BGP on a router", "Start a VM" etc. It needs to be able to handle retries and thus be idempotent.
Regarding performance, a workflow execution can call 500-700 child executions serially, or around 1400 child executions concurrently per second.
> An activity must encapsulate something much higher level than a single IO operation. So something like "Configure BGP on a router", "Start a VM" etc. It needs to be able to handle retries and thus be idempotent.
I was referring to the workflows, that is, writing the workflows in managed languages, not the activities.
Out of curiosity, are you working full-time on this? I'm working part-time on the same problem, looking to go full time soon, and it's interesting to see how the same ideas are popping up somewhat independently across different projects :) let me know if you're interested in chatting!
> I was referring to the workflows, that is, writing the workflows in managed languages, not the activities.
Ah understood. I have no plans supporting native workflow executors.
> Out of curiosity, are you working full-time on this?
Yes, currently I work on it full time.
> I'm working part-time on the same problem, looking to go full time soon, and it's interesting to see how the same ideas are popping up somewhat independently across different projects :)
Nice website! I also see the ideas of determinism, replayability etc more and more.
> let me know if you're interested in chatting!
Sure, my email is visible in the Git commit history.
So, I like this idea, I really do. At the same time, in the short-term, WASM is relatively messy and, in my opinion, immature (as an ecosystem) for prime time. But with that out of the way (it will eventually come), you'll have to tell people that they can't use any code that relies on threads, so they better know if any of the libraries they use does it. How do you foresee navigating this? Runtime errors suck, especially in this context, as fixing them requires either live patching code or migrating execution logs to new code versions.