

After Docker: Unikernels and Immutable Infrastructure - dlrush
https://medium.com/@darrenrush/after-docker-unikernels-and-immutable-infrastructure-93d5a91c849e

======
contingencies
This post makes sense except for the unrealistic notion that some kind of
mystical unikernel is going to descend fluorescent pink-winged from the
heavens and spear code cruft with its long sinuous Tusk of GreatCode +37.

The goal of less kernel bloat is a great one, however the realistic options in
a modern environment are either (1) accept the performance and management
overhead in running and maintaining a whole new kernel per application; or (2)
use containers, thereby unifying the kernel across all containers and removing
that overhead (but accepting some security risk).

The pink-winged unikernel is option (3) Everyone rewrites all their code to
run on some exotic kernel, or accepts a very complex and long-winded automated
recompilation of their existing kernel (eg. Linux) in line with automated
application profiling and agrees to deploy on paravirt instead of containers
and take the resulting performance hit.

I think (3) is unrealistic, though parts of it will eventually occur at
appropriately latency-agnostic portions of mature continuous deployment
processes, but do wish unikernels and their winged brethren the best of luck.

