Some of the original &quot;unikernel in a shared environment&quot; research and development was done on IBM&#x27;s VM system in the 70&#x27;s. Their motivation was that there were many customers who used a dedicated application on what was then a mainframe to process their data (this would be analogous to their unikernel) and they wanted to consolidate their hardware, so they got a bigger mainframe (like an IBM 370 at the time) and they would run all of these dedicated applications in their own logical partition (LPAR). It brought three huge benefits to the table (error containment, hardware consolidation, and backward compatibility). Because IBM had experienced the same effect that we&#x27;re seeing today, their new mainframes in the 70&#x27;s were so much more powerful than the ones from the 50&#x27;s and 60&#x27;s, and for them what was worse the ones from the 50&#x27;s and 60&#x27;s running their dedicated apps were still fine. So they developed a way to make computing more cost effective for their customer and at the same time opened the market further for their mainframes.<p>Today, a typical dual core 8GB x86 machine can, as a dedicated machine run a lot of things. At the same time the evolution of open systems have brought &quot;continuous configuration integration&quot; into the mainstream, all major OSs from OS X to Windows to Linux have weekly, sometimes daily, reconfiguration events.<p>And while the number of the changes in aggregate are high, the number of changes on particular subsystems are low. Unikernels answer the need of creating a stable enough snapshot of the world to allow for better configuration management. Look at the example of the FreeBSD system taken down after 20 years. Some services can just run and run and run.<p>Image isolation is a thing, and you can only be as good as your underlying software and hardware can make you, but it can also be a big boost to operational efficiency if that can simplify your security auditing and maintenance.<p>So my take on Bryan&#x27;s article was that he came at the argument from one direction, which is fine, but to be more through it would help to look at it from several directions. What was worse was that he made some assertions (like never being in production) before defining precisely what he means by a Unikernel which leaves him wide open to examples like NetApp and IBM&#x27;s VM system to counter his assertion.<p>The nice thing about computers these days is that many of the problems we experience have been experienced in different ways and solved in different ways already, and we can learn from those. The Unikernel discussion is not complete with looking through the history of machines which are dedicated appliances (from Routers, to Filers, to Switches, to Security camera archivers)<p>Like most things, I don&#x27;t think unikernels are a panacea but they also aren&#x27;t the end of the world and have been applied in the past with great success.