In the meantime, a handful of organisations/individuals seem to be working on becoming "Docker for unikernels". That's probably an unfair description, but they're aiming to produce tools for building and managing unikernels: Unikraft [1], NanoVMs/Nanos [2], Unik [3]. Other orgs are producing unikernel-based OSs and VMs [4].
What is your toolset for building and managing unikernels? What have you learned?
Bonus question: is Unik dead? [5]
[0] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
[2] https://github.com/nanovms/nanos
[3] https://github.com/solo-io/unik/
Or do you basically have to maintain a port of your software so that you can also run it on Linux with all the creature comforts of a normal system? If it's that, do you get weird bugs that only happen in prod and which are a gigantic pain to understand and work through?
- some run only one language
- some require recompilation
- some essentially swap out libraries, others do something closer to dropping your already mostly static binary in a minimal disk image
- some build pid1 processes, others VMs images
Anyway, here are some additional entries in the space:
- https://ssrg-vt.github.io/hermitux/
- https://github.com/linuxkit/linuxkit (more embedded/minimal VM than unikernel)
- https://nabla-containers.github.io/ (runs on Solo5)
I am going through using Linuxkit to build AMIs for cloud providers now from containers. I wouldn’t necessarily class linuxkit as a unikernel project because it doesn’t have the hallmark blurring of user and kernel space or kernel-as-a-library but you can customize the kernel so it’s an adjacent idea, and I think it’s the one most likely to be in actual use at non-hyperscalers.
[EDIT] Added OSv since it's on one of the linked lists but is a pretty large active player in the field.
We talked about a mixture of Unikernels in general and how they run their infrastructure.
What's interesting about Nanos is it's POSIX compliant. In other words you don't have to write your app differently to get it to run in their Unikernel.
That said, no modern router is a "unikernel" anymore, and the low end switches fall more into the embedded systems category.
(btw: out of curiosity, how would HN differentiate between an embedded system/RTOS and an unikernel?)
I’m not sure why unikernels have not caught on widely. I suspect their time has yet to come for some applications, but at least for NFV and sandboxing, I would bet on solutions using eBPF or XDP with WASM for sandboxing.
One of the cooler things that we've found though is that there is a very wide misconception that you'll need a k8s for unikernels - that is simply not the case. When we deploy them to the cloud we use the underlying storage/networking layers that already exist - so we don't have to manage all of that. Unikernels remove a lot of the complexity that comes with container infrastructure.
When you deploy a Nanos unikernel we create a machine image, which if you are deploying to say AWS becomes an ec2 image and then the instance that spins up is that unikernel - there is no layer of Linux that you deploy something else to. I highly recommend that anyone that is remotely interested to just try it out - https://ops.city - it'll clear up any deployment/orchestration questions you have almost immediately.
In fact, speaking of AWS we just reduced the deploy time there by 66% so now you can build/deploy your unikernel to AWS in < 20 seconds. It's actually faster than deploying to Google Cloud and that remains my favorite place to deploy them.
I don't think unikernels are worth it unless you're running at massive scale. A realistic target audience is providers of serverless-style services, in which case you're taking a vanilla application someone else wrote and compiling it against a unikernel.