As said in the post, this was a consequence of Docker failing them when running multiple containers on a host.
> Not using an optimized base os for containers...
On a server that might be possible, but I thought Docker's advantage was providing a reproducible system that can also be run on your dev machine? Sorry, if Docker doesn't run stable on my dev machine, no way I'm trying it.
Because the base OS needs to be something an admin can work comfortably on, esp. if the host is supposed to run other things besides docker (e.g. a database, you do not want to run mysql over a network if possible).
And for this you need a "real" base OS, which will be either apt-flavor (debian/ubuntu) or rpm-flavor (rhel, sles), depending on the organization.
Why not run your database on a different machine then. Separation of concerns. Have a cluster a machines for containers so you can take advantage of it's strengths instead of trying to duct tape everything together on machine
> Why not run your database on a different machine then. Separation of concerns.
While true in general, you always end up introducing latency (simply because it's on a different host) and possible packet losses/retransmits (e.g. when the switch buffer memory overruns). Given the "hft" in the blog name (high-speed financial transactions), both can equal losses of money.
As said in the post, this was a consequence of Docker failing them when running multiple containers on a host.
> Not using an optimized base os for containers...
On a server that might be possible, but I thought Docker's advantage was providing a reproducible system that can also be run on your dev machine? Sorry, if Docker doesn't run stable on my dev machine, no way I'm trying it.