Live data from Hacker News

What is a 'unikernel'?

ma.ttias.be

11–20 of 71 posts

Re: What is a 'unikernel'?

#11
post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

My simplified version: A container is a way of sharing the resources of a kernel, with some resource isolation. A unikernel is a way of sharing the resources of a hypervisor.

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.

Re: What is a 'unikernel'?

#12
post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

I pretty much stay away from all this stuff, but I keep a keen eye on it. The whole virtualization space is pretty interesting (potentially), but it seems like people aren't too clear about the different use cases. Rather, they promote whatever bit of tech they learned as The Solution, even though VMs, docker, unikernels, et al obviously have different characteristics.

Re: What is a 'unikernel'?

#13
post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

I don't think containers are related to unikernels. The whole point of containers is to sacrifice a bit of performance in order to gain convenience. 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 requiremen…

Or if you want to remove a potential layer of security issues.

Re: What is a 'unikernel'?

#14
post #6
post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

Seems pretty weird that we think it's normal to run a computer that simulates several physical computers, each running an operating system built for the mainframe in a 70s university CS department closet that then only ever runs one user and one application. You just think it's easier because you're used to it. I'm glad that this development is happening. In a few years when it's mature, we'll all have a saner setup…

Yeah I certainly see the contradiction(?) in things. That is the world we live in though. I think the biggest issue is with the tools we use to manage things. Looking at things as "a computer" with storage/network/cpu seen as one unit is pretty natural now as it has always been that way pretty much.

Re: What is a 'unikernel'?

#15
post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

Nobody is stopping you from using VMs instead of containers. I bet most deployments aren't using containers. And unikernels are very much experimental and research right now, especially since they aren't made to easily package an existing application.

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.

Re: What is a 'unikernel'?

#16
post #7
post #6

Earlier quoted context omitted.

Seems pretty weird that we think it's normal to run a computer that simulates several physical computers, each running an operating system built for the mainframe in a 70s university CS department closet that then only ever runs one user and one application. You just think it's easier because you're used to it. I'm glad that this development is happening. In a few years when it's mature, we'll all have a saner setup…

>In a few years when it's mature, we'll all have a saner setup to work with. I'm happy you get to work in an environment with no legacy applications that require a specific old operating system but that's not the case for a massive portion of sysadmin jobs.

From a recent post, here's a talk[1] about containers where they use SmartOS (Solaris/IllumOS derivative) to containerize Linux by just implementing the syscall table. The future of hosting legacy apps might be providing legacy interfaces on modern OS's (IMO).

1: https://www.youtube.com/watch?v=coFIEH3vXPw

Re: What is a 'unikernel'?

#17
post #5

From the article: > Even core modules in the Linux kernel don't apply to every installation. Things like USB drivers are useless in a virtualised "cloud" environment, but are still included in the kernel. You don't have to compile them in, or load them as modules, if you don't want. Or am I confused about what they're trying to say? I've been using Linux for long enough to recall when you had to recompile your kernel…

It is said in a very confusing manner. The core idea is dependency inversion: instead of the admin dictating the capabilities of the kernel, dictating the capabilities of the applications, we turn the whole thing around.

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?

Re: What is a 'unikernel'?

#18
> Honestly, if you're thinking about all the levels an application is built upon, it's a miracle things even work.

One mitigating factor is that all those russian-doll levels don't switch back and forth all that much (thinking in computer, not human, time). Moreover, some of those levels (like the BIOS) do their thing and then they cede control until the end of time (i.e. reset).

So yes, the multilayered cake is pretty impressive, but the situation is not that dire.

Re: What is a 'unikernel'?

#20
post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

There's a huge spike of value created when you cross the threshold of "you really don't need to think about sysadmin stuff, you can just focus on the application layer."

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. :)

Post reply on HN