Unikernels have been predicted to be the successor to container technology for a few years now because of their purported speed, security, and size but adoption has been lagging – why?
Well, before answering that question let’s define what a unikernel is and what exactly it does for you. A unikernel is a single process system specifically designed to run one and only one application as a virtual machine typically in the cloud or in the data center. Unikernels typically are much faster than a Linux VM or a docker container.
Some researchers from NEC are reporting booting them in 5ms which is only slightly slower than a fork and multiple orders of magnitude than booting a container. They also run faster at runtime because they aren’t fighting the system for server resources. There is actually a fairly high tax for context switching each process in a monolithic operating system like Linux. Microsoft has measured this to be in the 30% range. That’s a lot of waste!
Because of their size if you happen to have your own servers you can run thousands of them per machine. Lastly, they are much more secure than a typical Ubuntu box as they don’t expose a shell, they don’t have the concept of users and their attack surface is much less.
It’s important to drill down on the fact that being a single process system many exploits simply stop working because most exploits are predicated on the fact that you want to eventually run other programs like saying a crypto-miner or mysqldump or something like that after exploiting the one you are attacking. The single process nature of these systems completely stops that.
All of this is good and all but as the below diagram indicates the most important thing about unikernels is that developers are already deploying their software like a unikernel even though they are using Linux. If you’re an engineer at a medium-sized software company chances are you don’t have just one or two servers.
You have thousands of servers. You see the virtual machine has become the process. IPC between processes now goes across the network through microservices. More importantly, the notion of Unix users has been thrown completely out the window and abstracted into a higher level namely AWS/GCE IAM.
So if they are so great why aren’t they spread everywhere yet?
There are a few reasons but the main one is that they have remained largely inaccessible to the average developer. Traditionally if you wanted to hack around with unikernels you needed to be a low-level c programmer fluent in operating system internals and very comfortable tweaking native libraries or writing patches for things like MySQL.
This was a very large barrier to entry for most people to the extent that they’d rather stuff forks in their eyes rather than try to boot a hello world in their favorite language.
OPS changes that. OPS allows anyone – even non-developers to instantly build and run unikernels on their laptop or in the cloud. Sound cool? Let’s get started!
First download OPS. One shot binary downloads are available via this command:
If you happen to code Go you can also build from source. OPS is written in Go but Nanos the kernel is obviously written in C.
Now paste this into hello.js:
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8083, "0.0.0.0");
console.log('Server running at http://127.0.0.1:8083/');
Now you can run it via a node package we’ve created.
What’s interesting here is that while we specified a package you don’t actually need to if you want more fine-grain control. A package in OPS is composed of the actual binary we wish to run – in this case, the node.js binary, the libraries it is linked to and some common settings that one would typically put into a config.json outside of a package.
This will pop a small HTTP server on port 8083 which you can verify:
Wow – you just ran your first javascript unikernel! It’s almost like you just made your own little operating system out of your app.
This is a simple hello world application but OPS is much more powerful than that. You can actually run raw elf binaries with OPS as well and the config.json manifest allows you to put whatever you want on the filesystem, populate it with environment variables and such.
What I find most interesting about unikernels is the new forms of they open up access too. Their security and performance benefits allow entirely new forms of computing to flourish that were simply not possible with regular Linux vms or containers.
OPS main goal is to democratize access to unikernels so every developer can use them today – what will you build?
