>> ... and I need none of Dockers scaling properties, so I'll run it direct on hardware. What is not "direct on hardware" about Docker containers? There's a bi

>> ... and I need none of Dockers scaling properties, so I'll run it direct on hardware. What is not "direct on hardware" about Docker containers? There's a bit of a misunderstanding here, and I wouldn't nitpick on it if I didn't think it betrayed something about the author's point. In some way or other he sees Docker as additional overhead, like a VM. While there obviously is _some_ overhead this isn't an accurate picture. As for the overall point of doing everything in a container, according to various sources that is exactly what Google does now, for example. The reason is that containers capture dependencies, and they make for much more fluid and manageable systems. As with most changes of this magnitude there are waves of adulation and revulsion, but overall I think this is the new world. On the elasticsearch point: you can use environment variables inside the elasticsearch.yml file, and you can set environment variables inside a container when you execute it so there is a complete pathway to pipe configuration information into the container. There are really only two things that cause an issue: discovery and disk volumes. Discovery is a problem because es uses udp multicast by default, but there are plugins that substitute other mechanisms for listing cluster members. On kubernetes/GKE we use a fabric8 plugin for this. Disk volumes are an issue just because most container platforms don't yet deal well with them. We had to roll our own solution for dynamically attaching replication controllers to GCE persistent disks, but there are some better solutions in the release pipe.