The search for the killer app of unikernels


#1

[from the original at: http://unikernel.org/blog/2017/the-search-for-the-killer-app-of-unikernels]

When a radically different technology comes along it usually takes time before we figure out how to apply it. When we had steam engines running factories there was one engine in each factory with a giant driveshaft running through the whole factory. When the electric engine came along people started replacing the giant steam engine with a giant electric motor. It took time before people understood that they could deploy several small motors in different parts of the factory and connect electric cables rather than having a common driveshaft. It takes time to understand the technology and its applicability.

Continue reading …


#2

This clearly an application of unikernels to smart contracts in both the replicated state machine sense as Tendermint or Hyperledger Fabric sense or as quorum machines or inside trusted execution environments like SGX.


#3

IoT! Every presentation about unikernels mentions IoT yet I haven’t found a single example in the wild. If anyone has experience trying to build, say a gateway, I’d love to talk to you.


#4

I had a random encounter with with Lars Thomas Hansen, which works on Webassembly (wasm) at the Mozilla foundation. So I asked what he thought of the idea of using unikernels in browsers. Now I have a better understanding of why it isn’t really feasible.

In wasm, at least in Firefox, the code is run in a separate piece of memory, relying on CPU boundchecking to limit access to surrounding memory. This happens in the same process as the browser. There have been discussions if it should happen within a separate process, which would in principle be quite similar to the proposed idea of using a unikernel and CPU virtualisation. However, the wasm component needs a way to access the DOM and the Javascript engine with minimal overhead and as such it needs to happen in the same process to avoid a costly context switch. Some security is sacrificed, but people seem quite confident that the offered security level is still sufficient.

In addition there is of course the aspect of portability. Binary code isn’t portable. Javascript engines are. However, one weakness of the current implementations is that there isn’t an efficient way to leverage the CPU-specific instructions to optimise various workloads. So, if you compare doing a TLS handshake in wasm compared to native code the native code can be made to run a lot quicker if it can use the latest instructions to do so.

I guess the binary could be built on demand and supporting 99% of the devices out there would be possible (if one supports i386 and ARM32) with on demand compilation targeting each device and taking the features of that platform into account. However, it would’t be as easy to leverage things like edge caching nodes to handle scalability and network performance. wasm OTOH can leverage CDNs and such in a robust fashion.