<p>It's difficult to say whether other tools will be <em>better</em> if there is nothing really concrete to measure against. A good, partially biased answer comes from <a href="https://www.consul.io/intro/vs/zookeeper.html" rel="nofollow noreferrer">Hashicorp's Consul</a></p>

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

<blockquote>
  <p>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</p>
</blockquote>

<p>... scalability:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>... and simplicity : </p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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: </p>

<blockquote>
  <p>Instead of only having server nodes, Consul clients run on every node in the cluster.</p>
</blockquote>

<p>Hope this can provide some form of answer.</p>

CC BY-SA 4.0
2018-11-07T14:54:38.890Z
Does this mean you would need a Consol running as a sidecar in each pod in K8S?
avi
CC BY-SA 4.0
2018-11-07T14:58:31.347Z
This is possible, but doesn't have to be done as such. The [Consul documentation](https://www.consul.io/docs/platform/k8s/index.html) goes through the options.
Bruce Becker
CC BY-SA 4.0
2018-11-07T14:37:30.430Z
2018-11-07T14:37:30.430Z
Bruce Becker
<p>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?</p>

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

CC BY-SA 4.0
2018-11-07T21:43:01.130Z
TBH most use cases of Zookeeper could be met with Redis these days
Gaius
<configuration-management><zookeeper>
In a modern IaaS microservice based system is Zookeeper still a useful tool?
avi
# In a modern IaaS microservice based system is Zookeeper still a useful tool?

(Asked by: username_0 on 2018-02-27)

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?

**Tags:** configuration-management, zookeeper

> **Comments:**
> **username_1**: TBH most use cases of Zookeeper could be met with Redis these days  

---

## 1 answers

### Answer by username_2 on 2018-11-07. Score: 3

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](https://www.consul.io/intro/vs/zookeeper.html)

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 husername_0ng server nodes, Consul clients run on every node in the cluster.

Hope this can provide some form of answer.

> **Comments:**
> **username_0**: Does this mean you would need a Consol running as a sidecar in each pod in K8S?  
> **username_2**: This is possible, but doesn't have to be done as such. The [Consul documentation](https://www.consul.io/docs/platform/k8s/index.html) goes through the options.  

---

