The point of the layered containers has nothing to do with how they're run; it has to do with how they're developed. By splitting the OS from the runtime from the application, each one can be updated when the layer above it needs it to be, and is otherwise fixed to a binary-identical image. Then, new releases of higher-level things (apps) can target the
old versions of lower-level things (runtimes, OSes), knowing they will be
literally, bit-for-bit, the same thing their other releases are using.
This is the guarantee Heroku makes, for example: updates to their servers will never break your app, because although the packages making up their infrastructure might update, the packages making up your container's base image are frozen in time unless you switch out your container's "stack" (base image) for a new one.
Having a frozen base OS image, and then a frozen runtime on top of that, allows for perfect repeatability in your deploy process. Once you've got a tested-and-working runtime image, that references a tested-and-working OS image, you just stop touching them altogether; you keep the container-ID of that runtime image fixed in production, and deploy your new app releases on top of it.
One neat side-effect of this: if containers have parent-images in common, those parent-images can be cached at the target. If all the containers running on some server use the same common base-image, that base image only needs to be downloaded to the server once. The second-through-Nth time, the container only grabs what's different--the tiny "app" part of the image--and then composes it with everything into a running container.
This is the guarantee Heroku makes, for example: updates to their servers will never break your app, because although the packages making up their infrastructure might update, the packages making up your container's base image are frozen in time unless you switch out your container's "stack" (base image) for a new one.
Having a frozen base OS image, and then a frozen runtime on top of that, allows for perfect repeatability in your deploy process. Once you've got a tested-and-working runtime image, that references a tested-and-working OS image, you just stop touching them altogether; you keep the container-ID of that runtime image fixed in production, and deploy your new app releases on top of it.
One neat side-effect of this: if containers have parent-images in common, those parent-images can be cached at the target. If all the containers running on some server use the same common base-image, that base image only needs to be downloaded to the server once. The second-through-Nth time, the container only grabs what's different--the tiny "app" part of the image--and then composes it with everything into a running container.