What is a 'unikernel'?

Whereas for unikernels, it's the opposite

> Unikernels leverage the advantages of virtualisation to create an operating system that's as specialised and optimised as possible.

It makes no sense to craft a hyper efficient kernel and then run Ruby on it. If your requirements are such that Linux is too slow, you are probably an HFT. Or Google.

There are pros and cons to each: a container lets you run other things on the same kernel, and introspect the running process (as well as do interception of things like sysdig does.) However, root-on-container generally means root-on-all-containers. So we use VMs to host containers in.

x86 is much smaller in terms of instruction set to a Linux kernel, there are historically fewer vulnerabilities, many fewer LoC, etc. The unikernel compiles your OS and libs together, meaning you can share a hypervisor - which is good for security. You lose some of the convenience of management of containers in order to get this.

Containers, VMs and Unikernels all have different characteristics and philosophies, if one fits all your needs there is no need to make it more complicated by introducing another type. But if you need something specific, they are there.

Heroku was the first to cross it, and they do a bang-up job with Rails apps, but ever since it came out there has been this sort of question hanging in the air of "how does this generalize?"

A VM on something like Amazon EC2 was the best we could do at that time. It certainly generalizes, but you have to do quite a lot of sysadmin work to keep an app running healthily. Docker was an improvement on that, taking away some underlying system work. But then losing the security benefits of VMs and still, in the end, requiring a bunch of systemsy stuff.

Of course Heroku kept firing with its buildpacks supporting lots of platforms and a host of infrastructure provided as a service. But that doesn't really provide all of the control application developers need. You're sort of at the mercy of what infrastructure there's a market for, at market prices.

So what's happening is both sides are sort of pressing in to the middle... On the docker side trying to build general-purpose containers that can run on a shared foundation of rock solid system images, and on the IaaS side trying to do as much as possible over a network connection.

We will eventually meet in the middle, with a set of secure, well-defined interfaces between an application and the infrastructure it relies on, which is robust enough to handle the vast majority of software.

Then again, if you squint your eyes that's kind of what we already have. We're just slowly decreasing the surface area of those interfaces and increasing their security. What you're feeling is the pain of that surface area being still pretty big and the job of surveying daunting. Luckily you don't need to map the whole thing, just know enough to make good decisions this week.

And honestly, I think for most people, focusing on how to build more human-relevant software is going to be way more helpful to your career than learning about the successor to Docker. But that's just some unsolicited career advice. :)

I tend to think of unikernels as having to 'front-load' more of the work. That's why you can treat the end artefact as almost disposable.

With a traditional stack, it may be easier to set up, but you're then committing to acting as caretaker for the code that runs on that machine, inc. patches, upgrades, version constraints, etc. There's probably more work there over the long term.

This is kind of where the distinction of 'cattle vs pets' comes from.

Quicksort and universal hash tables use randomization to avoid problems that arise with pathological sets of data, and so their performance can only be given on average.

If even simple CS primitives have such trade offs, then those are certainly going to propagate up the complexity tree as we engineer solutions on top of them.

In general, it's probably best to just know that these things exist and what their strengths and weaknesses are (they will almost certainly always have both) so that you can pick the right tools for the job at hand.

It's a fairly different philosophy—I don't think anyone really cares about the performance aspect of it (those people care more about getting zero-copy low-level IO in userland while still reaping the "control-plane" benefits of having an OS, using e.g. Snabb Switch.)

It's more like the philosophy behind Erlang releases or black-box "appliance" VMs. Which is, basically, that you don't maintain "the OS" as a thing separate from your app; you just maintain "your app", and any bits of OS are basically part of the vendored deps of each successive app release.

Seperate VMs would as well, but it's not really feasible to run a full Windows Server for each customer.

Wish modern systems were designed and implemented with even half the skill that VMS, etc were. I've never gotten to experience an OS reliable enough that I temporarily forgot reboot command. Desktop Linux will have to do. ;)

CVE-2015-3456 was raised in April which had a privilege escalation due to a floppy driver controller, and caused widespread reboots and replacements of images in the Amazon cloud:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3456

It has nothing to do with bytecode per se.

It allows a JVM to run bare-metal, there are plenty of them already in the embedded world.

For example J9 from IBM.

Thanks

OSv is a bit unusual architecturally, it is almost a very small OS that runs applications in a single address space. It is perhaps a hybrid architecture.

2) specialization. AFAIK the the concept of a library OS is from a time when single purpose computing was not on the agenda. We could argue a lot about the different ways of multiplexing and isolating different workloads and how maybe privilege levels were meant to solve the same problem as hardware virtualization but the spirit of unikernels (and library OSs) is to use language and program against an API that specializes to whatever ABI your target happens to be. The name unikernel is used more in the context of specialized applications in the sense of what a UNIX process is supposed to be (do one thing) but I'd say the important aspect is still the use of language technology which then enables specialized code.

I'm not too familiar with OSv but I think the goal is to provide a runtime for off the shelf java applications. It should be possible to fuse an application with just the needed parts of libc and drivers, though.

The client application might use a library dependent on, say, a high-frequency clock. Therefor, during the build of the application, the specific capability is build into the kernel. Synchronisation and sanity checks of this high-frequency clock runs only when this specific image (or unikernel) is loaded.

It's a pretty neat idea and fits well in the global trend of dependency inversion. It also highlights the gaping architectural hole in the current container (docker) offerings: by using a base-image, you specifically ask for everything that is necessary for: networking, IPC, process management, scheduling, file system management, package management, printing, the whole POSIX interface etc. etc. This in turn creates a huge attack surface from a security perspective and makes maintenance and quality control much harder.

My sole question with unikernels is: doesn't this just move resource management (scheduling) upwards and security (access to resources) downwards? Or in other words, are we not creating two extra rings?