Also the only cloud provider it has installation instructions for is AWS's EKS platform. Yet it has integration instructions for Azure CosmosDb Gremlin API.
That one customer out there using EKS and Gremlin on CosmosDb is probably over the moon right now.
I am the Drasi engineering manager, and I can assure you that any weirdness you sense is purely accidental.
The project was announced through standard Microsoft channels by Mark Russinovich and is part of the Microsoft Collaboration on GitHub. But we are predominantly an open source project from the Azure Incubations team which has a history of releasing open source projects. So we don't feel the need to constantly remind everybody that we are a Microsoft project and team.
The documentation site is missing some content that wasn't ready in time for the release but it includes AKS install instructions as well as additional Source and Reaction docs. These will be out soon.
If you know that customer that uses EKS and Cosmos Gremlin, please let us know, we would also be over the moon.
In any case, the Drasi Team is most active over on our discord channel(https://aka.ms/drasidiscord) where we would love to answer any questions you have about Drasi and help you get up and running.
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 evolution of that paper is Unikraft, a LF OSS project at www.unikraft.org).
(Cold) boot times are determined by a chain of components, including (1) the controller (eg, k8s/Borg), (2) the VMM (Firecracker, QEMU, Cloud Hypervisor), (3) the VM's OS (e.g., Linux, Windows, etc), (4) any initialization of processes, libs, etc and finally (5) the app itself.
With Unikraft we build extremely specialized VMs (unikernels) in order to minimize the overhead of (3) and (4). On KraftCloud, which leverages Unikraft/unikernels, we additionally use a custom controller to optimize (1) and Firecracker to optimize (2). What's left is (5), the app, which hopefully the developers can optimize if needed.
LightVM is stating a VM creation of 2.3ms while Firecracker states 125ms of time from VM creation to a working user space. So this comparing apples and oranges.
I know it's cool to talk about these insane numbers, but from what I can tell people have AWS lambdas that boot slower than this to the point where people send warmup calls just to be sure. What exactly warrants the ability to start a VM this quickly?
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.
Not sure an OS created to meet the specific need of VC funded startup, created exclusively by employees of that company should be called a "community Linux".
Totally understand the concern. We've tried to draw a very clear line between Wolfi (the project), and Chainguard Images (our product). They're in different GitHub organizations, have different maintainers, and are documented differently.
We (Chainguard) still represent most of the maintainers to Wolfi, but there are external folks too. We're going to need help scaling Wolfi to get it to where we want it to be, and that will require a real community.
We do fully intend for wolfi to be a community project, but it will take some time. We do say on the home page:
>What are the plans for long-term Wolfi governance?
We intend for Wolfi to be a community-driven project, which means over time it will have multi-vendor governance and maintainers. For now we're focused on building the project and community, and will revisit this in several months when a community has formed.
