I've been using SlicerVM extensively - which is Firecracker MicroVMs for the regular person (and for the irregular with their platform offering) - to run local 'edge' style workloads locally and securly. Agents, local dev CI, etc. It slotted in and replaced my proxmox vm orchestrator, and now I have secure and and fast vms on my laptop wherever I go. It also supports dockerfile style builds if you're wanting a security upgrade from containers (which, you should if you're using agents).
Honestly, while I see firecracker replacing docker on the horizon I don't see firecracker replacing v8 isolates for most edge function execution. Firstly, this article's scenario is a bit unusual in that they were using someone else's isolates - so adding on a few hops; secondly isolates running JS/TS can be statically analyzed quite well, and at scale looking historically for issues and exploits, in many edge compute scenarios this is quite desirable. MicroVMs can have an awful lot more flexibility so to get the same benefit you have to really lock down what is available - the trade-offs for mid-size companies seems to benefit isolates. Obviously netlify is more than big enough and relies heavily on this that it leans in their favour.
I'm having trouble understanding/believing this, given that Cloudflare Workers are also v8 isolates and run vastly faster than the 25-40ms that netlify says their isolates took...
from the article: "With our old infrastructure it went out over the internet, ran the edge function, and came back to us to pass on. With the new compute platform, the request is forwarded to a compute node within our network."
As far as I know, Cloudflare Workers have always executed within Cloudflare's network, not gone out to the internet and executed elsewhere (which I read as being in a hyperscaler cloud).
> In the past, requests went out to a hosted execution service. Today, they run on MicroVMs inside our own edge network — roughly 5x faster at the median.
So, the execution itself might now be slower as far as we know, they just eliminated some networking from the mix? Misleading.
The next time you want to curse AWS, remember they gave us Firecracker, one of the best microvm technologies out there, and the basis of at least a few non-AWS products out there (this one being the newest entry to the list).
> When the MicroVM boots up and the JavaScript server begins to listen on a port, we take a snapshot of the MicroVM. [...] we start a new MicroVM from that snapshot.
That sounds scary, since forked RNG states can lead to catastrophic failures in UUID generators or cryptography.
You’d hope so, though it’s not unheard of to get this wrong. Fastly managed to snapshot guest seeds and use them at runtime for RNG in their WASM snapshots a few years ago https://nvd.nist.gov/vuln/detail/cve-2022-39218
This is highly interesting considering AWS invented the MicroVMs for lambda, yet node on lambda is dog slow (both in latency and throughput). I can traumadump on request. I bet they could use some of this tech especially since their use cases are often not too dissimilar (auth validation, rule checking etc)
It is originally AWS, though we forked Firecracker ~4 years ago now and maintain an internal version with custom hypercalls (command-and-control from within the VM, POSIX-style fork, etc.) and a number of other features. We regularly pull patches and fixes from upstream Firecracker. You can read about the differences here:
v8 isolates aren't actually a great sandbox and I would not trust them implicitly in the AI era. This is probably why they wrap them in an additional sandbox.
Without commenting on v8 isolates specifically, this doesn't necessarily hold in any isolation situation; many customers are running code on behalf of their customers, which are often submitting jobs on behalf of theirs, and so on. Isolation breaches within a platform customer can result in significant cross-user data breaches.
Not only are they shared kernel... They're shared process, shared address space, shared memory pool and allocator... In fact, there is very little isolated about them at all.
I bet there are a million ways to cause side channels allowing learning about other code or data on the same machine, and just one V8 bug (of which there have historically been thousands) let's you take over or modify code in another isolate.
I've been using SlicerVM extensively - which is Firecracker MicroVMs for the regular person (and for the irregular with their platform offering) - to run local 'edge' style workloads locally and securly. Agents, local dev CI, etc. It slotted in and replaced my proxmox vm orchestrator, and now I have secure and and fast vms on my laptop wherever I go. It also supports dockerfile style builds if you're wanting a security upgrade from containers (which, you should if you're using agents).
Honestly, while I see firecracker replacing docker on the horizon I don't see firecracker replacing v8 isolates for most edge function execution. Firstly, this article's scenario is a bit unusual in that they were using someone else's isolates - so adding on a few hops; secondly isolates running JS/TS can be statically analyzed quite well, and at scale looking historically for issues and exploits, in many edge compute scenarios this is quite desirable. MicroVMs can have an awful lot more flexibility so to get the same benefit you have to really lock down what is available - the trade-offs for mid-size companies seems to benefit isolates. Obviously netlify is more than big enough and relies heavily on this that it leans in their favour.
25 USD/m to run a daemon on my own hardware. Yikes.
That seems off to me as well.
Fwiw, you can run this instead free and open source: https://github.com/smol-machines/smolvm
Disclaimer: Am author.
Brew tap: https://github.com/smol-machines/homebrew-tap
I think Alex learned his lesson offering a free version running OpenFaaS.
https://unikraft.com/blog/netlify-edge-functions and https://slicervm.com/ both using the lookalike slop design template made me to believe it was a shadowy unikraft project lol.
Alex from Unikraft here! Happy to answer any questions about the microVM part of the story from our side.
We also did a couple of technical write ups if you're interested:
- https://unikraft.com/blog/netlify-edge-functions
- https://unikraft.com/customer-stories/edge-functions-netlify
I'm having trouble understanding/believing this, given that Cloudflare Workers are also v8 isolates and run vastly faster than the 25-40ms that netlify says their isolates took...
from the article: "With our old infrastructure it went out over the internet, ran the edge function, and came back to us to pass on. With the new compute platform, the request is forwarded to a compute node within our network."
As far as I know, Cloudflare Workers have always executed within Cloudflare's network, not gone out to the internet and executed elsewhere (which I read as being in a hyperscaler cloud).
> In the past, requests went out to a hosted execution service. Today, they run on MicroVMs inside our own edge network
The isolates were not being run at the edge.
They were running on the edge, and in the same datacenters but by another provider.
> In the past, requests went out to a hosted execution service. Today, they run on MicroVMs inside our own edge network — roughly 5x faster at the median.
So, the execution itself might now be slower as far as we know, they just eliminated some networking from the mix? Misleading.
The next time you want to curse AWS, remember they gave us Firecracker, one of the best microvm technologies out there, and the basis of at least a few non-AWS products out there (this one being the newest entry to the list).
> When the MicroVM boots up and the JavaScript server begins to listen on a port, we take a snapshot of the MicroVM. [...] we start a new MicroVM from that snapshot.
That sounds scary, since forked RNG states can lead to catastrophic failures in UUID generators or cryptography.
Firecracker has existing solutions to this, which I assume they're using: https://github.com/firecracker-microvm/firecracker/blob/main...
You’d hope so, though it’s not unheard of to get this wrong. Fastly managed to snapshot guest seeds and use them at runtime for RNG in their WASM snapshots a few years ago https://nvd.nist.gov/vuln/detail/cve-2022-39218
This is highly interesting considering AWS invented the MicroVMs for lambda, yet node on lambda is dog slow (both in latency and throughput). I can traumadump on request. I bet they could use some of this tech especially since their use cases are often not too dissimilar (auth validation, rule checking etc)
seriously - if netlify can do 15ms warm start + 10ms cold start, wtf is lambda doing for the other 1500ms?
> they could use some of this tech
Firecracker is AWS tech, and was behind both Lambda & Fargate. I imagine it's all the enterprisey extras built on top that cause those issues.
It is originally AWS, though we forked Firecracker ~4 years ago now and maintain an internal version with custom hypercalls (command-and-control from within the VM, POSIX-style fork, etc.) and a number of other features. We regularly pull patches and fixes from upstream Firecracker. You can read about the differences here:
https://unikraft.com/blog/unikraft-vs-firecracker
Weird time to advertise your product.
When would you prefer they advertise? Seems entirely relevant.
When they're contributing to the conversation. It's not relevant.
How is it not relevant? In what way doesn't it contribute?
It's on you to prove it does. In what ways does it contribute?
We now know about their unikraft VM, whereas previous we did not.
If only there was an HN guideline about not using the site primarily for promotion.
fargate is not firecracker
can confirm that this is true for the fargate product used by consumers.
as someone who worked on it
From the Firecracker README:
https://github.com/firecracker-microvm/firecracker
"Firecracker was developed at Amazon Web Services to accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate."
Wish it explained where the v8 isolate latency is coming from compared to microvms
"In the past, requests went out to a hosted execution service."
They were outsourcing to another company so there's plenty of room for overhead to creep in.
v8 isolates aren't actually a great sandbox and I would not trust them implicitly in the AI era. This is probably why they wrap them in an additional sandbox.
But I guess they are good enough to isolate multiple instances of the same code, ran by the same customer in parallel.
Without commenting on v8 isolates specifically, this doesn't necessarily hold in any isolation situation; many customers are running code on behalf of their customers, which are often submitting jobs on behalf of theirs, and so on. Isolation breaches within a platform customer can result in significant cross-user data breaches.
Why are v8 isolates bad, I see speculative execution hacks, but are there others?
Despite naming them isolates, the V8 team does not consider them to be a security boundary.
The v8 JIT is very complex and can lead to sandbox escapes if there are type confusion bugs.
v8 isolates are still shared kernel
while microvm's are separate kernel + hardware virtualization through hypervisor guarantees
I wouldn't call it bad either, just different tools for different things
Not only are they shared kernel... They're shared process, shared address space, shared memory pool and allocator... In fact, there is very little isolated about them at all.
I bet there are a million ways to cause side channels allowing learning about other code or data on the same machine, and just one V8 bug (of which there have historically been thousands) let's you take over or modify code in another isolate.
If you're counting milliseconds why use Javascript?
V8 is extremely optimized for script startup time.
V8 isn't written in JavaScript?