[teekert]

Your understanding of containers is incorrect!

Containers decouple programs from their state. The state/data live outside the container so the container itself is disposable and can be discarded and rebuild cheaply. Of course there need to be some provisions for when the state (ie schema) needs to be updated by the containerized software. But that is the same as for non-containerized services.

I'm a bit surprised this has to be explained in 2025, what field do you work in?

[johannes1234321]

It's not that easy.

First I need to monitor all the dependencies inside my containers, which is half a Linux distribution in many cases.

Then I have to rebuild and mess with all potential issues if software builds ...

Yes, in the happy path it is just a "docker build" which updates stuff from a Linux distro repo and then builds only what is needed, but as soon as the happy path fails this can become really tedious really quickly as all people write their Dockerfiles differently, handle build step differently, use different base Linux distributions, ...

I'm a bit surprised this has to be explained in 2025, what field do you work in?

[rkomorn]

It does feel like one of the side effects of containers is that now, instead of having to worry about dependencies on one host, you have to worry about dependencies for the host (because you can't just ignore security issues on the host) as well as in every container on said host.

So you go from having to worry about one image + N services to up-to-N images + N services.

[zelphirkalt]

I think you are not too wrong about this.

Just that state _can_ be outside the container, and in most cases should. It doesn't have to be outside the container. A process running in a container can also write files inside the container, in a location not covered by any mount or volume. The downside or upside of this is, that once you down your container, stuff is basically gone, which is why usually the state does live outside, like you are saying.

[fijiaarone]

Your understanding of not-containers is incorrect.

In non-containerized applications, the data & state live outside the application, store in files, database, cache, s3, etc.

In fact, this is the only way containers can decouple programs from state — if it’s already done so by the application. But with containers you have the extra steps of setting up volumes, virtual networks, and port translation.

But I’m not surprised this has to be explained to some people in 2025, considering you probably think that a CPU is something transmitted by a series of tubes from AWS to Vercel that is made obsolete by NVidia NFTs.