I have a bit of a problem understanding why this would be a good thing to be honest.
Capacity demand is handled by resource concurrency thresholds so why would spinning up a new OS (no matter how lightweight) be better than having non-blocking IO threads on a single kernel?
There is no reason the spun up OS can't also have non-blocking IO threads.
Mirage's philosophy is mainly about reducing attack surface and unnecessary overhead. That it makes the OS so small that you can boot it up in milliseconds is just an added benefit.
Ok, but that would only be true if I was going to spin up a new vm to join the load group / cluster but even then no one would do that unless behind a reverse proxy / waf load balancer so the attack vector angle is covered.
I'm not saying MirageOS doesn't sound neat, I'm just not yet convinced it has a general purpose use case.
Due to the startup time your average server would, in practice, still need to run an SSH server for remote administration which is a vector for attack. A MirageOS server you would instead just tear down and start a new version of.
A WAF also still passes through HTTP requests which hit Apache/nginx which calls out into the OS and altogether that give a significant surface area for vulnerability (think e.g. shellshock and ENV variables.)
I also don't think anybody says that MirageOS is ready for the general purpose use case; it's very much specific experimental tooling for (currently) really niche cases.
Unikernels do have a ton of future potential though ....
I'll be reading more into unikernels because it does seem like an interesting topic.
However, I strongly advise you to read up on how production environments are done in security conscious enterprises (banks, payment providers, etc) as you seem to make some assumptions in your comment. To give you some idea of the environments I've designed in the past:
A WAF worth it's name won't pass any request back to a webserver if it matches a known signature, method, payload, etc. This is a functionality commonly called virtual patching. SSH is usually only allowed on internal vlans and often requires some sort of external authentication mechanism like a centralised jumpserver or ldap.
Also, if using Solaris with OVM for SPARC you wouldn't boot up a new server but a non-global zone (think Docker but 2 years from now) which can be started in ~1 second and offer full isolation from the host system. AIX also does something similar and I've seen several different approaches used on Linux from LXC to VMware + F5 irule based auto-scaling groups.
A properly secured SSH server still has a bigger attack surface than no SSH server and likewise a webserver+OS behind a WAF still has a bigger attack surface then a webserver without an OS.
I guess this is defining things from a purely pragmative "more code means a bigger attack surface" perspective. I know that's an oversimplification but there's also some truth to it.
But indeed; the Solaris OVM / LXC stuff spawning minimal OS's without administrative access gets you quite close (and with a more vetted codebase,) so in that regards unikernels are indeed still mainly an academic exercise.
Are you sure? I'm usually very careful with my usage of figures of speech but I'm no language major so maybe I should clarify that I meant that I could see edge cases but not a general purpose one.
Did this clarify my point or in any other way contribute to your undestanding?
MirageOS is useful for creating single-purpose appliances. That fits well with how the cloud is used today (where you typically end up with one service/app per VM anyway). The autoscaling piece is only one aspect and is only in the early stages, so you shouldn't dwell on it.
The overview page and the ASPLOS paper (linked upthread) and the ACM article [1] will help explain the benefits and trade-offs of the unikernel approach. Other people have also started using unikernels so you can read about their experiences too [2].
Capacity demand is handled by resource concurrency thresholds so why would spinning up a new OS (no matter how lightweight) be better than having non-blocking IO threads on a single kernel?