Big upvotes for this article.  I&#x27;m glad it was written, because I&#x27;ve seen nothing but hype for Unikernels on Hacker News (and in ACM, etc.) for the last 2 years.  It&#x27;s great to see the other side of the story.<p>The biggest problem with Unikernels like Mirage is the single language constraint (mentioned in the article).  I actually love OCaml, but it&#x27;s only suitable for very specific things... e.g. I need to run linear algebra in production.  I&#x27;m not going to rewrite everything in OCaml.  That&#x27;s a nonstarter.<p>An I entirely agree with the point that Unikernel simplicity is mostly a result of their immaturity.  A kernel like seL4 is also simple, because like unikernels, it doesn&#x27;t have that many features.<p>If you want secure foundations, something like seL4 might be better to start from than Unikernels.  We should be looking at the fundamental architectural characteristics, which I think this post does a great job on.<p>It seems to me that unikernels are fundamentally MORE complex than containers with the Linux kernel.  Because you can&#x27;t run Xen by itself -- you run Xen along with Linux for its drivers.<p>The only thing I disagree with in the article is debugging vs. restarting.  In the old model, where you have a sys admin per box, yes you might want to log in and manually tweak things.  In big distributed systems, code should be designed to be restarted (i.e. prefer statelessness).  That is your first line of defense, and a very effective one.