nderjung
Joined 8 years ago
Karma
545
Submissions
98
Member since
Nov 16
Recent submissions
Comment · 1 month ago
Netlify use Unikraft for microVMs; just explaining the variant of Firecracker they are using.
Comment · 1 month ago
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:
Comment · 1 month ago
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
Comment · 4 months ago
Hi, Alex from Unikraft here. One clarification: Browser-Use didn't move away from Unikraft because of any limitation around browser startup times, snapshotting, scale-to-zero, or browser-level autoscaling. Those capabilities worked well and were a key reason they adopted the platform in the first place.
The challenge they encountered was at a different layer: horizontally scaling the underlying EC2 infrastructure. At the time, native EC2 fleet autoscaling wasn't yet supported by the platform, so they chose to take ownership of that part of the stack and build directly on Firecracker.
It's also worth noting that Unikraft is actively working on transparent infrastructure autoscaling (with live migration), so the gap they encountered is being addressed. The article's title may give the impression that unikernels were the bottleneck (they weren’t, and our platform transparently support Linux VMs as well), when in reality the decision was driven by infrastructure orchestration requirements rather than browser runtime capabilities.
As an aside, we love Browser-Use <3 and we still work together closely!
Comment · 8 months ago
Howdy! We are hard at work at improving the DX, and as a result we've been working on a brand new CLI. We haven't made any announcements yet, but it's already open-source for early adopts if you'd like to give it a try!
https://github.com/unikraft/cli
Feedback is very much appreciated, we're listening! :)
Comment · 9 months ago
Hey! Co-founder of Unikraft here.
Unikraft aims to offer a Linux-compatible environment (so it feels familiar) with the ability to strip out unnecessary internal components in order to improve both boot-time/runtime performance and operational security.
Why would you need a memory allocator and garbage collector if you serve static content? Why would you need a scheduler if your app is run-to-completion?
Linux gives you the safety-net of generality and if you want to do anything remotely performant, you by-pass/hack it altogether.
In the article, Unikraft cold-boots in 150ms in an emulated environment (TCG). If it was running natively with virtualization hardware extensions, it can be even shorter, and without the need for snapshots which means you don't need to store this separately either.
Comment · 2 years ago
Which OS and device are you using?
Comment · 2 years ago
This project operates by first building the webassembly module into an ELF binary and then statically linking this against the Mewz library OS in order to become a unikernel binary.
It looks still very early days in terms of supporting all libc/syscalls as well as support for different platforms.
I wonder how this compares in terms of performance to https://unikraft.org which is able to do the same but is a more establish libOS/unikernel project (disclosure I am a maintainer of Unikraft :-)) since this is written in Zig and Unikraft is written in C.
Comment · 2 years ago
Hi!
Thanks for the feedback!
Good point on the Kraftfile syntax and as you've seen, there is a reference document. We can make sure to place a link to this in all guides.
The term "KraftCloud Specification" is in fact incorrect, this should just be "`Kraftfile` specification".
We are working on providing a "Unikraft Hub". Since unikraft.org is a public OCI registry and it works through many popular tools like `crane` or `regtool` as well as our native `kraft` CLI tool; you can actually view it locally by running `kraft pkg ls --all --apps --remote`.
Thanks again for the feedback! We'll get on to updating the docs to make these bits clearer!