Cynically awaiting an open sourced internal google product dealing with unikernel management and scaling which is woefully complex, utilizes its own nomenclature for simple concepts like 'input' and 'output'. Becomes foundational to can-you-even-scale-bro job interviews. Appears on every bootcampers resume. Now each job posting requires 10 years of experience in it which is more or less organizing its nonsensical convoluted yaml files.
Conceptually I really like unikernels, but I don't think they have much purpose in the software world today.
A lot of companies aren't running their stuff on metal anymore, they're running on Kubernetes. It's what people know and are familiar with. How many people know unikernels? How do you even debug an app running on a unikernel? How do you convert a "legacy" app to be runnable on a unikernel?
There are already very stripped down Linux distributions out there for running apps on Kubernetes like Bottlerocket OS. This removes the majority of the attack surface that unikernels remove. And you get to keep the Linux ABI.
Unikernels may strip out a lot of bloat and attack surface, but they also introduce a lot of complexity of their own.
We are seeing an increasing trend towards On-prem/Cloud-prem/Co-los[0], mainly due to cost and reduced complexity. Inversely, most smaller companies (1-10 emp) who use hyperscalers do not use their metal offerings, because of cost. They wish to scale with demand which metal cannot provide. Using EKS and other similar services have the benefit of being familiar and elastic, but are in fact slow and soon become quite expensive[1].
This has been a goal of Unikraft for a long time, to make using unikernels simple and familiar to use (in fact, transparent). This is why we use OCI images as the root filesystem; why it's possible to start unikernels through Docker; why we have several types of Kubernetes integrations.
> How do you debug a running app?
For one, you can attach a gdb server and step through both application code and kernel code together. Secondly, at Unikraft at least, we are introducing a virtual shell that allows you to introspect the filesystem, main threads, see system stats, etc.
> Stripped down Linux distros reduces attack surface
This is may reduce the attack surface, but one bad-actor application can still take down the host and all the other containers since they are still process (software) isolated. With unikernels you get hardware-level isolation AND, interestingly, the performance thanks to the lack of strong syscall boundaries.
> Unikernels increase complexity
Give us a chance and try out one of our examples :-)
In fact gVisor is the opposite, it injects more guard instructions between the application and the kernel across the syscall layer in order to make stronger security guarantees. These additional guards slow the application even further by however long it takes to perform necessary permission checks.
It is not necessary to have such checks in a unikernel because the kernel inherently trusts the application because together they were constructed in the same pipeline. The hardware then protects the two together.
I was under the impression that containers/Kubernetes actually depend more on the kernel than virtualization as they run the containers by sharing the kernel? I may be misunderstanding it and need some HN knowledge power!
So the market for this is cloud providers? If so, I think it's failed. Amazon, Cloudflare, et al have already developed their own lightweight runtimes based on Firecracker/V8.
They might not be quite as light as unikernels, but within the same order of magnitude for sure, and I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible.
Why would it automatically fail just because others have ship their products first? It's always good when new ideas are tried and bring something new to the table. Never say never.
> I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible.
I have been following the news on Unikraft development for a few years now (since 2019 I think) and now fortunately am a beta tester on kraftcloud. I have seen their website and documentation transform from something that only linux kernel wizards would use to what it is now. So definitely they put some work on making sure unikraft is easy to adopt.
As the current state of kraftcloud, some apps can already be deployed by copy-pasting the config file (that usually consists of 4 or so lines), install the CLI and hit the deploy button. If you want to enable the scale-to-zero you only need to put -0 at the end of the deploy command. If your use cases not covered in their documentation asking their support or joining the discord is a good start if you don't want to deal directly with the "complexity" (which from my experience mainly consist of copy-pasting some .so files into the root folder).
Another unikernel yes, sorry about that! :) . Unikraft started back in 2017 initially as a research project, and has been a Linux Foundation OSS project since 2018.
While Unikraft OSS is used in different use cases, our primary target is cloud deployments. Unikraft has 3 key principles:
1. A fully modular OS -- so that we can specialize the resulting unikernels (VMs) as much as possible
2. Linux-API compatibility -- so that we don't break applications
3. Integration with Docker/Dockerfiles (and other tools) -- for ease of use
Unikraft powers kraft.cloud . You can see the platform's guides to get an idea of the apps/frameworks it supports: https://docs.kraft.cloud/guides/
The part that I don't understand about 'fully modular' unikernels, is that you can build a linux kernel with exactly what features you want, but no one does that, so why would they do this?
In fact this is not true with Linux. We did a study of this[0] and found that there are too many interdependencies between Linux kernel subsystems. The smallest, usable Linux kernel we test with sometimes is around 30MB.
In comparison, compiling NGINX together with Unikraft results in a kernel size of under 2MB. This means that there is 28MB of kernel we didn't need or want.
You can get an uncompressed Linux image (built with only virtio support, including SMP and networking) under 12MB; it's not 2, but also not 30MB.
This is without LTO, so you could probably get it lower.
At least I know from talking to Alex that they actually know what users and people playing with kernels like in his toolchain.
Kraftcloud is just them eating their own dogfood. In my opinion it's all about the toolchain(I mean not only) and these people understand that.
In my opinion Linux didn't win because it has the best design on every front. It won, because it had the easiest toolchain for someone like me with zero experience to just read a total after school and start building a kernel.
This is similar. Building is simple, configuring is simple, packaging is simple. It has the added bonus of having people behind it, that are ALSO good researchers.
I hope that at some point they will pay for a professional audit, but it's already awesome to see where they got.
Also what is the particular use case here? Why use it over one of the other kernels out there? I see a lot of 'safe' and 'modern' but nothing showing how it is better/worse than the competition. What are the trade offs here? What do you get with this kernel and what is missing?
The key difference between unikernels (and library OSes) vs. other kernels is that each kernel is different with a unikernel. Your application goes through a process of specialization, where you can decide exactly the necessary features (e.g. libraries, syscalls, memory allocation, scheduler, etc.) are necessary or desired for your application. Additionally, other kernels are typically multi-process whereas a unikernel is inherently single-process since it does not support syscalls like fork. (That said, at Unikraft, we are working on supporting fork, eta. late April).
Additionally, before Unikraft, one of the major trade-offs was developer time and effort to get your application into a unikernel. Since Unikraft has been actively developed for several years by ~100+ people, it has become much more stable, feature complete and easier to use; ultimately making unikernels easier to approach.
Today, in-addition to multi-process applications, the trade-off now really depends on your usecase and so selecting whether you wish to deploy your application as a unikernel or on top of a monolithic kernel or microkernel. For example, developer environments which require many subsystems, multiple programs, etc., where you can't know everything ahead-of-time, are still best suited for multi-user, monolithic kernels that can run most workloads.
Another thing to note is that unikernels are designed to be immutable and are often created in a CI/CD context. This means that they are single-purpose and if you wish to change them, you need to re-build (or re-package).
That's a giant stretch. Kraft is a surname. I assumed it was an April fools joke that Kraft the cheese company was making their own cloud (which would be hilarious).
I wonder whether we could get Kraft to sponsor us :) . Unikraft used to be called Unicraft but was changed to a "k" for name clash reasons. Agree that names are hard.
I caught on to that immediately. My statement was meant to mean that it would so so unlikely to indicate the Raft protocol, that it’s more likely to have been a reference to these other things. It is not a reference to those things, but it even less of a reference to Raft.
The parent is downvoted because the original comment contained some stretch logic talking about possible confusion with Raft consensus protocol due to naming similarities, the current comment is after the ninja edit.
