Unikernels

Chapter 5. Limits of the Solution

All technologies have their limits, and unikernels are no different. This section will discuss some of the things to keep in mind when you’re considering a unikernel solution.

Unikernels Are Not a Panacea

For all their advantages, unikernels are not a panacea. In a post-unikernel-enabled cloud, there will be many non-unikernel workloads. Undoubtedly, there will be complex stacks that simply won’t lend themselves to implementation as a unikernel. But that’s fine—by turning some workloads into unikernels, we now have all the more resources to give to the complex old-school stacks. When we reduce the footprint of unikernel-capable workloads, we make plenty of room for beefier tasks.

Practical Limitations Exist

The keep-it-simple concept that enables unikernels necessarily comes at a price. Not every solution will be suitable for implementation as a unikernel. Others may need some architectural modification to fit within the unikernel concept. And still others will work with no code modifications whatsoever.

So what are the key limitations in unikernel implementations?

Single Process (but Multiple Threads)

For the simple unikernel stack to work, there is no room for the complexity of multiple process handling. Once you have multiple processes, the overhead rises dramatically.

Multiple processes require process management. There has to be a way to start a process, stop a process, inspect the status of a process, kill a misbehaving process, and ...