> remember that containers add a framework/dependency at quite a fundamental level I don’t mind this fundamental dependency. If the only artefact you have is a

> remember that containers add a framework/dependency at quite a fundamental level I don’t mind this fundamental dependency. If the only artefact you have is a container, and no source code, that’s no worse (arguably it’s better) than the “we only have the compiled binary of the production service from a decade ago, and no idea what’s installed on the machine”. That complexity lives somewhere, and if your application is tied to it (e.g. a specific python version) then it makes sense to have that part of your application. Containers have been bread and butter for a long time now, I don’t think they’re a super scary new thing that we should worry about disappearing off the face of the earth tomorrow (like the latest js framework) > there are maintenance costs Those maintenance costs exist with or without containers. Either you have a virtualenv or whatever, a container, or a global toolchain installed and you just ignore it. I’ve got containers that I wrote in 2019 that I built last week and they just worked out of the box, no faffing around with versions of anything. In my experience, the thing that’s most likely to fail or rot is external URLs that you grab the dependencies of the container from - which will happen with a shell script or virtualenv either Edit: https://github.com/dotnet/core/issues/9671 https://github.com/dotnet/core/issues/9671 here’s a perfect example