patternMinor
In a modern IaaS microservice based system is Zookeeper still a useful tool?
Viewed 0 times
zookeepersystemmicroserviceiaasbasedusefulstillmoderntool
Problem
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?
Are there better ways to handle feature toggles and centralized configuration settings for multiple environments using a more modern (aka serverless style) system?
Solution
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.
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.
Context
StackExchange DevOps Q#3462, answer score: 3
Revisions (0)
No revisions yet.