Unikernels are specialised, single address space machine images constructed by using library operating systems -- Wikipedia
Unikernels promise lightweight, secure, minimalistic image to boot and run. They assume being run in a secure hypervisor, so can do away with a lot of complexity of a modern OS. There are two main approaches:
- clean slate, where a new, minimal unikernel is written in a modern language
- strip-down, where an existing kernel is simplified to reduce its overhead and remove unnecessary features
Feb 2022 (is this out of date? Send a PR)
Despite a lot of hype around 2015-2016, the unikernels didn't blow up in popularity the way that containers or Kubernetes did.
The main blockers for a wider adoption of unikernels appear to be:
- compatibility with existing code
- lacking debuggability (monitoring, logging, familar tools, ...)
- lacking universality - each unikernel only supports a subset of languages
- lacking accepted standard (like Linux or Docker)
- running as VMs means applications can't share some resources (unused RAM) like they can in Linux containers
A few thoughts (correct me):
- Security one of the strongest arguments for a unikernel is the reduced attack surface. While that's difficult to argue with, that same approach makes for more difficult debugging. Similar to debugging a FROM SCRATCH container from inside the container. While this can be alleviated by baking in debugging and monitoring tools, this goes against the whole idea.
- Lightweight another strong argument for unikernels: low overhead and small memory footprint. The flip side, is that you will need to allocate a certain amount of resources for your VM, that can't be shared with other applications like they can with Linux containers. So you might not be able to flatpack as much as you can with containers.
- Performance while a simple kernel without the overhead of syscall switch does increase the performance of some operations, it's not clear how well that applies to applications for which the syscalls aren't bottlecks. Besides, the high performance comes at a cost, so will only be an acceptable tradeoff for a subset of applications.
- Debugging/Monitoring with the advent of eBPF, the visibility into the kernel has increased dramatically, so the standard have risen. Unikernels would need to provide a viable alternative for massive adoption to happen.
- Scheduling containers now have a few options for scheduling (Kubernetes, Nomad, etc). Scheduling VMs with something like OpenStack would require a lot of improvement to get to the level of ease/speed that the container-specific solutions provide. This could be alleviated with things like Firecracker that can integrate with Kubernetes, but these haven't exactly blown up in popularity either.
- Compatibility containers package existing software and run it unchaged. Unikernels require compiling the kernel together with the application. There are some solutions that can produce a Linux binary for debugging and a kernel image for production. Keeping your unikernel (mostly) Linux-compatible is possible, but requires some glue.
Currently, the only two with commercial support I could find are Unikraft and NanoOS. If you're looking to learn to make your own, check out StardustOS used to teach at St Andrews university, which includes a minimal kernel for Xen that's easy to browse through.
| Project | language | src | started | last commit | status |
|---|---|---|---|---|---|
| Unikraft | C | https://github.com/unikraft/unikraft | 2017 | recent | active |
| NanoOS | C | https://github.com/nanovms/nanos | 2017 | recent | active |
| Mirage OS | OCaml | https://github.com/mirage/mirage | 2014 | recent | active |
| OSv | C | https://github.com/cloudius-systems/osv | 2012 | recent | active |
| RustyHermit | Rust | https://github.com/hermitcore/rusty-hermit | 2019 | recent | active |
| HermiTux | C | https://github.com/ssrg-vt/hermitux | 2017 | recent | active |
| StardustOS | C | https://stardustos.gitbook.io/stardust/ | 2019 | recent | active |
| Rumprun | C | https://github.com/rumpkernel/rumprun | 2014 | 2020 | active? |
| Click OS | C++ | https://github.com/sysml/clickos | 2007 | 2014 | dead |
| Clive | Go | https://github.com/fjballest/clive | 2015 | 2016 | dead |
| HaLVM | Haskell | https://github.com/GaloisInc/HaLVM | 2010 | 2018 | dead |
| GUK | C | https://github.com/Leonidas-from-XIV/guestvm-guk | 2011 | dead | |
| runtime.js | C++, JS | https://github.com/runtimejs/runtime | 2014 | 2019 | dead |
| Include OS | dead | ||||
| LING | dead | ||||
| Drawbridge | ??? |
| Project | language | src | started | last commit | status |
|---|---|---|---|---|---|
| Unik | Go | https://github.com/solo-io/unik | 2016 | 2019 | dead? |
- “Unikernels: Library Operating Systems for the Cloud” (Madhavapeddy, et al., 2013)
- "Unikernels: The Next Stage of Linux’s Dominance" (Ali Raza, Parul Sohal, James Cadden, Jonathan Appavoo, Ulrich Drepper, Richard Jones, Orran Krieger, Renato Mancuso, and Larry Woodman. 2019)
- "Unikraft: fast, specialized unikernels the easy way"
- https://wiki.linuxfoundation.org/_media/realtime/events/rt-summit2017/unikernelized-real-time-linux-and-iot_tiejun-chen.pdf
- NanoVMs in depth
- Jaradat, W., Dearle, A. and Lewis, J. Unikernel support for the deployment of light-weight, self-contained, and latency avoiding services.
- UniLinux -- Unikernelized Linux - Tiejun Chen- FOSSASIA 2018
- LISA18 - Unikraft: Unikernels Made Easy (2018)
- Unikernel Technologies - Michael Bright (2017)
- Unikernels - Keep It Simple to the Bare Metal - Tomek Kalinowski (2017)
- Unikernels and Event-driven Serverless Platforms -- Madhuri Yechuri (2017)
- Unikernels and Docker: From Revolution to Evolution - Black Belt Track - Mindy Preston (2016)
- Unik: Unikernel Runtime for Kubernetes by Idit Levine, EMC (2016)
- Unikernels: the rise of the library hypervisor in MirageOS (2016)
- "Look ma, no OS! Unikernels and their applications" by Matt Bajor (2015)
- Unikernels: Who, What, Where, When, Why - Adam Wick, Galois (2014)