fhuici

6 ms·

1.
by fhuici 3mo ago
FYI, a microVM isn't a small VM, nor necessarily one that has been allocated little RAM. The term comes from the fact that a microVM is launched with Firecracker (a Virtual Machine Monitor), and Firecracker itself, as far as Virtual Ma
2.
Serverless is a Broken Promise to Fix it(unikraft.io)
1 points by fhuici 2y ago|1 comments
3.
by fhuici 2y ago
Current serverless offerings come with a substantial litany of complex, frustrating and expensive issues that together constitute a far cry from the promise of serverless. In this post we look into why that is, what serverless should be,
4.
by fhuici 2y ago
On kraft.cloud we use Dockeffiles to build into extremely specialized VMs for deployment. With this in place, we can have say an nginx server cold started and ready to serve at a public URL in about 20 millis (not quite the 10ms you mention
5.
by fhuici 2y ago
We don't need all of those layers and abstractions of course. But if we do things right we also don't need to go the bare metal server route -- cloud platforms, if done right, can provide both strong, hardware-level (read: vm) i
6.
by fhuici 2y ago
Actually it means both, in an unfortunate case of term overload. Though I can understand the embedded/IoT world being frustrated by this, as the term existed first within that context.
7.
by fhuici 2y ago
The edge within this context means running a server close, in terms of Internet latency, to users. For example, if a user if sending a request from Germany, then the response should come from a server running in say Frankfurt, not the US. T
8.
by fhuici 2y ago
Yes, though I'd like to point out that "scale to zero" is a loose definition to mean anything that can be transparently scaled to 0 whenever an app/service is idle, and then wake up when traffic to the service arrives on
9.
by fhuici 2y ago
100% agree. In almost all cloud deployment, whether transparently or not, you'll have a hypervisor/VM underneath for hardware-level/strong isolation reasons. Using wasm on top of that stack only for isolation purposes might n
10.
by fhuici 2y ago
On kraft.cloud we can (done internal stress tests for this) run thousands of specialized VMs (aka unikernels) scaled to zero, meaning that when a request for one of them arrives we can wake it up and respond within the timescales of an RT
11.
by fhuici 2y ago
Hi, on kraft.cloud we use FC, along with a custom controller and very specialized VMs (unikernels) to have extremely efficient deployments (eg, millisecond cold starts). For a PHP web server, for instance, we can cold start things in about
12.
by fhuici 2y ago
Fully agree, doing reactive autoscaling when the actual boot time is slow is an inherently hard problem. We've done years of research into building specialized VMs (unikernels) and fast controllers to be able to provide infra that allo
13.
by fhuici 2y ago
[Disclaimer: I'm with KraftCloud] For what it's worth, Firecracker/the VMM is only one part of the boot process. Among others, there's also the controller and the VM/OS itself that typically slow things down. In ot
14.
by fhuici 2y ago
Author here, we did this, first by continuing the research alongside the creation of the Unikraft LF OSS project -- the result of which was the Eurosys 2021 best paper award ( https://dl.acm.org/doi/10.1145/3447786.
15.
by fhuici 2y ago
Hey, author/founder here, thanks for providing that answer, all correct there :) . I would also add that KraftCloud unikernels are built using Unikraft, and that its modularity allow us to tailor/specialize those images to obtain
16.
by fhuici 2y ago
The 125ms is using Linux. Using a unikernel and tweaking Firecracker a bit (on KraftCloud) we can get, for example, 20 millis cold starts for NGINX, and have features on the way to reduce this further.
17.
by fhuici 2y ago
Agree with epr's definition of a unikernel (and no, no mental decline on your part, this isn't always well defined). First off, a unikernel is a virtual machine, albeit a pretty specialized one. They're are often based on mod
18.
by fhuici 2y ago
The model of a single container within a VM just adds overhead. The ideal case would be to remove the container layer and have the application(s) within the container run directly in the VM (which hopefully only includes the libs and OS mod
19.
by fhuici 2y ago
[One of the authors of the paper] I wouldn't recommend writing a network stack from scratch, that is a lot of effort. Instead, with the Unikraft LF project (www.unikraft.org) we took the lwip network stack and turned it into a Unikra
20.
by fhuici 2y ago
[Author of the paper here] You hit the nail on the head, this is precisely what we do (kernel API compatibility) with the LF Unikraft project (the evolution of the 2017 paper) at www.unikraft.org, and kraft.cloud, a cloud platform that leve
21.
by fhuici 2y ago
Correct, we never did release Tinyx, mostly because it was in a very unclean/researchy state = not ready for public consumption. In retrospect, we probably should have either (a) made it available in whatever state it was in or (b) put
22.
by fhuici 2y ago
Maybe try out kraft.cloud: we take Dockerfiles as input and automatically convert to lightweight VMs/unikernels when deploying (disclaimer: I'm one of the paper's authors and one of the people behind KraftCloud).
23.
by fhuici 2y ago
Yes, Kata started as clear containers. And yes, the main purpose is compatibility with containers -- though generally speaking, adding layers to the cloud stack never helps to make a deployment more efficient. On kraft.cloud we use Dockerfi
24.
by fhuici 2y ago
Back when we did the paper, Firecracker wasn't mainstream so we ended up doing a (much hackier) version of a fast VMM by modifying's Xen's VMM; but yeah, a few millis was totally feasible back then, and still now (the evoluti
25.
by fhuici 2y ago
I agree with the other comments. On the cloud, the VM is still the golden standard for strong (hardware-level isolation): if you deploy a container in the cloud, you can almost be sure there's a VM underneath. Given this, what we tried
26.
by fhuici 2y ago
And these overheads are even smaller if you use unikernels as per the paper. Eg, cold starts of a few milliseconds depending on the app/size of the image.
27.
by fhuici 2y ago
On kraft.cloud we have unikernels (specialized VMs) with Prometheus exporters that can be scraped, and other monitoring facilities.
28.
by fhuici 2y ago
Check out kraft.cloud and the accompanying LF OSS project www.unikraft.org :) (disclaimer: I'm one of the authors of the paper and one of the people behind that cloud offering). On KraftCloud we use Dockerfiles so users can convenientl
29.
by fhuici 2y ago
[disclaimer: I'm one of the authors of the paper] I 100% agree, containers are an amazing dev env/reprodicble env tool! In fact, we think they're the perfect marriage to the unikernels (specialized VMs) we used in the paper;
30.
by fhuici 2y ago
Yes, we'll have pay as you go pricing plans.

More ›