Good visual on the daemon/containerd split. Worth calling out too that most of what people call Docker overhead is actually the image pull and layer caching, not the runtime itself once the container is actually running.
Exactly. Once it's running it's basically a normal process at near-native speed, so the "overhead" everyone feels is the cold path: pull, decompress, extract layers. Which is why it stops being a footnote the moment you're launching containers on demand, serverless, batch jobs, agents spinning up compute per task. The runtime is basically solved; the real latency lives in the supply chain now (image size, registry proximity, lazy-pulling, warm caches).
Good one 👍
Good visual on the daemon/containerd split. Worth calling out too that most of what people call Docker overhead is actually the image pull and layer caching, not the runtime itself once the container is actually running.
Exactly. Once it's running it's basically a normal process at near-native speed, so the "overhead" everyone feels is the cold path: pull, decompress, extract layers. Which is why it stops being a footnote the moment you're launching containers on demand, serverless, batch jobs, agents spinning up compute per task. The runtime is basically solved; the real latency lives in the supply chain now (image size, registry proximity, lazy-pulling, warm caches).
thanks for the explanation 🌈
Very nice