The less between your application and the hardware the better you can utilise it. There’d be basically no contention for resources, IO could go basically straight to the drive with less fsync-shenanigans etc.
With our Linux-based unikernel you can make small adjustments to the application -- usually just a handful of lines of code -- and get big performance improvements, like 25% or so. We had a paper about this at Eurosys'23: https://dl.acm.org/doi/abs/10.1145/3552326.3587458
That‘s the problem of unikernels. There are papers how great they are but almost nobody is using them. If applications could easily get a 25% boost without much work they would do it.
But nobody is using it. So I am not trusting the „benefits“.
There are a ton of well known techniques in computer science that will make software faster, more reliable or better in other ways, that people don't use, yet really work.
I mean, if I had an easy-enough way to use them, I absolutely would.
Docker isn’t ideal, but it’s common, and the UX is decent enough. If a unikernel solution existed with near-enough quality of UX and deployment, I’d 100% switch.
> But nobody is using it.
The development community at large often chooses to use/not-use things (packaging solutions, tooling, engineering approaches, software architectures, etc) for a huge variety of reasons, not all of them based in any kind of logic or benefit. I suspect microkernels could become a viable solution for some things, they just need a “docker moment”.
If you look at PostgreSQL configuration settings, you'll notice a chunk of them are dedicated to dealing with fsync. They even have a dedicated testing tool to test how the database behaves with different modes of syncing.
fsync is a serious performance problem, especially in distributed storage systems. If you can get it under your control, you can definitely benefit from it.