The scope of "everything that is needed to run" is a lot higher than might appear and since it is common code that is applicable to every app that would be deployed it is packaged as a 'kernel'. Something has to talk to the network, to the disk, keep track of time, etc. You might be surprised at how much code is involved in merely writing a byte to disk, efficiently and in a manner that a random webapp might use.

One very common misconception about unikernels is that they don't have kernels which every single implementation out there has one - it just might be smaller or less-featured than others.

So, at least in our view, it's not about having a 'small' kernel it is more about the architecture.

You can have libraries that can implement device driver functionality and talk directly to devices. Actually there are some (DPDK - Data Plane Development Kit and SPDK - Storage Performance Development Kit, for example).

> The scope of "everything that is needed to run" is a lot higher than might appear

Having written one algotrading framework with full kernel bypass which required me to account for every single piece of kernel functionality in use by the application (mostly to eliminate its use) I actually think it is the opposite. Most applications do not need a lot from the kernel to function and what they are using could be supplied as library.

Main reasons to have kernel -- protect shared resources and impose security constraints -- are not present when you intend to only have one application in the system.

Whether code is packaged a a library or inside a base kernel is definitely open to interpretation/design. We, for instance have the concept of a 'klib' which is code we don't want packaged in the base kernel but is optional and can be included at build-time. For instance deploying to Azure requires a cloud-init call to check-in to the meta-data server to tell it the instance has booted - not something you want to put inside every image if you are only deploying to say Google Cloud. Likewise, we have another klib that provides APM functionality but checks-in to a proprietary server so clearly not everyone wants that inside their image either.

However, there is a lot more than just networking/storage drivers and some of it is very common code. Page table management for instance. Do you have 2,3,4 page table levels? How do you allocate memory to the app? IOAPIC vs PIC? Do you support calls the way GLIBC wants? RTC vs TSC vs PIT? I'm not saying any of these can't be librarized but they are most definitely not choices I would expose to the vast majority of end-users to choose at build-time for.

This is the approach of IncludeOS. You include some headers and a library, compile and you can launch your application as a VM.

There are advantages to an approach like Nanos or OSv in that development is easier and you have better compatibility.

You mean, run an 'application' on a 'server'. Maybe we should call it.. an application server.

And have it 'operate' it directly on hardware with only a minimal 'system' layer for common operations.

I feel old.