hackernews client

Hands-On Introduction to Unikernels

107 pointsposted 22 days ago

(labs.iximiuz.com)

43 Comments

bregma

16 days ago

So, if I understand correctly, a "unikernel" is what we used to call an "executive" except it is intended to be run as a guest on a virtual machine provided by a full-fledged traditional kernel/userspace OS instead of on bare metal.

The article does reintroduce some concepts that were commonplace when I was first learning computers and it gives them some new names. I like that good ideas can still be useful after years of not being the latest fad, and it's great that someone can get new credit for an old idea with just a little bit of marketing spin.

valyala

13 days ago

There is no need in the operating system to run Unikernels. Every Unikernel includes parts of operating system needed for interacting with the underlying hardware. So Unikernels can run on bare metal if they know how to interact with the underlying hardware (i.e. if they have drivers for that hardware). Usually Unikernels are targeted to run on virtual machines because virtual machines have unified virtualised hardware. This allows running the same Unikernel on virtual machines across multiple cloud providers, since they have similar virtual hardware.

fulafel

16 days ago

Amiga: https://wiki.amigaos.net/wiki/Introduction_to_Exec

> The Multitasking Executive, better known as Exec, is the heart of the Amiga's operating system.

> All other systems in the Amiga rely on it to control multitasking, to manage the message-based interprocess communications system, and to arbitrate access to system resources.

g-b-r

16 days ago

They can generally be run on bare metal, to my knowledge.

I personally don't remember exactly what was meant with "executive".

simtel20

16 days ago

I've only ever heard of that as the type of a DOS/Windows .exe binary.

g-b-r

16 days ago

that's an executable...

simtel20

7 days ago

There were publications in the 80s that used that term iirc, and I do recall the term for how slightly incongruous it was, and how it didn't come with an explanation.

In looking into ut some more, it looks like the executive was a term from mainframes for the layer of the kernel that enforced isolation, but I must have read the term being loosely used in pc magazines. Or maybe mockingly?

deivid

16 days ago

This is really well written, thanks for sharing.

I didn't understand the point of using Unikraft though, if you can boot linux in much less than 150ms, with a far less exotic environment

nderjung

16 days ago

Hey! Co-founder of Unikraft here.

Unikraft aims to offer a Linux-compatible environment (so it feels familiar) with the ability to strip out unnecessary internal components in order to improve both boot-time/runtime performance and operational security.

Why would you need a memory allocator and garbage collector if you serve static content? Why would you need a scheduler if your app is run-to-completion?

Linux gives you the safety-net of generality and if you want to do anything remotely performant, you by-pass/hack it altogether.

In the article, Unikraft cold-boots in 150ms in an emulated environment (TCG). If it was running natively with virtualization hardware extensions, it can be even shorter, and without the need for snapshots which means you don't need to store this separately either.

deivid

16 days ago

Unikraft is cool, I still have it in my 'todo' list to play around with sometime.

Linking the app with the 'kernel' seems pretty nice, would be cool to see what that looks like for a virtio-only environment.

Just wanted to point out that the 150ms is not snapshot based, you can get <10ms for small vms (128MB ram, 2GB ram moves you to ~15ms range), for 'cold' boots.

pjmlp

16 days ago

Security, it isn't only memory footprint.

iberator

16 days ago

Which architecture can boot it in 150ms ?!

jumploops

16 days ago

Boot is a misleading term, but you can resume snapshotted VMs in single digit ms

(and without unikernels, though they certainly help)

deivid

16 days ago

You can boot a vm without snapshots in < 10ms, just need a minimal kernel.

rwmj

16 days ago

I think "in a VM" was elided. It's easy to tune qemu + Linux to boot up a VM in 150ms (or much less in fact).

Real hardware is unfortunately limited by the time it takes to initialize firmware, some of which could be solvable with open source firmware and some (eg. RAM training) is not easily fixable.

hun3

16 days ago

Stripping away unused drivers (.config) and other "bloats" can get you surprisingly far.

TacticalCoder

16 days ago

And most importantly and TFA mentions it several times: stripping unused drivers (and even the ability to load drivers/modules) and bloat brings very real security benefits.

