If you're running Docker in a VM on a bare metal server you're doing it wrong. You should be running Docker on a bare metal server.
You're also conflating different problems here. If someone is writing poor SQL it doesn't matter if their deploying with a VM, Docker, or onto a bare metal server.
They are explicitly not that. Docker containers do not provide you any real isolation guarantees from a security POV and make no attempts at such. This is extensively documented. [1]
"If you're running Docker in a VM on a bare metal server you're doing it wrong. "
Ummm... Running Docker inside a VM is by far the most common deployment type of Docker there is. What do you think is an EC2/ECS/GKE deployment? Hint, there's a VM running your containers in all of them. This is also what Docker the company recommends - https://www.docker.com/blog/containers-and-vms-together/
[1]: https://docs.microsoft.com/en-us/virtualization/windowsconta... https://www.redhat.com/en/topics/containers/containers-vs-vm...
Until a bug in Docker, or the CNI abstraction, or some resource hangs/panics the kernel on the bare metal, and then you have to reboot the whole thing taking out all the containers.
This gets rarer, and rarer, as the bugs get ironed out, of course, but In my 20+ year anecdotal experience, a kernel running just a bunch of VM's crashes far less frequently than a kernel running containers.
They are related, as devs sometimes think of microservices as a way to speed things up and/or process more requests per second, under an assumption that a server with fewer responsibilities is a server with faster turnaround time.
Not if you're doing things that require certain kernel features. For example, if I have an application that uses io_uring, it's _very_ pertinent as to which kernel it runs on. A VM has that in scope, a Docker container does not.