This is the second unikernel article this week I think, and the second that really undersells the benefits of having a full OS. Let's just swap out a couple of words:
> With a unikernel, the [observability] surface is much smaller. If the functionality isn't in the application (the operating system), then the [SRE] is screwed. There's no next hop.
Tools such as `strace`, eBPF, `lsof`, `ss`, etc. have tremendous value. The article mentions some nice things for observability ("structured logging, OTel") but so much gets thrown away.
In general, the more specific tool you have, the more tailored to the goal approach you may have, with all features optimized for that goal. If you need those tools from the full OS, you might have their specialized versions in a unikernel.
In a type 1 hypervisor running a JVM on top, you would use Java Flight Recorder.
The tools exist, and in a container world no one should be running those tools directly anyway, it is all about rootless immutable containers, ideally without OS layers for deployment.
Not just that. Unikernel sounds ok if all your linux server does is run one service that doesn't need anything but tcp/ip, and whose users don't need extra resources. But being able to deploy a new binary and other files through any means (ssh, pipelines, git), having localized log files, etc., are more than a convenience. Sure, I could log on another server, run a db on another server, and deploy html/css/js from yet another server, but would that make life easier? And this is just a really simple case. If you have multiple services, you'll need multiple servers with a uni-kernel approach, or build some monster thing. It's horses for courses.
Welcome to cloud computing, where software is cattle, not pets.
There isn't a Linux server taking care of a couple of services.
There are services deployed as Kubernetes pods, or serverless language runtimes across a cluster abstraction, running directly on top of type 1 hypervisors, or minimal kernel images enough to power distroless container images.
Let me know when your local OS does multi-machine scheduling across heterogeneous hardware and application constraints, networking, observability, service accounts and a finer grained permissions system, in a way that’s far less confusing and piecemeal.
Also, this argument only works if you just broaden the definition of “OS” to “anything that runs that isn’t your apps”.
> Tools such as `strace`, eBPF, `lsof`, `ss`, etc. have tremendous value. The article mentions some nice things for observability ("structured logging, OTel") but so much gets thrown away.
Trivial to implement. I have a full custom (from scratch written) debugging/benchmarking implementation written both for Linux and two of my custom kernels, both of which are REALLY unique when it comes to architecture. My custom debugger also supports numerous inline scripting languages.
It's also not like you are stuck with a full OS when you are running Linux. You can remove features from the kernel you don't need, and you can configure a bare-bones busybox to be your userspace, or just run your application directly as the init process.
Take this with a grain of salt. I haven't run unikernels in prod, so it's all a figment of my imagination.
> Tools such as `strace`, eBPF, `lsof`, `ss`, etc. have tremendous value.
But doesn't their value lie in getting you access to the core of the OS that you wouldn't be able to touch otherwise? What if your network stack was a library you could instrument just like you do with the rest of your app code?
Also, I don't need a tool to tell me I'm being punished by the IO or CPU scheduler if I am the only one using the CPU and IO :)
If your app, is the only one running, and the whole kernel is a library, you can simply have said library instrumented with as much observability as you need, directly and you now no longer need to worry about which processes are using cpu and IO because…it’s all you.
> With a unikernel, the [observability] surface is much smaller. If the functionality isn't in the application (the operating system), then the [SRE] is screwed. There's no next hop.
Tools such as `strace`, eBPF, `lsof`, `ss`, etc. have tremendous value. The article mentions some nice things for observability ("structured logging, OTel") but so much gets thrown away.
The tools exist, and in a container world no one should be running those tools directly anyway, it is all about rootless immutable containers, ideally without OS layers for deployment.
There isn't a Linux server taking care of a couple of services.
There are services deployed as Kubernetes pods, or serverless language runtimes across a cluster abstraction, running directly on top of type 1 hypervisors, or minimal kernel images enough to power distroless container images.
Also, this argument only works if you just broaden the definition of “OS” to “anything that runs that isn’t your apps”.
Trivial to implement. I have a full custom (from scratch written) debugging/benchmarking implementation written both for Linux and two of my custom kernels, both of which are REALLY unique when it comes to architecture. My custom debugger also supports numerous inline scripting languages.
> Tools such as `strace`, eBPF, `lsof`, `ss`, etc. have tremendous value.
But doesn't their value lie in getting you access to the core of the OS that you wouldn't be able to touch otherwise? What if your network stack was a library you could instrument just like you do with the rest of your app code?
Also, I don't need a tool to tell me I'm being punished by the IO or CPU scheduler if I am the only one using the CPU and IO :)