I know you were responding about the boot times but that's just the icing on the cake.

hun3

7 days ago

Mostly depends on how bloat correlates to attack surface, but you're right

iberator

16 days ago

But 150ms? That's boot time for dos or minix maybe (tiny kernels). 1s sure.

balou23

16 days ago

FreeBSD did some work to boot in 25ms.

Source: https://www.theregister.com/2023/08/29/freebsd_boots_in_25ms...

deivid

16 days ago

You can do <10ms. I was working to see if I could get it under 1ms, but my best was 3.5ms

gpderetta

16 days ago

for example: https://firecracker-microvm.github.io/

binsquare

16 days ago

Microvm's

victorbjorklund

16 days ago

Because it will be slightly faster and you will use less resources? For a lot of use cases that probably does not matter but for some it does.

hun3

16 days ago

Hypervisor as a microkernel

pjmlp

16 days ago

Yes, there is a certain irony when you look at the cloud workloads with a type 1 hypervisor managing either serverless or container workloads.

tuananh

16 days ago

the missing piece of unikernel is debuggability & observability

- it need to be easy to replicate on dev machine & easy to debug - it needs to integrate well with current obs stack. easy to debug in production.

without clear debuggability & observability, i would never put it into production

imiric

16 days ago

This is a common myth. Debugging unikernels is indeed possible[1][2]. It may not be the type of debugging you're already used to, but then again, unikernels are very different from containers and VMs, so some adjustment is expected.

As for observability, why is that the concern of unikernels? That's something your application should do. You're free to hook it up to any observability stack you want.

[1]: https://nanovms.com/dev/tutorials/debugging-nanos-unikernels...

[2]: https://unikraft.org/docs/internals/debugging

godisdad

15 days ago

Respectfully, neither of these docs strike me as really sufficient to debug live running systems in the critical path for paying users. The first seems to be related to the inner development loop and local the second is again how to attach gdb to debug something in a controlled environment

Crash reporting, telemetry, useful queuing/saturation measures or a Rosetta Stone of “we look at X today in system and app level telemetry, in the <unikernel system> world we look at Y (or don’t need X for reason Z) would be more in the spirit of parity

Systems are often somewhat “hands off” in more change control sensitive environments too, these guides presume full access, line of sight connectivity and a expert operator which are three unsafe assumptions in larger production systems IMO

valyala

13 days ago

You can expose Unikernel application metrics in Prometheus text exposition format at `/metrics` http page and collect them with Prometheus or any other collector, which can scrape Prometheus-compatible targets. Alternatively, you can push metrics from the Unikernel to the centralized database for metrics for further investigation. Both pull-based and push-based metrics' collection is supported by popular client libraries for metrics such as https://github.com/VictoriaMetrics/metrics .

You can emit logs by the Unikernel app and send them to a centralized database for logs via syslog protocol (or any other protocol) for further analysis. See, for example, how to set up collect ing logs via syslog protocol at VictoriaLogs - https://docs.victoriametrics.com/victorialogs/data-ingestion...

You can expose various debug endpoints via http at the Unikernel application for debugging assistance. For example, if the application is written in Go, it is recommended exposing endpoints for collecting CPU, memory and goroutines profiles from the running application.

pjmlp

16 days ago

Easy the very same kind of mechanisms for rootless/no-ssh containers are available.

traxler

16 days ago

I've found the idea of unikernels interesting for several years now, is there a tl;dr on why they don't seem to have taken off, like at all? Or is it all happening behind some doors I don't have access to?

gucci-on-fleek

16 days ago

I think that part of it is that relatively few people use bare-metal servers these days, and nested virtualisation isn't universally supported. I also found this technical critique [0] compelling, but I have no idea if any of it is accurate or not.

[0]: https://www.tritondatacenter.com/blog/unikernels-are-unfit-f...

eyberg

16 days ago

The majority of nanos users don't do either of these methods. They simply create the image (in the case of aws that's an ami) and boot it. This is part of what makes them vastly more simple than using normal linux vms or containers as you don't have to manage the "orchestration".