Unikernels are constructed by combining application code with only the operating system components necessary for that code to run. The result is a highly specialized, single-purpose application which can be deployed directly to the cloud or onto IoT-like devices. Unikernels reduce software complexity by only including code that is required, resulting in portable applications with much smaller footprints and fast boot times. By combining the familiar tooling and portability of Docker with the efficiency and specialization of next-generation unikernel technology, organizations have a flexible platform to build, ship and run distributed applications without being restricted to a particular infrastructure. Because workloads that reach the data center today are on a spectrum from physical machine to container to hypervisor, only the Docker platform can further widen the scope and provide more flexibility for orchestrating hybrid applications. Watch the video from Docker Online Meetup #31: https://blog.docker.com/2016/01/docker-online-meetup-unikernels/

1. Unikernels and Docker
Amir Chaudhry
Richard Mortier
Martin Lucina

2. Overview
Introduction to unikernels
Unikernel workflow
Unikernels and Docker
Demo!
Q&A

3. Introduction to unikernels

4. Traditional Approach
Operating systems have a lot of code
Linux: over 25 million lines of code
Debian 5.0: 65 million lines of code
OS X 10.4: 85 million lines of code

5. Traditional Approach

6. Traditional Approach

7. Traditional Approach
Leads to problems

8. Traditional Approach
Leads to problems
Unnecessary system complexity with large
amounts of (now) unused code
Lack of portability since applications are
deeply intertwined with system APIs

9. Unnecessary system complexity
Building applications for a current OS involves:
- Forcing a choice of distribution and version
- Managing ad hoc application configuration
- Dealing with wider system configuration details,
e.g., firewalls
Current operating systems are designed for many
users to run multiple applications, simultaneously.
Modern architecture patterns, like single-purpose
microservices, don’t require such features.

10. Traditional systems programming meant
building services in one environment.
However, a modern programmer deals with
diverse targets:
Lack of portability

11. Lack of portability
● Cloud services with unpredictable traffic
spikes and failures
● Smartphone programming on ARM/x86
with power budgets
● JavaScript user interfaces with
asynchronous web clients
● Internet of Things devices that have little
ARM M0 processors
● Kernel modules to extend operating
system functionality
Code reuse is difficult across environments

12. Traditional Approach - Summary
Applications currently rely on a software stack of 100M+ lines of code.
Code reuse is difficult between environments, especially new contexts.
Difficult to get the maximum benefit of modern architecture patterns.
It's great that we can engineer software to make all this work…
but can we do better?

13. Can we do better? How?
We need to disentangle applications from the operating system:
Break up operating system functionality into modular libraries
Link only the system functionality your application needs
Target alternative platforms from a single codebase

14. Unikernels, unikernels, unikernels!
Concepts derived from library OS technology from the 1990s
- Make OS components available as a collection of libraries
- Link application code together with system libraries at build time
- Only use the libraries specifically required for the application
- Produce a single process, single address space image
- Retarget that image simply by switching out system libraries during build

15. Reduced complexity:
Static linking of only required libraries: removes unnecessary services.
Increased speed:
Can boot inside a TCP connection setup or packet RTT.
Fewer layers means lower latency and more predictable performance.
Efficient resource usage:
e.g. a typical stateless MirageOS app is ~10MB of RAM.
e.g. can create a MirageOS DNS server that comes in at ~200kB.
Benefits

16. Unikernels facilitate new design patterns:
Microservices
- Small, self-contained, single-purpose applications
Immutable Infrastructure
- Can statically link data into application: reduces dependency on external components
- Store outputs in Git: introducing new models for update, upgrade, triage
- Can be sealed: can even enable hardware memory-protection so image is really immutable
Benefits

17. Unikernel workflow

18. 1. Build an application as you normally would on your dev machine
● Use libraries for OS components
● Avoid dependencies on traditional host OS
2. Test and measure
● Can use familiar tools
3. Build as a unikernel
● Change system libraries to retarget the unikernel
4. Deploy
Familiar development cycle...

19. All the familiar software development tools are available, including:
- Continuous Integration systems
- gdb
- profilers
- linters
- dtrace
Interesting side-effect of libraries: Everything is in userspace so all the usual tools
apply. No boundary between userspace and kernel means everything is just
function calls.
… using familiar tools

20. Lots of open source software!
Projects make different trade offs
- Clean slate involving bespoke protocol
implementations (MirageOS, HaLVM)
- Code reuse by using rump kernels and
components from battle-tested NetBSD
(Rumprun unikernel)
So we see the need for unikernels
and the range of activity
Many implementations!

21. Traditional approaches give limited benefits.
Unikernels offer a new way to create and deploy applications.
There are barriers to adoption:
- Developers must adapt to new and varied toolchains to access this tech
- Multiple projects means multiple toolchains
- Deployments are not always straightforward
Must make unikernels more accessible to developers and easier to deploy.
Enter Docker!
Unikernels are a new technology!

22. Unikernels and Docker

23. Docker aims to make it easy to Build, Ship, Run software
- Built a well known and widely used toolchain and ecosystem
- Traditionally Linux Containers but can also be for Windows containers
Unikernels need more tooling. Docker has tooling and broad ecosystem. Clearly
the two go together!
Can increase unikernel adoption by bringing them into the Docker ecosystem
Docker helps you Build, Ship, Run software

24. - Use Docker to build a unikernel microservice, and run a cluster of them to
drive a web application with database, web and PHP code
- Build system is wrapped in an easy-to-use Dockerfile
- Each microservice is turned into a specialised unikernel
- Each unikernel runs in its own KVM virtual machine with hardware protection
Demo: Docker and Unikernels

25. Docker now manages the unikernels just like Linux containers
This includes networking!
Turns unikernels into an awesome backend for a Docker deployment, reusing
orchestration and management
Demo: Docker and Unikernels

26. Demo!

27. The unikernels that ran the LAMP stack were:
- Small, secure, OS images with only the functionality required
- 2—6MB images are typical for the full kernel+app
Low-latency boot times of <1s are comparable to Linux containers
What just happened?

28. Perfect for specialised microservices
that perform one task (Web, DB)
- Unikernels and containers sit on a
continuum
- Both can be run alongside each
other
Unikernels

29. Unikernels are a new way to develop apps (libraries all the way down)
This reduces complexity and improves portability
Unikernels can be managed by Docker!
Image management, networking and storage configuration all provided by Docker
Early days and more work to come!
Summary

30. Q&A
Visit devel.unikernel.org for more info