I recently built a similar thing for learning purposes using firecracker + the firecracker go api. I wrote a small init system in rust and combined that with filesystem images derived from the Debian, Ubuntu etc. container images (that can be extended with more layers).

What really surprised me the most, is how quick and simple it is to compile the linux kernel. Cloned a tag with --depth 1, configured it and then it took ~ 5 minutes to build vmlinuz.bin. As someone who is too young to have had to regularly do that, I had heard multiple stories of how long that's supposed to take but it really doesn't.

I then tried to move from firecracker to qemu microvms but didn't get that far yet since I didn't have more time.

All in all a great learning experience and if I wasn't an undergrad student with no time, I'd love to build a service/business around it.

> I had heard multiple stories of how long that's supposed to take but it really doesn't.

It used to, but that's why they are only stories now.

it /used/ to take forever back in the Core 2 Duo days, with the amount of cores and the sheer speed of the IPC its gotten a ton better.

Wow!

I came across Unikraft a while ago and went “wow that’s cool, but I have no idea how to use this”, cloud offering and docs you have up there now look amazing! Will 100% be giving this a go first thing tomorrow!!

I thought that’s what fly.io is, although I’m not familiar with it, am I missing something?

Fly: takes your docker image, converts it into a Firecracker VM and runs that: kernel boundaries etc are all the same as before (and the same as running your container locally).

Kraft Cloud: takes your docker image, and turns it into a “unikernel”, and runs that. In a unikernel, your application _is_ the kernel. There’s no process boundary, no kernel-space/userspace split there’s a single address-space etc.

I believe the idea is that you get a perf benefit-as your application is often the only one running in the container, security is provided by the hupervisor anyways, so may as well cut out all the middle layers that aren’t getting you much. Seems some of the authors/founders of Unikraft are in the comments, they can explain much better than I.

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 great perf.

Finally, we also had to design and implement a controller from scratch -- nothing out there provided the millisecond semantics and scalability we needed (plus we also did tweaks to network interface creation and a few other things to get the end to end experience to be fast).

That sounds amazing! Very keen to give it a try.

My work had a product that was doing builds and hosting for arbitrary client code, you’re doing all that, plus more. I’ve got massive respect for that, because there were some hard problems to solve, even in our pretty vanilla environment- looks like you guys have done a far better job than we did, plus more!

It sounds like consequences of bugs like memory corruption are far more challenging to deal with in the Kraft cloud situation. Sometimes isolation has other benefits.

Isn't that better isolation though ? A memory corruption will at worse break the OS which is the app and nothing else. Push the model further and you can have one unikernel per user and reduce even further the consequences of bugs

That is a very clever idea!