[bluepizza]

Because they are a silly idea. Why would you spin up a full kernel to run a single application on top of a hypervisor that is balancing resources?

Operating systems already solve this problem relatively well, without the overhead, via processes and containers.

[jasode]

>Why would you spin up a full kernel to run a single application

You're misunderstanding the levels of abstraction probably because the word "kernel" within "unikernel" is throwing you off. The idea is to use a partial kernel (only the minimum services one needs). The so-called "kernel" is a library of code where you compile the minimum bits into the single-process image.

>Operating systems already solve this problem relatively well, without the overhead, via processes

A full operating system like Linux is expending extra overhead to schedule/prioritize/monitor processes (plural) -- because Linux is designed to be more general purpose and open-ended than a specialized unikernel. In contrast, a unikernel with only 1 singular process (say a specialized db engine) doesn't need to expend extra cpu on processe(s) scheduling.

All that said, it doesn't seem like unikernels have enough advantages to attract widespread adoption like containers.

[hypertele-Xii]

So it's less of an operating system and more of a single app that runs on metal?

[packetlost]

Yes. Think of it like depending on a small kernel directly in your build step. So your application gets compiled with everything (including OS interface) that it needs and nothing more. The result is a bootable image that is only capable of running your app.

I think the value isn't in the containerization vs unikernel comparison. If you're using containerization you've accepted certain security risks. Where unikernels have a lot of potential IMO is in high security environments where the security risks of containerization are not acceptable.

[chakkepolja]

Another way to describe it is OS-functionality-as-library.

[eyberg]

This is very very common misconception. Just yesterday I was helping someone out with a networking issue they were having on AWS stemming from this concept.

Coming from k8s/firecracker it is common to think that you need to orchestrate your unikernels with a framework of some kind. In our case (Nanos/OPS) a lot of people think that means spinning up an ec2 linux, sshing in and using 'ops run' on top of that but that is never suggested for prod deploys. Instead we suggest doing an 'image create' followed by an 'instance create'.

What does this mean? Essentially every time you hit the deploy button a new ami is made and a brand new ec2 instance spins up without any linux inside. So instead of adding layers through containers we actually subtract them. That means you can still configure the instance to your hearts content but you don't have to manage it - the cloud does for you and this is a huge win for many teams that don't want to deal with all the ops/SRE work that something like k8s brings (or even normal vanilla linux does).

It is important to realize that containers extract heavy performance penalties when running on top of existing infrastructure (like the cloud) since they duplicate storage and networking layers. They also have severe security issues - the shared kernel being the main one.

[igorkraw]

What is the functional difference of os=>hypervisor=>unikernel vm vs. os=>capabilities and pledges or containers? I would get if we use a unikernel approach running on bare metal for high security, specialised applications but this doesn't seem to exist?

[eyberg]

The difference is that the vast majority of people are deploying to the cloud so they are already deploying to a hypervisor. Every single cloud is built on top of virtualization. AWS used to use Xen, now they use KVM. Google Cloud is entirely built on KVM. Azure uses Hyper-V. The cloud is just an API for virtualization.

Instead of AWS (hypervisor) => linux => k8s => containers unikernels advocate for AWS (hypervisor) => unikernel and that makes them run much faster in general (we've clocked upwards of 300% req/sec for go/rust webservers on AWS for instance) and a lot safer.

[einpoklum]

> Why would you spin up a full kernel to run a single application on top of a hypervisor that is balancing resources?

What if your application involves multiple processes and threads?

[eyberg]

Nanos supports multiple threads but not multiple processes so you can have as much performance as you have underlying hardware but if you are using something like an interpreted language where is normal to spin up X app-workers behind a reverse proxy those become vms. (I should point out that those languages are single-thread/single-process to begin with.)

[Brian_K_White]

dude we get it

How many more comments will we read yet another copy of a nanos sales pitch?

The post is about unikernels, so, obviously every single comment will say something about them.