Thread

5x faster Edge Functions: V8 isolates to Firecracker MicroVMs

229 points · 106 comments · jbott

Normal_gaussian · 1790802926 · focus · HN ↗
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.
1. jst1fthsdys · 1790803807 · focus · HN ↗
  25 USD/m to run a daemon on my own hardware. Yikes.
  1. binsquare · 1790806021 · focus · HN ↗
    That seems off to me as well.
    Fwiw, you can run this instead free and open source: <a href="https://github.com/smol-machines/smolvm" rel="nofollow">https://github.com/smol-machines/smolvm
    Disclaimer: Am author.
    QGQBGdeZREunxLe · 1790809419 · focus · HN ↗
    Brew tap: <a href="https://github.com/smol-machines/homebrew-tap" rel="nofollow">https://github.com/smol-machines/homebrew-tap
    Cyph0n · 1790820570 · focus · HN ↗
    This looks amazing! The credential injection trick is particularly cool :)
    chrisweekly · 1790832279 · focus · HN ↗
    you beat me to it (I'm singing the praises of smolmachines.com "smolvm" microvms all over the place)
    binsquare · 1790833323 · focus · HN ↗
    Appreciate your support!
    dprkh · 1790838210 · focus · HN ↗
    Why is this better than just using Docker?
    binsquare · 1790840212 · focus · HN ↗
    Kernel level isolation.
    Functionality of criu built in so you can get rewind, pause, in an accessible manner.
    Embeddable (you can write JavaScript to programmatically use an isolated environment)
    Native performance on multiplatform + consistent experience across platforms.
    stavros · 1790844765 · focus · HN ↗
    This sounds great. By the way, does "kernel-level isolation" mean "you have to allocate a chunk of RAM to this"? Or is that CPU-level?
    EDIT: Ah, looks like it means "runs its own kernel", not "isolates at the kernel" like Docker does.
    binsquare · 1790848288 · focus · HN ↗
    yes, separate kernels + virtualized hardware via hypervisor.
    containers are built on linux primitives & so shares the kernel.
    stavros · 1790850989 · focus · HN ↗
    Excellent, thank you. This is definitely useful to me.
    zmmmmm · 1790844816 · focus · HN ↗
    amazing!
    any point of comparison with microsandbox? [0]
    [0] <a href="https://github.com/superradcompany/microsandbox" rel="nofollow">https://github.com/superradcompany/microsandbox
    binsquare · 1790847286 · focus · HN ↗
    I focus on building the best VM tech.
    Good sandboxing is a feature of a good VM.
    Outside of that I support GPU and enables something called branchable computing.
    Normal_gaussian · 1790851176 · focus · HN ↗
    Smolvm with it's libkrun vmm provides significantly worse security positioning than slicervms use of firecracker, which leads to slicervm for any dangerous or secure workload.
    <a href="https://github.com/libkrun/libkrun" rel="nofollow">https://github.com/libkrun/libkrun
    binsquare · 1790851661 · focus · HN ↗
    Libkrun and firecracker had similar foundations (Rust, KVM, rust-vmm).
    Firecracker has a long track record but has a lot of knobs and tunings to get the security right.
    smolvm's serve mode confines each VMM by default with a seccomp allowlist, Landlock, a per-VM uid and no_new_privs, much like Firecracker's jailer.
    For dangerous workloads, people can do the same things such as skip host mounts and use virtio-net.
    It's not a different security class just because it's libkrun vs firecracker
    tomjen3 · 1790885818 · focus · HN ↗
    That is so effing cool — my only fear with it is whether you could turn it into a sustainable business, because I want that project to be around for a long time.
    binsquare · 1790893503 · focus · HN ↗
    I'll keep it going just for you
  2. QGQBGdeZREunxLe · 1790806896 · focus · HN ↗
    I think Alex learned his lesson offering a free version running OpenFaaS.
    alexellisuk · 1790845871 · focus · HN ↗
    The world: "build a secure, enterprise-ready microVM automation solution - work on it full time, and pay salaries for the staff that work on it"
    Also: it has to be free.
    So yes you're right, people confuse VC backed companies, and vibe-coded pet-projects for sustainable software.
    SlicerVM was started in 2022 and internal only, plenty of YouTube videos and such about it - written completely manually from our Actuated work.
    There's a free trial for anyone who wants to play about on their Mac or Linux computer, the comment here is from a real user (unprompted) that knew and used free alternatives previously.
2. innocent_name · 1790806309 · focus · HN ↗
  <a href="https://unikraft.com/blog/netlify-edge-functions" rel="nofollow">https://unikraft.com/blog/netlify-edge-functions and <a href="https://slicervm.com/" rel="nofollow">https://slicervm.com/ both using the lookalike slop design template made me to believe it was a shadowy unikraft project lol.
3. dwroberts · 1790840411 · focus · HN ↗
  > I see firecracker replacing docker on the horizon
  I don’t think this is going to happen because they serve different purposes. Having to boot an entire OS inside a VM is a step backwards compared to containerisation. There are definitely use cases for isolating containers by running them inside a VM (see: Kata) but it generally ‘replacing’ docker, I don’t think that is on the horizon at all
  (Also: you need KVM available, you need a rootfs to boot which will be larger than a container, it has no built in support for mounts or really any kind of communication with the host unless you explicitly set up networking etc for it)
  1. jeroenhd · 1790845557 · focus · HN ↗
    > Having to boot an entire OS inside a VM
    The whole point of Firecracker over normal VM solutions is that "booting an OS" takes milliseconds.
    Still, I don't think Docker is at risk of being replaced just yet because of the resource management benefits you get from sharing a kernel.
    Normal_gaussian · 1790850327 · focus · HN ↗
    Balloon devices go a long way for ram sharing, though not all the way. CPU scheduling is great.
    There's definitely a tradeoff, but IME it's not as drastic as you first think.
    dwroberts · 1790850890 · focus · HN ↗
    Whether it takes milliseconds or seconds though, you are still doing it. You’re still just running a VM
    troupo · 1790857446 · focus · HN ↗
    > The whole point of Firecracker over normal VM solutions is that "booting an OS" takes milliseconds.
    Define "OS". A barebones OS will indeed start in microseconds. But then your app/service won't. Because it will likely need a gazillion things that a barebones OS doesn't provide. Suddenly the startup time isn't microseconds or even milliseconds.
    Sadly, we never got the promise of unikernels, and everything requires the full-blown OS to run anything
    jeroenhd · 1790860797 · focus · HN ↗
    The VM's I'm talking about don't run some kind of weird bespoke OS, just a normal Linux kernel. You can make Linux boot quite quickly if you strip out everything but the hardware you virtualise, and if you resume a snapshot from CoW RAM, you don't even need to do that.
    I don't have any recent measurements myself, but the startup time for a full Linux kernel using Firecracker's snapshotting feature seems to be around 30ms if you optimise calls for latency: <a href="https://dev.to/adwitiya/how-i-built-sandboxes-that-boot-in-28ms-using-firecracker-snapshots-i0k" rel="nofollow">https://dev.to/adwitiya/how-i-built-sandboxes-that-boot-in-2...
    The measurements in that blog post place Firecracker above Docker in terms of startup performance. Most of that delay is probably the Docker daemon rather than Linux namespace APIs, but that's beside the point.
    Huggingface places Firecracker startup time between 100-300ms while Docker is at 50-200ms, based on Kata: <a href="https://huggingface.co/blog/agentbox-master/firecracker-vs-docker-tech-boundary" rel="nofollow">https://huggingface.co/blog/agentbox-master/firecracker-vs-d...
    Either way, latency is in the same ballpark of "low enough that it only matters in edge cases".
    pjmlp · 1790884817 · focus · HN ↗
    I would say that kind of got halfway there, when doing serverless.
    The gazillion things that the OS doesn't provide is taken care by language runtimes, which can perfectly run directly on top of type 1 hypervisors.
    In similar way how some of those languages have bare metal implementations for embedded development, where the runtime takes the OS role.
    Naturally on languages with thin runtimes and heavy reliance on POSIX like C and C++, this isn't as straightforward.
    chrisweekly · 1790871629 · focus · HN ↗
    Hmm... "resource management benefits you get from sharing a kernel" costs the security risks you incur from not having kernel-level isolation.
    These days I'm looking at microvms (esp. smolvm from smolmachines.com) by default, for anything where I'd previously have reached for docker (via colima or more recently orbstack).
  2. spwa4 · 1790873205 · focus · HN ↗
    > Having to boot an entire OS inside a VM is a step backwards compared to containerisation
    If it boots faster than a container ...
    Also containers don't work well with remote filesystems, or filesystems in general, because the admin always limits you.
4. tietjens · 1790842828 · focus · HN ↗
  Would love to read a blog post about this if you've every time to cobble one together.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.