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