I wasn't picking on ZK in particular. I was more pointing out that the system as a whole is complicated. It might be fine for "enterprise deployments" where a c

I wasn't picking on ZK in particular. I was more pointing out that the system as a whole is complicated. It might be fine for "enterprise deployments" where a company has a lot of time, money and resources to throw at the implementation. In my opinion the average end user is going to get lost in the details of how these systems interconnect and work together. Debugging some of the more complex issues that they will face will be challenging. Even Exhibitor is not a silver bullet for managing ZK. It helps with rolling restarts and lets you do a sort of MySQL-esque bin-log replay of your state, but even with Exhibitor, it's not going to make for a smooth recovery at 4:00AM when PagerDuty rings. The underlying design of how Mesos and Marathon communicate create situations where they have differing views of the state of the cluster, and you end up with "orphans" which are tasks that Mesos is aware of but Marathon knows nothing about. In my opinion, the system feels like it was designed to be something else, and then all this functionality was tacked on later. Coincidentally that is exactly what the case is with Mesos. I think there is a lot of room for an improved user experience that these tools will struggle to provide.