Hacker News Reader

Comment by verdverm | Hacker News Reader

> We believe that is the future of Serverless and cloud computing in general, and I’ll try to convince you why.

Reads like an opinion piece. Technically weak on details and the comparisons leave a lot to be desired

> I believe lowering costs by 3x is a strong enough motivator that it alone will motivate companies to make the switch to Isolate-based providers.

depends on so much more than price... like do I want to introduce a new vendor for this isolate stuff?

> An Isolate-based system can’t run arbitrary compiled code. Process-level isolation allows your Lambda to spin up any binary it might need. In an Isolate universe you have to either write your code in Javascript (we use a lot of TypeScript), or a language which targets WebAssembly like Go or Rust.

If one writes Go or Rust, there are much better ways to run them than targeting WASM

Containers are still the defacto standard

View on HN

> If one writes Go or Rust, there are much better ways to run them than targeting WASM

wasm has its place, especially for contained workloads that can be wrapped in strict capability boundaries compile-time (think, file-encoding jobs that shouldn't access anything else but said files: https://news.ycombinator.com/item?id=29112713).

> Containers are still the defacto standard.

afa FaaS is concerned, wasmedge [0], atmo [1], tarmac [2], krustlet [3], blueboat [4] and numerous other projects are turning up the heat [5]!

[0] https://github.com/WasmEdge/WasmEdge

[1] https://github.com/suborbital/atmo

[2] https://github.com/madflojo/tarmac

[3] https://github.com/krustlet/krustlet

[4] https://github.com/losfair/blueboat

[5] https://news.ycombinator.com/item?id=30155295

WASM could be nice if you do not control the running environment (browser), once it matures more. I don't see the benefit of adding the v8 runtime as a layer for anything that is not native to it. More abstraction and complexity gives rise to concern

There are interesting plans to speed up [the cold start latency of] V8 by compiling it to wasm[0]

AFAIU the main point is that for wasm you can condense startup to a mmap operation and that you can "freeze" a running wasm process (essentially by dumping the memory/stacks to a new wasm module. In [0] they use [1] to do this.

[0] https://bytecodealliance.org/articles/making-javascript-run-... [1] https://github.com/bytecodealliance/wizer

> If one writes Go or Rust, there are much better ways to run them than targeting WASM

Is there a similar priced way to run Go or Rust with similarly fast cold starts and low latency?

I think this is the real selling point of isolates; inefficient if you want to run a postgres server but perfect for low latency edge stuff.

There is the usual argument that on premise/dedicated servers scales way better that people expect, nonetheless the trend seems to be a move towards smart CDNs...

> Is there a similar priced way to run Go or Rust with similarly fast cold starts and low latency?

I keep hearing good things about Firecracker in that regard (https://firecracker-microvm.github.io/).

> Is there a similar priced way to run Go or Rust with similarly fast cold starts and low latency?

A binary?

I tried to find the "A binary" service but no cloud offering seems to have it. You always have to wrap it in a container, VM or external runtime to do that.

If you don't care about isolation... to do so requires a VM to securely isolate and that is a significant startup time and resource usage over a wasm module.

You could run it in a very simple container, unshare(1) style. This adds no measurable overhead to binary startup time. https://man7.org/linux/man-pages/man1/unshare.1.html

Containers do not provide sufficient isolation to run untrused binaries. That's why aws built and uses firecracker for lambda.

VMs are also full of side channels. Depending on how much isolation is a concern, you need to own the host.

I don't trust VMs particularly more than containers in this respect: Containers have a lot of attack surface, but VMs also have a lot of complicated in the code in the kernel, in addition to having complicated emulated device drivers and a large silicon-based attack surface.

Google Cloud Functions and Cloud Run are good options, I prefer Run which runs arbitrary containers

'FROM scratch' for a binary only container

>If one writes Go or Rust, there are much better ways to run them than targeting WASM

>Containers are still the defacto standard

But that really depends on just how compute heavy the service in question is. For a lot of lightweight "frontend" (yes we're still talking server side, but you get the point) code for some API endpoint there's some lightweight glue logic between it and whatever backend services are involved. Targeting WASM in V8 might not have much of a performance hit at all compared to a native binary and if it allows your tiny service to only use 3MB of RAM instead of e.g. 100MB then that's still a pretty big win, even discounting the resource cost, because now you're avoiding context switches and running off of a shared runtime that's already going to have a bunch of hot paths fitting into cache.

The argument for V8 Isolates vs containers has a ton of overlap with the argument for containers vs. VMs. Yes there are security concerns, yes you're giving up some level of functionality but if you don't need a full container then the lighter abstraction might be the more efficient choice just as containers are often a better fit than a full VM. If the service in question is a good fit for Node then it might also be a good fit even using WASM from a Rust codebase to run on V8.

I'd be surprised if many Go -> WASM would fit in 3MB of ram

That's before you worry about the fact that Go has a different runtime and mem management strategy. I'd only use Go WASM for toys at this point

Fair point, Go in particular is a bad example on my part. I'm only suggesting that just because some existing codebase is in a different language doesn't mean that running on WASM is never going to be practical. Yeah not as good as native, but if it means you can target V8 as a VM instead of x86 then it still might win out.

Indeed, I'm keeping my eye on WASM but still expect it to require more time to bake

I may have also reached the point in my career where I don't want to use the latest and greatest runtime. Stability has its merits

Reply on news.ycombinator.com