You don't even need unikernels, and as much as I loathe myself for saying it, I find myself agreeing with a few of Cantrill's points regarding unikernels in pro

You don't even need unikernels, and as much as I loathe myself for saying it, I find myself agreeing with a few of Cantrill's points regarding unikernels in prod. Not all of them, and I think it's worth exploring, but there's a spectrum here: on one end, unikernel app containers, and on the other full jails. The Google approach with minimal containers that still act Unixy and Posixy but carry very little distribution overhead is somewhere around 0.1 on the spectrum. But we call [0.0, 1.0] the same thing now, so the tooling has to support all cases, and now just pulling a Docker image down might cost me gigabytes of network transfer that I don't need to spend. Combined with the HTTP-strong architecture, Docker encourages fat containers but then falls apart on them at higher sizes because of the HTTP mechanics. Example: I need to ship about 1 TB of static data alongside my app in a separate container. Try that in Docker. The answer will invariably be Docker not being designed for that, but I thought Docker encouraged the jail-style fat container case? What happens when the jail you're renting out because that's a container too actually uses a bunch of space and you try to `docker commit` into whatever you're managing your containers? You shouldn't be using containers for that, but features of Docker encourage it, and thinking fat like that has numerous pitfalls. (My example is borne from reality: I watched Docker wash out from a team in two days once they tried to commit a 100+ GB container. I assume the docs guided them there.)