Simon Kuenzer

Running your own custom applications is one of the most important features that make unikernels fit for the cloud. As related work has shown, unikernels can achieve this by compiling or linking them (native) or by providing a binary-compatible interface (e.g., Linux system call ABI). Both modes have their pros and cons, and because specialization is our key concept for the Unikraft OSS project, we support both. In this talk, we will present our implementation design, the challenges that we solved, and the lessons that we learned. Additonally, we will show a demonstration with nginx running in both modes.

Unikraft is an open source Xen Project incubator under the auspices of the Linux Foundation. The Unikraft open source project is the basis for Unikraft GmbH, a company that aims to build the next generation of cloud with unikernels for production and enterprise use.

Unikernels are hard to debug? Unikernels cannot be easily administrated or monitored? While unikernels have the potential to revolutionize our infrastructures and take cloud computing into the next era, many worry that unikernels cannot be seamlessly integrated into today’s development and production workflows. At the Unikraft team, we are heavily working on addressing these concerns and changing the status quo. Although unikernels are monolithic bundles of only necessary kernel functions and an application, we follow the concept that everything is a (micro-)library. Users can pick and choose kernel functionality at build time. The same applies for monitoring and debugging: In this talk, we will give an overview of our current debugging and monitoring capabilities, and we will present our vision for how these pieces will enable a cloud-native experience. We will also give a deep dive into our GDB backend implementation with a live demo.

Unikraft is an open source Xen Project incubator under the auspices of the Linux Foundation. We are currently launching a start-up with the mission to provide Unikraft unikernels for production and enterprise use.

Cloud computing has revolutionized the way we think about IT infrastructure: Another web server? More database capacity? Resources for your artificial intelligence use case? Just spin-up another instance and you are good to go. While most cloud images (e.g., AMIs on Amazon EC2) are meant to run a single service (e.g., nginx), for convenience these tend to be built on top of general-purpose OSes and full distributions, often resulting in GB-sized images that sometimes only need to perform a simple task such as serving static web pages. One of the main contributing factors to this status quo is the myriad kernel inter-dependencies, rendering debloating of a Linux kernel image far from trivial. In this talk we will show results from a proof-of-concept deployment on Amazon EC2 using Unikraft, a fully modular library OS that makes it easy to remove unneeded components, and to optimize the remaining ones. On EC2, a Unikraft nginx image is able to outperform an nginx Debian image by 2x in terms of requests/sec when serving static content, all the while consuming 1/6 of the memory (we will show a brief Unikraft demo). Unikraft is an open source Xen Project incubator under the auspices of the Linux Foundation.

Although unikernels - images containing specialized OS primitives and libraries targeting a specific application - have shown impressive performance potential (e.g., fast I/O of 40 Gbps, fast instantiation in the millisecond range, minimal memory footprints of only KBs and a minimal trusted compute base), creating them has proven to be a complicated and time-consuming process. This is mostly because operating system components have to be individually specialized and developed for each target application and target platform.

In this talk we give an update on the Unikraft open source project. Unikraft is a toolkit for creating specialized unikernels and it aims to remove the need for time-consuming, expert work. In the past two years, the community has put a lot of effort into supporting OS functionality, drivers, and platforms, porting libraries, and providing tools to ease porting of existing applications. We will give an overview of all the exciting achievements and conclude with an outlook of recent project directions: binary compatibility (Linux ABI), support for a wide range of compiled and interpreted languages (e.g., web assembly, Go, Python, Ruby, etc.), enhanced safety features, and the ability to seamlessly produce images ready to run as extremely lean VMs, containers, or directly on bare metal. The aim is that Unikraft will represent a step forward towards wider adoption of unikernels beyond the research community.

We have spent quite a bit of our time over the last years developing unikernels – highly specialized kernels targeting specific applications. We have been originally interested in them for virtualized network functions because of their fantastic performance benefits: tiny memory footprints, boot times comparable to those of processes, and fast I/O performance, to name a few.

Despite the fact that this work and work from several others is proof of their potential, unikernels have yet to see massive adoption. One of the main showstoppers is development time: for instance, developing Minipython, a MicroPython unikernel, took the better part of 3 months to put together and test. ClickOS, a unikernel for NFV, was the result of a couple of years of work. What’s particularly bad about this development model besides the considerable time spent is that each unikernel was basically a “throwaway”: every time we wanted to create a new unikernel targeting a different application and a different platform, we would start more or less from scratch. This comes from the fact that each application has different OS dependencies and benefit from different optimizations and specializations of these layers.

Two years ago, we started Unikraft as an open source incubator project under the umbrella of the Xen Project and the Linux Foundation. Our goal is to build a common pool of decomposed OS functionalities, called libraries, where various Unikernel projects can share implementations and optimizations with others. The project provides Unikernel builders tools that help them to select needed libraries and configurations. Unikraft's build system quickly and automatically creates images tailored to the needs of their specific applications. The users can choose multiple target platforms (e.g., extremely lean VMs, containers, or directly as bare metal) without having to do additional work for each of them.

