[marcus_holmes]

I've been playing with Unikernels for Go server deployment - so far so good. I'm not sure if this counts as "no OS" - as I understand it (and I'm not sure I do) the Unikernel core provides the calls that the Go runtime is expecting.

But the central idea that the server system can only run one program makes a lot of sense to me. Obviously it won't work for a desktop, but then the whole idea that desktops and servers run the same OS doesn't make much sense to me.

[OrvalWintermute]

I've been expecting the unikernel approach to catch on more too - although not the "no OS" it can be pretty stripped down compared to a regular OS. Now that unikernels are starting to gain more traction in the DOD I expect this will continue.

[perbu]

I've worked with Unikernels for a couple of years. They are great, but they are very, very pure and this can be limiting.

Say I have an web API written in Go. For some reason I need to do some openssl stuff before I start up my main program. In a container I can just wrap my program in a little shell script which generates/signs a cert before starting the API.

Such a simple task. It is gonna be a lot harder with a Go Unikernel as I could have to bake this functionality into the application itself.

This Swiss Army knife that is Unix often has it's uses.

[marcus_holmes]

I get that, but I rarely need to do stuff like this - I generally use the awesome ACME library to handle certs. But yes, if I did need to do that then a Unikernel wouldn't be useful.

But the reduction in attack surface of not having all those Swiss Army blades hanging about - and not having to configure them just right so I don't accidentally damage stuff - is a real benefit.

[pjmlp]

You can have best of both worlds with container OSes like Bottlerocket.

In any case, in you have a web API written in Java then you can connect advanced monitoring tools like JDK Flight Recorder and directly affect the system via JMX beans.

So it is more a matter of tooling maturity than anything else.

[pjmlp]

Somehow I would state that serverless and PaaS for managed languages are where unikernels are going.

In those cases 99% of the time you really don't care what runs underneath the language runtime.