Cloudflare Workers run in V8 isolates, which are much lighter-weight than containers, with the ability to run thousands in the same process, and start up new ones quickly on-demand. For Cloudflare it's usually easier to start your application on the machine where it is requested, than to try to route to a machine where it's already running: https://developers.cloudflare.com/workers/reference/how-work...
This is one type of "binding" or "live environment variable" or "capability". You configure it at deploy time, and then at runtime you can just do `env.SOME_SERVICE.fetch(request)` to call to your other worker: https://blog.cloudflare.com/workers-environment-live-object-...
The API construct that lets a worker call another worker (in the same process, in fact, in the same thread) is a Service Binding: https://blog.cloudflare.com/service-bindings-ga/
This is one type of "binding" or "live environment variable" or "capability". You configure it at deploy time, and then at runtime you can just do `env.SOME_SERVICE.fetch(request)` to call to your other worker: https://blog.cloudflare.com/workers-environment-live-object-...
There's a fancy RPC system, although it's (for now) centered on JavaScript so not as relevant to Wasm users: https://blog.cloudflare.com/javascript-native-rpc/
(I'm the tech lead for Cloudflare Workers.)