Hacker News Reader

Comment by hodgesrm | Hacker News Reader

I like the idea of the small attack service and minimal image size. However, having a different kernel image for each service seems likely to trigger some extremely hard-to-diagnose bugs, which have to include performance problems.

As least with conventional OS you have a chance to get in and figure out what's going on. With Unikernels it sounds as if you may end up with either a core dump (how?) or a misbehaving service you can't access to diagnose problems.

View on HN

Mirage can be configured to write trace data to a ring buffer shared with another VM, where you can run a visualisation tool to explore it. For an example, see:

https://mirage.io/wiki/profiling

Of course, having such a small (and legacy-free) OS makes debugging vastly easier in the first place.

You are right about simplification and I considered that point. Yet the fact that each application is developed on a general purpose platform, then compiled down to a unique production OS image seems to open up a lot of new corner cases involving long tail bugs. We had a similar phase in during the Java transition to JIT in the late 1990s, though that's obviously an antithetical technology approach. Either way you get a lot of ugly crashes.

The key for industrial use is extremely robust dev and management tools. Unikernels are thought-provoking but on their own do not appear to be anywhere near enough to solve the problem they are taking on.

Reply on news.ycombinator.com