Unikernels as an operational model of application delivery have been around for several years. A fixed purpose os/image that contains only what a service or application needs to run and nothing more has its advantages. Although similar to containers, unikernels are discreet in that they share nothing with another application or service, not even the OS kernel itself. Although they typically run as VMs, they have a very small internal footprint compared to say, a typical Linux VM. Only the absolute minimum in terms of OS kernel and other binaries or files are included in a unikernel which results in extremely fast loading and response times compared to a typical VM or container. Application instantiation and response times are limited to only the disk and network they are using.
Along with the presumed performance advantages of unikernels comes betters security due the architecture. Due to the small codebase, unikernels have a much smaller attack surface than a general purpose operating system. The lack of a shell means an attacker would need to resort to using machine code as an attack vector, which is far more difficult. Likewise the fact that unikernels are immutable means that even if an attacker manages to make any changes to the image, they will be lost when it is redeployed.
Barriers to Adoption
Given all the advantages inherit in unikernels, one would expect them to be widely used in enterprise applications and be poised takeover containers and/or VMs in terms of deployment numbers. Up until now that has not been the case, but why? Well it turns out that unikernels are actually quite difficult to deploy and also very difficult to manage at scale. The barrier to entry is essentially that one needs to have the knowledge and experience kernel developer to effectively manage unikernels.
Even for a seasoned developer this can be a daunting task, much less an operations professional who is less focused on building applications than on effectively monitoring, maintaining, and scaling an application with which they have been entrusted. So despite the many advantages of running an application or service in a unikernel, many enterprises have been hesitant to adopt them due to the steep learning curve.
A New Approach
To bridge this gap NanoVMs, a leader in the unikernel space, has released their open source Ops tool. Ops creates a wrapper around QEMU and KVM that allows developers to load an ELF binary into a Nanos unikernel, the unikernel that is developed and maintained by NanoVMs. With this release NanoVMs expects unikernels to become more accessible to the developer community in general. Additionally NanoVMs will make certain prebuilt packages available for things like databases and web servers, further removing the barrier to entry for deploying a unikernel based application.
With the release of Ops and the coinciding availability of prebuilt packages, NanoVMs has quickly taken unikernels from a difficult and geeky application deployment model to something that is primed for enterprise adoption. Being able to build, run, and test a unikernel simply by executing a single command on a laptop and subsequently deploy the application on the public or private cloud of choice will be incredibly empowering for enterprise customers seeking the performance and security that unikernels can provide.
Ken’s Conclusion
I remember first hearing about unikernels years ago when VMs were old news, containers were the new hot tech, and very few people had yet heard of Kubernetes. They were an exciting new technology that held promise but their future was unclear. The idea of running as minimal an image as possible to provide superior performance and security for applications seemed like a no brainer. As reality set in and the difficulty of building, deploying, and maintaining unikernels became apparent I began to hear less about the technology. With the release of Ops by NanoVMs we could likely see renewed enthusiasm for the technology and more widespread adoption.
