What strange reasoning, and I'm not sure if I read it right. What his argument sounded like to me is "Containers don't work for my CRUD application" which to me sounds like "Jet Engines don't work on my bicycle".<p>><i>Scaling databases with high write volumes is a somewhat unsolved problem in Computer Science. </i><p>Databases like Cassandra & hbase say otherwise - and may even be a good fit for containers. Given that these databases are Eventually consistent, you could spin up a machine, have the other nodes stream data to it, then kill it when you are done. Need a cluster to run analytics on? Spin up a couple machines, then destroy it when finished. The fact that MongoDB isn't a good fit for containers is an incredibly narrow view.<p>On the topic of narrow views, what about all the other nodes people are running that aren't CRUD applications? ETL servers (Hadoop, Spark), Event Processing (Kafka, Spark Streaming, Storm), and all the other buzzwords (microservices).<p>I guess you can say, if you have a CRUD app, yes, your infrastructure issues are solved and Docker, Rocket, CoreOS, Mesos aren't for you.<p>><i>As a final thought: once your system gets big enough, you will eventually have to do automated service discovery. This necessitates automated discovery of container hosts themselves and that’s another place where you need a stateful system that is not ephemeral and can be configured automatically.</i><p>MesosDns does this quite nicely. You ship your containers via Marathon/Aurora/Framework of choice, and those run on some machines somewhere, and are tracked by Mesos. MesosDns queries Mesos and and all your services are available as `service.framework.mesos`