3 ms·

If you don't value your and your developer's time, certainly, containerize everything. I've rarely seen a feedback loop with containers that's not longer than

If you don't value your and your developer's time, certainly, containerize everything. I've rarely seen a feedback loop with containers that's not longer than 10s only due to containerization itself, and that breaks the "golden" 10s rule (see https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...). If you aim for quicker turn-around (eg. just running a single test in <1s), you'll have to either aggressively optimize containers (which is pretty non-idiomatic with Docker containers in particular), or do away with them.

crabmusket 2y ago
Are you talking about CI or local development? Why would you run a single test in CI? And why would a container add 10+ seconds to a local task?
- necovek 2y ago
  I am talking about either, because the GP post was about "containerizing a build environment": you need your project built to either run it in CI or locally. Why would it be slow? It needs to be rebuilt? (on a fast moving project with mid-sized or large team, you'll get dependency or Dockerfile changes frequently) It needs to restart a bunch of dependent services? Container itself is slow to initialize? Caching of Docker layers is tricky, silly (you re-arrange a single command line and poof, it's invalidated, including all the layers after) and hard to make the most of. If you can't get a single test running in <1s, you are never going to get a full test suite running in a couple of seconds, and never be able to do an urgent deploy in <30s.
akdev1l 2y ago
> I've rarely seen a feedback loop with containers that's not longer than 10s only due to containerization itself Sounds like a skill issue tbh. `time podman run —-rm -it fedora:latest echo hello` will return in a few milliseconds, whatever delay you are complaining about would be from the application running in the container. Lastly containers != docker.

crabmusket 2y ago

Are you talking about CI or local development? Why would you run a single test in CI? And why would a container add 10+ seconds to a local task?

necovek 2y ago
I am talking about either, because the GP post was about "containerizing a build environment": you need your project built to either run it in CI or locally. Why would it be slow? It needs to be rebuilt? (on a fast moving project with mid-sized or large team, you'll get dependency or Dockerfile changes frequently) It needs to restart a bunch of dependent services? Container itself is slow to initialize? Caching of Docker layers is tricky, silly (you re-arrange a single command line and poof, it's invalidated, including all the layers after) and hard to make the most of. If you can't get a single test running in <1s, you are never going to get a full test suite running in a couple of seconds, and never be able to do an urgent deploy in <30s.

akdev1l 2y ago

> I've rarely seen a feedback loop with containers that's not longer than 10s only due to containerization itself Sounds like a skill issue tbh. `time podman run —-rm -it fedora:latest echo hello` will return in a few milliseconds, whatever delay you are complaining about would be from the application running in the container. Lastly containers != docker.