Re: Hmmmmm
Security is the main argument. If the containers are isolated in their own sandboxes, if one goes rogue, it can't kill the host OS or other applications running in other containers.
The argument in the "for" article are a bit off though. You still need an operating system in which to run the containers. The container just contains the application code and configuration, it doesn't provide the OS to run the services, it needs to "borrow" the core OS features from the underlying OS. There is no way around that, other than making the container a full VM...
I think that they have their place and, in the cloud, they are a good option. If you are running your own hardware and VM environment, it makes deployment in some respects easier and removing or replacing a container is easier than deinstalling an application and putting in a new one. Now crud left kicking around that needs to be manually cleared out.
That said, I've had containers or host environments that were real dogs and running the base application on the OS directly was actually quicker and easier. QNAP being a good example, I used a Unifi container on a QNAP NAS. It installed cleanly and easily, but you couldn't upgrade it, you needed to have the container information to install the update, but that information wasn't available on the QNAP, it was all hidden. The only way around it was to export the config, delete the container, install the updated container and restore the config. Unifi's built in update routines don't work in the container.
In the end, I put the full Unifi management software on a Raspberry Pi. It works much better than the QNAP implementation of Docker.
This isn't Docker's fault, the problem is how QNAP implemented it, easy installation out of a store containing Docker containers. But no information on the installation parameters and updates can only be done by hand using the command line and you need the installation parameters that were used by the GUI, which aren't documented and the GUI doesn't allow updates.
I like the idea of containers, but it still needs to mature and "rogue" environments that have a half-arsed implementation won't do anything to help improve their acceptance. I think we will be having both options (container and manual installation in a normal operating environment) for a long time, going forward.
There will always be situations, where the extra performance of direct installation will override the simplicity and security provided by a container and vice versa. (E.g. running a time critical application locally, you will install it directly and fine tune the OS and software, running on a shared cloud host, you will want to sacrifice some performance for the added security overhead.)