5 ms·

On the same note, CloudFlare’s approach to serverless computing by leveraging V8 sandboxing instead of traditional virtualization is fascinating: https://blog.c

by Jhsto 8y ago

On the same note, CloudFlare’s approach to serverless computing by leveraging V8 sandboxing instead of traditional virtualization is fascinating: https://blog.cloudflare.com/cloud-computing-without-containers/ https://blog.cloudflare.com/cloud-computing-without-containe... Considering challenges of interconnected cloud computing and common IR (of which the latter is mentioned in this paper) an interesting distinction arises: WASM, in comparison to containers, brings us a single language (JS), and through this, possibly a single “orchestrator” (V8 Isolates). Of course, this is more or less saying that the world would be a better place if everyone would be driving a Volkswagen. But this is like a second chance to iterate such idea and maybe do something about it. Isn't this a step towards the future of cloud computing?

zackbloom 8y ago
Workers are network addressible which seems to directly respond to one of the complaints in the article. Beautifully, if you call one Worker from another they have a decent chance of running on not just the same server, but in the same process. When one Worker calls another its data doesn't even leave user-space, even if the two Workers are owned by different people. Imagine calling a third-party API and having your request never even need to leave the process to be handled.
- hueving 8y ago
  If the request never has to leave the process, that means there isn't anything the third party API is doing that persists state or calls out to another backend. In that case, wouldn't it just be better to import this third party API directly as code and call it for significantly better reliability, performance, and reduced complexity?
  - woah 8y ago
    Then your engineers are responsible for maintaining and updating it. Calling to a third party allows you to offload that.
  - zackbloom 8y ago
    There are advantages in being able to have a security barrier between your code and that of your customers, and that you can push releases etc without having to update every downstream consumer. More importantly though, we're working on incorporating storage in a meaningful way.
    - jayd16 8y ago
      If the third party code is running in the same process than the security is managed by V8 (or whatever runtime). Does such a thing exist in other managed languages? Does anyone know if C# or Java(for example) have the concept of untrusted libraries?
      - regularfry 8y ago
        Dunno about managed runtimes, but the whole thing sounds isomorphic to running a bunch of untrusted docker containers in a single qemu VM.
      - heavenlyblue 8y ago
        You could think of "untrusted library" as of a wrapper around an HTTP API. The code you don't run, but depend upon it's results.
johncolanduoni 8y ago
On the contrary, WASM brings us quite a few languages, and likely even more as compiler backends are developed and the platform’s capabilities are extended. It would actually be pretty terrible at running JS as it exists right now.
- skybrian 8y ago
  This is true, yet apparently we are standardizing on JavaScript for foreign function calls. How do you pass a string or an array between workers written in different languages, other than as JavaScript? It seems like whatever language you use for generating WASM gets hidden as an implementation detail.

by Jhsto 8y ago

zackbloom 8y ago

Workers are network addressible which seems to directly respond to one of the complaints in the article. Beautifully, if you call one Worker from another they have a decent chance of running on not just the same server, but in the same process. When one Worker calls another its data doesn't even leave user-space, even if the two Workers are owned by different people. Imagine calling a third-party API and having your request never even need to leave the process to be handled.

hueving 8y ago
If the request never has to leave the process, that means there isn't anything the third party API is doing that persists state or calls out to another backend. In that case, wouldn't it just be better to import this third party API directly as code and call it for significantly better reliability, performance, and reduced complexity?
- woah 8y ago
  Then your engineers are responsible for maintaining and updating it. Calling to a third party allows you to offload that.
- zackbloom 8y ago
  There are advantages in being able to have a security barrier between your code and that of your customers, and that you can push releases etc without having to update every downstream consumer. More importantly though, we're working on incorporating storage in a meaningful way.
  - jayd16 8y ago
    If the third party code is running in the same process than the security is managed by V8 (or whatever runtime). Does such a thing exist in other managed languages? Does anyone know if C# or Java(for example) have the concept of untrusted libraries?
    - regularfry 8y ago
      Dunno about managed runtimes, but the whole thing sounds isomorphic to running a bunch of untrusted docker containers in a single qemu VM.
    - heavenlyblue 8y ago
      You could think of "untrusted library" as of a wrapper around an HTTP API. The code you don't run, but depend upon it's results.

johncolanduoni 8y ago

On the contrary, WASM brings us quite a few languages, and likely even more as compiler backends are developed and the platform’s capabilities are extended. It would actually be pretty terrible at running JS as it exists right now.

skybrian 8y ago
This is true, yet apparently we are standardizing on JavaScript for foreign function calls. How do you pass a string or an array between workers written in different languages, other than as JavaScript? It seems like whatever language you use for generating WASM gets hidden as an implementation detail.