1. 11
  1.  

  2. 6

    Unikernels are not a new idea. On Exokernel and Nemesis, they were called ‘processes’. Xen is a direct descendant of Nemesis, so it’s not very surprising that a lot of the unikernel ideas started there. It basically boils down to two things:

    • The kernel should be as small as possible and provide processes with abstractions that closely match the hardware (CPUs, memory, block devices, NICs, frame buffers [okay, this one is a bit dated]).
    • The program should use libraries that provide any higher-level abstractions that they need.

    Everything running on a modern hypervisor is equivalent to an Exokernel / Nemesis process, which is now rebranded as a unikernel. If you’re using Linux / Windows / *BSD, then the library that you’re bringing along to provide high-level abstractions is providing a rich filesystem (typically, more than one), nested process isolation, multiple users, a generic network stack, and so on. This is a really crappy way of building a program.

    1. 1

      Well, at least for this interpretation we don’t want users, multiple processes and such. Part of the argument here is that in 2021 it doesn’t make a ton of sense to be shoe-horning an extra layer of Linux on top of an already existing layer (the cloud) when you are managing thousand of vms.

      1. 1

        Well, at least for this interpretation we don’t want users, multiple processes and such.

        I’d slightly reframe that as: we shouldn’t pay the complexity cost of users, multiple processes, and such unless we need them for our program.

        Part of the argument here is that in 2021 it doesn’t make a ton of sense to be shoe-horning an extra layer of Linux on top of an already existing layer (the cloud) when you are managing thousand of vms.

        It’s also that the abstractions are just plain wrong. A modern web app does want users but it doesn’t want UNIX users it wants OAuth users with JWTs not 16-bit UIDs. If does want persistent storage but in the form of a local filesystem but instead in the form of a database or a distributed object store. It definitely does want network access, but it could have a network stack that’s aggressively optimised for its use case (which may be TCP-only with TLS offload, or UDP+QUIC only, for example and may be optimised for connections whose lifetime follows a predictable distribution and so on). The only IPC it’s likely to want is networked IPC because other components in the same distributed system may not be on the same physical machine (though it would like fast one-copy networking if they are). It wants a VCPU abstraction that maps to the available parallelism so that the language runtime / middleware can scale the available concurrency to something efficient, it doesn’t want a scheduler that is unaware of both the VCPU scheduling and the distribution of work (or anything else workload-specific) sitting between it and the hardware.