Docker is preparing to merge containers with an entirely different way to package applications: Unikernels.
To accomplish this, Docker has acquired Cambridge, U.K.-based startup Unikernel Systems, which has long been involved in this work. The plan is to use the Docker workflow to create minimal, built-on-demand operating systems that contain enough functionality to run a specific application and can run on anything from tiny IoT-style devices to data center servers.
"By combining the familiar tooling and portability of Docker with the efficiency and specialization of next-generation unikernel technology," reads Docker's press release, "organizations have a flexible platform to build, ship, and run distributed applications without being restricted to a particular infrastructure."
The less, the better
The idea behind unikernels is simple: Take an application, look at the OS calls it makes, then compile the app and only the parts of the OS that it needs into a single, unified kernel.
Unikernels aren't easy to assemble, but the resulting binary image is tiny compared to the size of packaging the app with the whole OS. Also, because there are fewer moving parts within the unikernel, there's less for an attacker to target -- and fewer things that can go wrong.
The unikernel concept has been around for some time, in the same way containers existed long before Docker popularized them. Most recently, the Xen Project (some members of which are now Unikernel employees) created the Xen Mirage unikernel system, with a custom application and OS stack written in the OCaml language. IncludeOS, another recent unikernel project, treats the OS's services as libraries that can be included within a C++ application.
Courtesy Docker Unikernels compile application code along with only the parts of the operating system that are required to run that application. The result is a single, fast-booting binary with a far smaller footprint (and attack surface).
A simpler way to build
How does Docker plan to make use of this idea? The short answer: It employs the existing Docker toolset to make it easier to package applications as unikernels on any platform that already supports Docker.
David Messina, VP of marketing for Docker, said this approach would "democratize" the unikernel world. In his view, building unikernels with Docker's common tooling and workflow would "make [unikernels] accessible to the hundreds of companies and thousands of organizations that are building things on Docker."
The workflow, as described by Anil Madhavapeddy, CTO of Unikernel Systems, involves a container that takes in an application and a configuration file, then builds the unikernel without the need for developer intervention. The details of the build are specific to the programming language in use, so an application written in C would have different sets of dependencies versus apps written in Java or OCaml. A big part of the work being done right now is to unify the workflow as much as possible, allowing for, say, performing x86 and ARM compilation in the same pipeline.
The next step
Madhavapeddy contrasted the approach Docker is going to take with the "expensive, handcrafted" manner in which existing unikernel systems (such as NetApp's OnTap and Cisco's IOS) were built.
"We've been making sure that style of specialization is available," he said, emphasizing that developers would also be able to build low-level components with the high-level APIs they use right now. "Unikernels have a lot of well-established building blocks, but they've been [historically] hard to put together."
Docker's proposal is the next step after the "just enough OS to run containers" concepts propagated by the likes of CoreOS. But the unikernel approach is unlikely to displace containers entirely, for the same reasons containers haven't totally displaced VMs.
There's little question that a great range of possibilities can be unlocked if unikernels can be built with only modestly more effort than would be needed to create a containerized app. It has obvious benefits, like allowing for higher app density on a server. But it also means the microservices application model Docker helped refine could be applied to contexts where it wasn't previously practical, such as in a resource-constrained client-side environment (read: IoT devices).