We are going to present the efforts and achievements done by the community in the last two years. We will also give an outlook of recent project directions: binary compatibility (Linux ABI), support for a wide range of compiled and interpreted languages (e.g., web assembly, Go, Python, Ruby, etc.), and enhanced safety and protection features. With a bit of left time, we will show a live demo to the audience.

Highly specialized Unikernels are still terrible to develop and maintain. Applications have to be ported manually to non-standard OSes before gaining from impressive benefits, like superb performance, great isolation, and a small trusted compute base. Unikernels can be instantiated in tens of milliseconds or less. They are tiny with low memory footprints of a few MBs or even KBs. They can achieve high network throughput of 10-40 Gb/s with a single CPU core and they enable running thousands of concurrent instances.

We are going to present the Xen Project/Linux Foundation's open source Unikraft project. Its high level goal is to provide an automated tool to build unikernels without requiring the time-consuming, expert work as today. In addition, Unikraft targets support for multiple "platforms": Xen, KVM, containers and bare-metal. Images are automatically produced for multiple of these platforms without requiring any additional time from users.

We have spent quite a bit of our time over the last years developing unikernels – highly specialized virtual machine images targeting specific applications. We have been particularly interested in them since because of their fantastic performance benefits: tiny memory footprints (hundreds of KBs or a few MBs), boot times comparable to those of processes, and small migration times, to name a few metrics.

Despite the fact that this work and work from several others is proof of their potential, unikernels have yet to see massive adoption. One of the main showstoppers is development time: for instance, developing Minipython [4], a MicroPython unikernel, took the better part of 3 months to put together and test. ClickOS [5], a unikernel for NFV, was the result of a couple of years of work. What’s particularly bad about this development model besides the considerable time spent is that each unikernel was basically a “throwaway”: every time we wanted to create a new unikernel targeting a different application, we would start more or less from scratch. This comes from the fact that each application has different OS dependencies and benefit from different optimizations and specializations of these layers.

One year ago, we started Unikraft as an open source incubator project under the umbrella of the Xen Project and the Linux Foundation. Our goal is to build a common pool of decomposed OS functionalities, called libraries, where various Unikernel projects can share implementations and optimizations with others. We started with initial and elementary pieces like schedulers, memory allocators, an VFS layer, network stacks and the pool is growing. The project provides Unikernel builders a menu where these libraries can be picked and configured. Unikraft's build system quickly and automatically creates images tailored to the needs of their specific applications. The users can choose multiple target platforms (e.g., Xen, KVM, containers, bare metal) without having to do additional work for each of them.

In this talk we introduce the concept of specialized Unikernels, give an overview of the Unikraft open source project, and show a live demo to the audience.

Unikernels have been shown to provide incredible performance benefits, including boot times of a few milliseconds, low CPU utilization, throughput in the range of 10-40 Gb/s and memory footprints of a few MBs or even KBs, to name but a few metrics. The clear downside is development time: it can take several months or longer to produce a working, optimized unikernel, and up until now, the process needed to be repeated for each target application. There was no shared research and development on the building and creation of unikernels.

In this presentation we will introduce Unikraft, a new, open source Xen Project sub-project under the auspices of the Linux Foundation that seeks to automate the development process for unikernels. Unikraft decomposes operating systems and libraries into elementary modules called libraries (e.g., schedulers, memory allocators, drivers, filesystems, network stacks, etc) and then allows users to quickly pick and choose, through a menu, which components to use when building a unikernel. Once done, Unikraft builds one image per target “platform” (e.g., Xen, KVM or Linux user-space), severely reducing unikernel development time. We will show a brief demo on how to use Unikraft, and cover the basics of the system including how to contribute to it.

We have spent quite a bit of our time over the last few years developing unikernels – specialized virtual machine images targeting specific applications. We have been particularly interested in them since because of their fantastic performance benefits: tiny memory footprints (hundreds of KBs or a few MBs), boot times comparable to those of processes, and small migration times, to name a few metrics.

Despite the fact that this work and work from several others is proof of their potential, unikernels have yet to see massive adoption. One of the main showstoppers is development time: for instance, developing Minipython [4], a MicroPython unikernel, took the better part of 3 months to put together and test. ClickOS [5], a unikernel for NFV, was the result of a couple of years of work. What’s particularly bad about this development model besides the considerable time spent is that each unikernel was basically a “throwaway”: every time we wanted to create a new unikernel targeting a different application, we would start more or less from scratch.

One thing we did do to try to re-use the work a bit more was to create a separate repo consisting of a “toolstack” that would contain functionality useful to multiple unikernels, mostly platform-independent versions of newlib and lwip (a C library and network stack intended for embedded systems).

That got us thinking that we should take that a (much bigger) step further: wouldn’t it be great to be able to very quickly choose, perhaps from a menu, the bits of functionality that we want for a unikernel, and to have a system automatically build all of these pieces together into a working image? It would also be great if we could choose multiple platforms (e.g., Xen, KVM, bare metal) without having to do additional work for each of them.

The result of that thought process is Unikraft. Unikraft decomposes operating systems into elementary pieces called libraries (e.g., schedulers, memory allocators, drivers, filesystems, network stacks, etc.) that users can then pick and choose from, using a menu, to quickly build images tailored to the needs of specific applications.