Hacker News Reader

Comment by mirceal | Hacker News Reader

i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing.

Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development.

Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp) 2) small attack surface (because you only have your app that’s the only attack surface. you don’t have cruft that build up in you os/kernel over years) 3) light resource usage (you could run thousands of these on the same physical machine) 4) true isolation via the hypervisor

definitely worth keeping an eye on the developments in this space

View on HN

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development.

Whether or not you want to debug in production, reality often means that you will see things in a live environment that you will not see in other environments.

Unikernels are very interesting and have a number of compelling attributes, but let's not pretend that the current state of available tooling for troubleshooting, instrumentation, and general debugging isn't a challenge.

hah. they're a new technology/approach. of course there are going to be challenges.

You're moving the goal posts and invoking a straw man. No one is advocating for "pretending", and the anti-unikernel argument is that the inherent cost of unikernels in general is the loss of kernel debugging tools; not simply that "right now the unikernel debugging experience is subpar".

in general right now, running on a full-featured monolithic kernel, the debugging experience is really pretty bad. especially in the target environment of horizontal clustered services or lots of little micro services.

so I actually believe there is an opportunity here to focus on the important pieces (network messages, control flow tracing, memory footprints, etc) after ejecting a huge amount of irrelevant stuff

Totally agree, there's definitely an opportunity there if the surface area of what the system is doing gets smaller. The big difference today is that it's a lot easier to compose a debugging suite using additional tools on top of a traditional host-based runtime for now.

Definitely excited to see how the technology evolves over the next few years. It hasn't moved as fast as I'd have expected over the last 2-3 years but I'd love to see that accelerate.

No, I'm not moving any goal posts. I was reacting to the statement "Tooling/Perf/etc is not needed when running". I'm not sure where you'd get the idea that I'm anti-unikernel, I just wanted to not disregard that challenge since it does matter.

I took care not to say that you were anti-unikernel; I was articulating the anti-unikernel position. I'm not sure what you actually meant, so I'll take you at your word that you weren't moving goal posts--in whatever case, the OP is correct that unikernels aren't inherently less debugable even though mature debug tooling may not exist for them today.

> Tooling/Perf/etc is not needed when running (do you really want to debug in production)

Do I want to debug in production? No.

Do I have to do it anyways? All the fucking time. I'm not perfect, I sometimes ship bugs, and when they show up in production, I need to diagnose, determine if rolling back will solve them, or whether I need to fix forward and how. Not being able to debug in production is simply unacceptable.

I want to ship perfect code. But I don't. So, instead, I debug. If the issue shows up in production, I debug in production.

yeah no. you don’t debug in production. you have logs and metrics. if you need to debug (as in attaching the debugger) you already are in trouble

Of course I'm in already in trouble. That's why I'm debugging. I tend not to debug things that are working perfectly.

If I can't attach a profiler to find, for example, the code that contains a regex that's doing too much backtracking with production data, then I'm dead in the water. If I can't get a sample out of a system that's received a query of death, then I'm dead in the water. If I can't attach dtrace (or the equivalent) and get stats on how much I/O a system is doing in response to various events, I'm dead in the water.

Being able to dive into the depths of a system is the #1 criteria for confidently being able to put it into production.

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development.

I don’t follow. Are you saying that development should build normal user space binaries, and you should only build the unikernel for production?

You will inevitably run into a behavior difference between the unikernel and user space outputs. Even if you’re not debugging in production (shudder) you need to be able to debug the unikernel.

Reply on news.ycombinator.com