If you limit your understanding of "containers" by not advancing past single-page tutorials produced by content marketing folks at orchestration startups, you may _feel_ like the author is right. But as it almost always the case with damn computers and generalized topics, there's no right or wrong. The world is boring and full of "it depends" but that was conveniently left out of the article because the goal, I suspect, was to back a sensationalist title and produce clicks/views. But I'll bite:

> 1. Data insecurity

The author is mixing up Docker image store with database's own data. It is true that Docker graph drivers have issues, but they don't store any data, those are binaries you distribute and you're welcome to start docker containers from a plain old directory on disk. Layers are sexy but optional and they have nothing to do with your database data.

> 2. Specific resource requirements

The author talks about running additional processes on a database machine. Why is this an argument against containers? Maybe because containers make it somehow easier? I dunno... Yeah, don't overload your database servers with other stuff, containers aren't forcing you to do it.

> 3. Network problems

This one is the most bizarre, with statements from all over the map, basically saying "networks are hard". Riding unicycles is also hard, but that's not used as an argument against containers. Here's an obvious conclusion: if you don't feel like learning software-defined networks (or don't need the benefits they provide), then don't use them and run containers with native host networking.

> 4. State in computing environment

This port is just rambling, I do not see anything specific to reply to. If the point to make was that containers don't play nice with state, it's like saying "processes do not play nice with state" because that's what a container is: a Linux process. You have full control over where (pin it to DB machines only) and how it runs, use features you need (and understand) and don't use others.

> 5. They just don’t fit major Docker features

In this part the author is basically saying that it's easy (or easier) to install a database using configuration management tools instead of using something like Docker. True, there is more than one way to skin a cat and frankly you can use both a configuration management system and the containers. I just can't see how this can be used as an argument AGAINST anything.

> 6. Extra isolation is critical at the database layer

The author again claims the containers bring in significant overhead. That's simply not true. I would recommend to mentally replacing "container" with "process" when you read the orchestration blogs to see right through FUD. Again, you can run a container from a directory on your filesystem using host networking and it will be no different from any other process on the box. Using a network namespace does not add any measurable difference to performance. [1]

> 7. Cloud platform incompatibility

The title doesn't match the paragraph of the text that follows. The author basically claims that being provider-agnostic (one of the benefits of containers) is not valuable. Well, he's a database administrator and it's not valuable to _him_. But there's a huge business value of being able to run on different infrastructures: selling $100/mo SaaS subscriptions is nice, but when the stream of early adopters dries up and you set your aim at those nice six-figure enterprise license contracts, you may find out that you will need to be able to run on a VMware cluster in a corporate colo. And containers can help.

Containers are big not because they make developers happy, they're big because they let sophisticated companies significantly consolidate their workloads (via dynamic scheduling) and shrink their infrastructure footprints. I constantly get shocked by AWS bills people share with me and something like Kubernetes provide quite significant material value of shrinking them. But another less obvious advantage is the ability to run [1] the same SaaS stack on public and private infrastructure, opening up entirely new markets for your company. What's your revenue from China? Ever thought about containers being the perfect tool to penetrate The Firewall and run on your Chinese customer's servers? Anyway, those are good reasons to finally learn and use containers. And the reason not to? Well, not this blog post.

[1] We are https://gravitational.com and some of our customers ARE database vendors, happily running their mission critical (everyone is mission critical in our biz) workloads on containers / Kubernetes and deploying them into behind-firewall corporate clouds. So yes I am biased but I'm also qualified to respond.