I maintain physical machines, VM hosts, and containers. Each has its advantages.
Obviously, you need physical machines. Even the cloud has physical machines behind it. They're what host the VMs and containers!
My physical machines all host the core OS. That is, sufficient software to host my VMs. I'm running my containers within VMs, so in my case I don't need any container-specific packages installed in the physical VM.
On the other hand, there are several services that I prefer to host in the physical boxes, many of which could be virtualized, some of which are better not.
I have SAN filesystem services installed. That supports my ability to do real-time mirroring on multiple hosts. I like it on the physical box because the path between the physical disks and the filesystems being shared up isn't dependent on secondary services (such as virtual machine managers and Docker). This give probably a minor performance
boost, but more importantly, means that those files will be available even if the virtualization services are down or haven't come up yet.
I have a Nginx proxy (mirrored) on physical hosts. A bigger budget and I might simply have a hardware proxy box like an F5, but this fits my budget and needs. The proxy fronts for physical services, VMs and containers, so it needs to be there even if the backend servers are not.
I have DNS on my physical hosts. Another resource that needs to be highly available and come online early.
I worked in a shop back when virtualization was still minimal. We had Solaris Zones, but I was about the only one who knew how to use them, so we had production servers which often ran at 10% capacity and even at their peak didn't usually exceed 20%, because they provided services that needed to be isolated. We were running short on rack space and worse - we were popping circuit breakers. So virtualization was something badly needed there.
I mentioned that my Docker instances are actually in VMs. That has a few advantages. For one, currently Docker can crash when I do certain types of Docker image builds on CentOS 6, but not on CentOS 7. So, since I prefer CentOS 6 (no systemd to annoy me), I keep both OS's in respective VMs. Also, VMs can hot-migrate to other physical hosts if their primary host deteriorates. And finally, OS updates to the VMs (especially Docker updates) don't have the potential to take the entire physical server offline for long periods of time. If things go really sour, I can revert the VM image and I don't have to take down all the machine services at once.
1
