> Standalone apps, in the way that people are building them wont. Conatainers rely on the underlying operating system for various things. Any exceptions are bun

> Standalone apps, in the way that people are building them wont. Conatainers rely on the underlying operating system for various things. Any exceptions are bundled with the app. I don't understand. I assume that for "underlying operating system" you mean the OS that hosts containers. Unless you depend on some OS specific things like iptables or stuff like that, it should be trivial to rebuild a container (e.g. make a new docker image with a new php) and test it. Containers are not so great if you migrate into container software that has not been packaged for containers in the first place. It's not that it won't work, but it's easy to find example where you could run into troubles. The whole point of solutions like docker is to give you the consistent environment that will help you to test your changes in isolation. > [...] The OS has an update function that is know, tested, documented and works. I can install a new RPM/deb and be fairly sure it'll work if it installs Until you have a distro that's too out of date for that to work properly. The same thing happens if you use containers with too much of an "OS" in it. There is currently a lot of debate about what's the right balance between microcontainers or full fledged mini-OS inside a container. On one end of the spectrum you move your problem to container orchestration, while on the other you risk breaking the isolation abstraction provided by the container by running an OS that doesn't have full control on it's environment (e.g. kernel, disks etc) and thus breaking the guarantee that existing upgrade tooling will work flawlessly. > a true VM is free to be moved to a new host, a container is not. You are hamstrung to that machine and possibly that config. > So If you built the farm on docker, you're stuck with it, on that hardware. unless you want down time, or was to re-engineer things That's true, only a VM will guarantee that an arbitrary legacy application can be moved to a different physical machine in face of arbitrary incompatible developments in the underlying hardware. Well, if you want to stretch that to the extreme, only a full emulator can guarantee that you will be able to run your legacy things on a completely different CPU architecture. However, you must be aware that VM offer you a way to acquire a technical debt, which is great in that it allows you to decouple your immediate hardware upgrade needs from your software reengineering, but you must be aware that you'd have to pay off this debt. I have a 15 years old mandrake linux VM with some legacy software. It's well known, tested and documented update system won't help me maintain the mess that's inside that VM.