8 comments

[ 2.8 ms ] story [ 30.6 ms ] thread
Unikernels are quite an intriguing concept. They'll be re-discovered every five years, like programmers keep re-discovering functional programming.
They're flying cars and VR.

People eventually come to realize they're not so great when having to apply real-world, cross-cutting concerns like access control, audit, logging, debugging, profiling, monitoring, throttling, backup, and recovery.

The emperor's new clothes might have a hole or two in them.

Access Control: There is none internally. We don't have the notion of users.

Logging: Keep using whatever you want be it elasticsearch, syslog, cloudwatch, etc. No opinions here.

Debugging: GDB works fine and in many cases since you can simply export the vm in it's entirety and then attach to it locally this becomes even easier to debug than the same application running on linux.

Profiling: We support things like ftrace and of course things like prometheus you can export.

Monitoring: Kinda in the same boat as logging - keep using whatever you are using today - datadog, victoria metrics, etc.

Throttling: This is traditionally an app-level concern that someone would implement at perhaps a load balancing layer - keep using whatever you are using.

Backup/Recovery: Running unikernels make it trivial to backup as you can clone running vms. In fact most cloud deploys involve making a snapshot that is already stored as a 'backup' and makes things like rollback much easier to do.

Wake me up when you can unikernel-ize a Java framework like Quarkus or Spring.
@eyberg: i'm curious on how NanosVM Inception works? what's included in the image here

https://aws.amazon.com/marketplace/pp/prodview-lwk72eg6wfo3i

Sorry - just now seeing this. This is a build of PVM that works with Nanos. We're also maintaining that patch set as I don't ever see it getting included into the kernel (not anytime soon anyways).
Undead, undead, undead.