[update] I spent nearly 4 hours this evening trying to get kubernetes to run the sample application. On the one hand I finally got the container running but without being able to get the client to connect. While I was drowning in 10-15 virtual machines it became clear to me that it’s not ready for primetime. It’s also clear to me that there are too many differences between host OS’ and the tools available. In some installs it was easier to use my laptop and access kubernetes via a tunnel and in some configs it was easier to use a single node. As I look at CoreOS and Fleet I wonder why I would need kuberbetes. I know that the intent is to provide a line of demarkation between the hardware and application but it’s not delivering. I might have better success with plain old Fleet and X-Fleet configuration and some sidekick configs.I’ve been experimenting (more than play and less than full-time production) with CoreOS and Docker for a number of months now. I was lucky enough to give a short workshop on both. Having to deal with the sidekick and ambassador patterns left a very bad taste in my mouth. I know that the teams are working on this but it was definitely something that makes Docker microservices less plausible.Now there are multiple frameworks that are supposed to be addressing this.Mesos+Marathon - Apache + JVM (argh!!!)Diego - Cloud Foundry (argh!!!)Kubernetes - too much alpha code (argh!!!)And then there are some libraries…rudder - virtual networking, meant for kubernetes but still alpha (argh!!!)weave - virtual networking, who are these guys?One of the dominant concerns is the container size. My next stop is looking at stackbrew for a tiny base image.