DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
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?
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.
