I've used zookeeper before as a configuration management service to keep track of application settings, feature toggles etc. However, that was back in the day before microservices and AWS/Azure/GCP. Since zookeeper tends to need multiple VMs to operate, is it still a good tool in the modern ecosystem?

Are there better ways to handle feature toggles and centralized configuration settings for multiple environments using a more modern (aka serverless style) system?

  • 1
    TBH most use cases of Zookeeper could be met with Redis these days
    – Gaius
    Nov 7 '18 at 21:43

It's difficult to say whether other tools will be better if there is nothing really concrete to measure against. A good, partially biased answer comes from Hashicorp's Consul

This seems to describe why Consul would be inherently better than Zookeeper, from the point of view of ease of use:

ZooKeeper et al. provide only a primitive K/V store and require that application developers build their own system to provide service discovery. Consul, by contrast, provides an opinionated framework for service discovery and eliminates the guess-work and development effort

... scalability:

ZooKeeper provides ephemeral nodes which are K/V entries that are removed when a client disconnects. These are more sophisticated than a heartbeat system but still have inherent scalability issues and add client-side complexity. All clients must maintain active connections to the ZooKeeper servers and perform keep-alives.

... and simplicity :

Consul provides first-class support for service discovery, health checking, K/V storage, and multiple datacenters. To support anything more than simple K/V storage, all these other systems require additional tools and libraries to be built on top. By using client nodes, Consul provides a simple API that only requires thin clients. Additionally, the API can be avoided entirely by using configuration files and the DNS interface to have a complete service discovery solution with no development at all.

It does not address the need for extra resources, but since the architecture is different, I would assume the need for resources is also less:

Instead of only having server nodes, Consul clients run on every node in the cluster.

Hope this can provide some form of answer.

  • Does this mean you would need a Consol running as a sidecar in each pod in K8S?
    – avi
    Nov 7 '18 at 14:54
  • 1
    This is possible, but doesn't have to be done as such. The Consul documentation goes through the options. Nov 7 '18 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.