Seems like a straw-man. Why is a process running within a container failing over more frequently than a process running directly on bare metal -- seems like more of a resource/process scheduling issue than anything to do with containers.
Or do you mean that Docker etc. are as reliable as bare metal?
Heck, you can go on Docker's webpage (https://www.docker.com/what-docker). Notice that while they make the claims that Docker is-
1. More lightweight
2. 'Open'/run anywhere
3. Secure
They don't say 'more reliable'.
I use Docker for systems I design; I also recognize current container technologies have their limitations. It is my job to know and avoid these pitfalls.
A lot of issues that people encounter with Docker specifically disappear if you run Kubernetes (such as volume management), simply by ignoring what Docker does and doing something sane instead.
> Or do you mean that Docker etc. are as reliable as bare metal?
This doesn't really mean anything, Docker the product has a lot issues - sure. Container technology in general? No. Where do you draw the line here? Is a chroot 'as reliable as bare metal'? At what point is a container not running on bare metal anymore?
As you said, a lot of problems would disappear if people use Kubernetes instead of Docker. At the same time, a lot of replication problems would disappear if people use PostgreSQL instead of MySQL. My point is, when a novice mixes immature technology with immature technology, he is going to have more issues than what's necessary.
Unless you've gone out of your way, Docker (as well as other Linux container systems) are just namespacing your process. There's no extra abstraction layer, it's just a more restricted execution environment.
Docker is ok when it works, hell when it doesn't, has lots of bugs and regularly regresses. I don't understand why you'd run production infrastructure on that and not on any of the alternatives.
Run like this, there is no disk or network performance difference between running the db process directly on the host or via a Docker container.
As others have mentioned, this is a really poor article.
Because the way to change anything in a container is to kill it and restart it. That's a fundamental difference compared to managing/maintaining a database not in a container.
The fact `docker kill` defaults to using SIGKILL instead of SIGTERM is unfortunate, and something one should be aware of before deploying a process with docker, but again, this does not make the process running within the container inherently less reliable.
edit: Looks like `docker stop` does the right-ish thing -- sends a SIGTERM, then only resorts to SIGKILL after a timeout has expired.