Magnus Skjegstad

A unikernel experiment: A VM for every URL

I recently wrote a DNS server that can boot unikernels on demand called Jitsu. The following diagram shows a simplified version of how Jitsu works. The client sends a DNS query to a DNS server (Jitsu). The DNS server starts a unikernel and sends a DNS response back to the client while the unikernel is booting. When the client receives the DNS response it opens a TCP connection to the unikernel, which now has completed booting and is ready to respond to the TCP connection.

The unikernels are built using MirageOS, a library operating system that allows applications to be compiled directly to small Xen VMs. These unikernels only include the operating system components the application needs - nothing else is added. This results in very small VMs with low resource requirements that boot quickly.

Now, what if I wanted to use Jitsu to boot my unikernel website when someone accesses it? My website is fairly low traffic, so this could potentially save me some resource use and hosting costs. Unfortunately, there are always a few requests per hour to some of the more popular sections, which likely would make my unikernel run most of the time. But what if I could split my unikernel into even smaller unikernels? What if I went to an extreme and had one unikernel per URL? Then I could only boot unikernels for the URLs that are being used and they would only need to know how to serve a single page. This could also have a number of benefits, such as the ability to spin up multiple unikernels for an extremely popular web page and use DNS to direct clients to the unikernel that is closest to them — while keeping the rest of the site inactive (let's ignore web crawlers for now). If I had dynamic sections of my website there could also be security benefits: Every dynamic page would run as a separate VM. An attack on a single page would not have to bring down the rest of the site nor reveal any data stored in other unikernels.

AR.Drone test flight #1

I bought an AR.Drone some time ago, but I haven't been able to do any testing with it until now. Yesterday we did a short experiment to see if it could lift the mobile phones we used for the chat experiment.

Experimenting with distributed chat

In this experiment we use a remote controlled airplane and an Android phone to carry data between two computers. The idea is that in environments where you are without a network connection you could still get a working network environment with the help of mobile nodes picking up messages in one area and delivering them in another. A typical scenario is for example rescue operations, where people may move in and out of a difficult to access rescue area and carry messages with them on their mobile phones. Although we focus on chat in this experiment, the real data carried could be anything you could store in a file, e.g. medical data from patients, information gathered from sensors in the environment, images etc.