We have built some tools for port discovery (talking to mesos to figure out what port service Y is built on), but even with all our tools, we recently did a complete cloud migration (to GCP), and it was easy as backing up and deploying Zookeeper on the new nodes. Once the slaves were up, everything was running as if nothing changed in under an hour.
Disclosure: I work at Google on Kubernetes.
I agree 100% Kube answers everything I am missing with mesos/marathon combination, that's why I am planning to start moving over new services.
It's just a matter of my personal comfort, I like to use isolated services that just use messaging and fire a message when their done with their role.
Even if Kube handles everything perfectly, it's still harder to maintain application with inner-service communication, hard to follow problems/errors/stack traces etc...
However, I'm using mesos, marathon and chronos to manage a production environment with service discovery glue based on Route53.
Using Docker to ship an application to a well configured environment is just a delight, the amount of configuration needed is absolutely minimal.
However, I think people need to realize that it's "easy" if your services are not talking to each other and dependent on one another in a way. If service X is using service Y directly (via HTTP), it gets a bit more challenging.
The way I like to configure micro-service is based on messaging so you send a message to a queue and multiple satellite services can consume that message and do stuff with it.
If your services are dependent on one another, the configuration gets trickier and the maintenance gets a bit harder.
Good job by Box also contributing back to the core of Kube based on what they needed, based on it getting merged I am guessing other people will find it useful as well.