JavaScript Unikernal

Build and Run Your First Javascript Unikernel

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 is 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.

JavaScript Unikernal

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.

JavaScript Unikernal

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:

curl https://ops.city/get.sh -sSfL | sh

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:

var http = require('http');
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.

ops load node_v11.15.0 -p 8083 -f -n -a hello.js

JavaScript Unikernal

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:

curl -XGET http://127.0.0.1:8083/

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?

Shahid

Founder of Codeforgeek. Technologist. Published Author. Engineer. Content Creator. Teaching Everything I learn!

Related Posts

2 Comments

  1. I would like to know how Ops compares to an Scratch Docker container. Both doesn’t have a shell or any other tooling in the VM, which makes the app more secure. I would also like to know how it compares in performance? Do you know anything about this?

    1. Hey Pieter,

      Good questions. Any container inherently runs Linux – even the ones on Windows. Containers have numerous security problems to the extent that they are being kicked out of various companies by CISOs because of them. The end artifact of a unikernel is a virtual machine so it’s considered the ‘gold standard’ for isolation, side channel attacks aside. For instance the entire public cloud including AWS and Google Cloud are entirely built on virtual machines – not containers. There’s a reason for that.

      Unikernels are single process by nature so they don’t even have the appropriate system calls to run other programs. Moreover that means you can’t ssh into them and they don’t have the concept of a user. Container based systems have to go to lengths to implement image scanning, syscall whitelisting, etc. and still have trouble.

      As for performance there are numerous papers from NEC, IBM, VMWare, and others showing their fast boot time (some can boot in 5-10ms) and faster run time. Cloudius Systems for instance was achieving 20% better performance with numerous databases.

Leave a Reply to Pieter Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.