Alternatives to Zookeeper logo

Alternatives to Zookeeper

Consul, etcd, Yarn, Eureka, and Ambari are the most popular alternatives and competitors to Zookeeper.
594
749
+ 1
40

What is Zookeeper and what are its top alternatives?

A centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications.
Zookeeper is a tool in the Open Source Service Discovery category of a tech stack.

Top Alternatives to Zookeeper

  • Consul

    Consul

    Consul is a tool for service discovery and configuration. Consul is distributed, highly available, and extremely scalable. ...

  • etcd

    etcd

    etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines. It’s open-source and available on GitHub. etcd gracefully handles master elections during network partitions and will tolerate machine failure, including the master. ...

  • Yarn

    Yarn

    Yarn caches every package it downloads so it never needs to again. It also parallelizes operations to maximize resource utilization so install times are faster than ever. ...

  • Eureka

    Eureka

    Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers. ...

  • Ambari

    Ambari

    This project is aimed at making Hadoop management simpler by developing software for provisioning, managing, and monitoring Apache Hadoop clusters. It provides an intuitive, easy-to-use Hadoop management web UI backed by its RESTful APIs. ...

  • Kafka

    Kafka

    Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design. ...

  • Redis

    Redis

    Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets. ...

  • Kubernetes

    Kubernetes

    Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. ...

Zookeeper alternatives & related posts

Consul logo

Consul

978
1.2K
203
A tool for service discovery, monitoring and configuration
978
1.2K
+ 1
203
PROS OF CONSUL
  • 59
    Great service discovery infrastructure
  • 35
    Health checking
  • 27
    Distributed key-value store
  • 25
    Monitoring
  • 23
    High-availability
  • 11
    Web-UI
  • 10
    Token-based acls
  • 6
    Gossip clustering
  • 5
    Dns server
  • 1
    Not Java
  • 1
    Docker integration
CONS OF CONSUL
    Be the first to leave a con

    related Consul posts

    John Kodumal

    As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.

    We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.

    See more

    Since the beginning, Cal Henderson has been the CTO of Slack. Earlier this year, he commented on a Quora question summarizing their current stack.

    Apps
    • Web: a mix of JavaScript/ES6 and React.
    • Desktop: And Electron to ship it as a desktop application.
    • Android: a mix of Java and Kotlin.
    • iOS: written in a mix of Objective C and Swift.
    Backend
    • The core application and the API written in PHP/Hack that runs on HHVM.
    • The data is stored in MySQL using Vitess.
    • Caching is done using Memcached and MCRouter.
    • The search service takes help from SolrCloud, with various Java services.
    • The messaging system uses WebSockets with many services in Java and Go.
    • Load balancing is done using HAproxy with Consul for configuration.
    • Most services talk to each other over gRPC,
    • Some Thrift and JSON-over-HTTP
    • Voice and video calling service was built in Elixir.
    Data warehouse
    • Built using open source tools including Presto, Spark, Airflow, Hadoop and Kafka.
    Etc
    See more
    etcd logo

    etcd

    225
    302
    23
    A distributed consistent key-value store for shared configuration and service discovery
    225
    302
    + 1
    23
    PROS OF ETCD
    • 11
      Service discovery
    • 6
      Fault tolerant key value store
    • 2
      Bundled with coreos
    • 1
      Open Source
    • 1
      Privilege Access Management
    • 1
      Secure
    • 1
      Consol integration
    CONS OF ETCD
      Be the first to leave a con

      related etcd posts

      Yarn logo

      Yarn

      11.3K
      7.7K
      141
      A new package manager for JavaScript
      11.3K
      7.7K
      + 1
      141
      PROS OF YARN
      • 84
        Incredibly fast
      • 21
        Easy to use
      • 12
        Open Source
      • 10
        Can install any npm package
      • 7
        Works where npm fails
      • 5
        Workspaces
      • 2
        Incomplete to run tasks
      CONS OF YARN
      • 15
        Facebook
      • 6
        Sends data to facebook
      • 3
        Should be installed separately
      • 2
        Cannot publish to registry other than npm

      related Yarn posts

      Simon Reymann
      Senior Fullstack Developer at QUANTUSflow Software GmbH · | 24 upvotes · 1.7M views

      Our whole Node.js backend stack consists of the following tools:

      • Lerna as a tool for multi package and multi repository management
      • npm as package manager
      • NestJS as Node.js framework
      • TypeScript as programming language
      • ExpressJS as web server
      • Swagger UI for visualizing and interacting with the API’s resources
      • Postman as a tool for API development
      • TypeORM as object relational mapping layer
      • JSON Web Token for access token management

      The main reason we have chosen Node.js over PHP is related to the following artifacts:

      • Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
      • Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
      • A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
      • Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.
      See more
      Johnny Bell
      Software Engineer at Weedmaps · | 19 upvotes · 1.2M views

      So when starting a new project you generally have your go to tools to get your site up and running locally, and some scripts to build out a production version of your site. Create React App is great for that, however for my projects I feel as though there is to much bloat in Create React App and if I use it, then I'm tied to React, which I love but if I want to switch it up to Vue or something I want that flexibility.

      So to start everything up and running I clone my personal Webpack boilerplate - This is still in Webpack 3, and does need some updating but gets the job done for now. So given the name of the repo you may have guessed that yes I am using Webpack as my bundler I use Webpack because it is so powerful, and even though it has a steep learning curve once you get it, its amazing.

      The next thing I do is make sure my machine has Node.js configured and the right version installed then run Yarn. I decided to use Yarn because when I was building out this project npm had some shortcomings such as no .lock file. I could probably move from Yarn to npm but I don't really see any point really.

      I use Babel to transpile all of my #ES6 to #ES5 so the browser can read it, I love Babel and to be honest haven't looked up any other transpilers because Babel is amazing.

      Finally when developing I have Prettier setup to make sure all my code is clean and uniform across all my JS files, and ESLint to make sure I catch any errors or code that could be optimized.

      I'm really happy with this stack for my local env setup, and I'll probably stick with it for a while.

      See more
      Eureka logo

      Eureka

      233
      563
      65
      AWS Service registry for resilient mid-tier load balancing and failover.
      233
      563
      + 1
      65
      PROS OF EUREKA
      • 20
        Easy setup and integration with spring-cloud
      • 8
        Web ui
      • 8
        Health checking
      • 7
        Circuit breaker
      • 6
        Netflix battle tested components
      • 6
        Service discovery
      • 6
        Monitoring
      • 4
        Open Source
      CONS OF EUREKA
        Be the first to leave a con

        related Eureka posts

        Ambari logo

        Ambari

        31
        45
        1
        A software for provisioning, managing, and monitoring Apache Hadoop clusters
        31
        45
        + 1
        1
        PROS OF AMBARI
        • 1
          Ease of use
        CONS OF AMBARI
          Be the first to leave a con

          related Ambari posts

          Kafka logo

          Kafka

          13.9K
          13.1K
          562
          Distributed, fault tolerant, high throughput pub-sub messaging system
          13.9K
          13.1K
          + 1
          562
          PROS OF KAFKA
          • 120
            High-throughput
          • 114
            Distributed
          • 86
            Scalable
          • 79
            High-Performance
          • 64
            Durable
          • 35
            Publish-Subscribe
          • 18
            Simple-to-use
          • 14
            Open source
          • 10
            Written in Scala and java. Runs on JVM
          • 6
            Message broker + Streaming system
          • 4
            Avro schema integration
          • 2
            Suport Multiple clients
          • 2
            Robust
          • 2
            KSQL
          • 2
            Partioned, replayable log
          • 1
            Fun
          • 1
            Extremely good parallelism constructs
          • 1
            Simple publisher / multi-subscriber model
          • 1
            Flexible
          CONS OF KAFKA
          • 27
            Non-Java clients are second-class citizens
          • 26
            Needs Zookeeper
          • 7
            Operational difficulties
          • 2
            Terrible Packaging

          related Kafka posts

          Eric Colson
          Chief Algorithms Officer at Stitch Fix · | 21 upvotes · 1.9M views

          The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.

          Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).

          At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.

          For more info:

          #DataScience #DataStack #Data

          See more
          John Kodumal

          As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.

          We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.

          See more
          Redis logo

          Redis

          38.3K
          28.1K
          3.9K
          An in-memory database that persists on disk
          38.3K
          28.1K
          + 1
          3.9K
          PROS OF REDIS
          • 877
            Performance
          • 535
            Super fast
          • 511
            Ease of use
          • 442
            In-memory cache
          • 321
            Advanced key-value cache
          • 190
            Open source
          • 179
            Easy to deploy
          • 163
            Stable
          • 153
            Free
          • 120
            Fast
          • 40
            High-Performance
          • 39
            High Availability
          • 34
            Data Structures
          • 32
            Very Scalable
          • 23
            Replication
          • 20
            Great community
          • 19
            Pub/Sub
          • 17
            "NoSQL" key-value data store
          • 14
            Hashes
          • 12
            Sets
          • 10
            Sorted Sets
          • 9
            Lists
          • 8
            BSD licensed
          • 8
            NoSQL
          • 7
            Async replication
          • 7
            Integrates super easy with Sidekiq for Rails background
          • 7
            Bitmaps
          • 6
            Open Source
          • 6
            Keys with a limited time-to-live
          • 5
            Strings
          • 5
            Lua scripting
          • 4
            Awesomeness for Free!
          • 4
            Hyperloglogs
          • 3
            outstanding performance
          • 3
            Runs server side LUA
          • 3
            Networked
          • 3
            LRU eviction of keys
          • 3
            Written in ANSI C
          • 3
            Feature Rich
          • 3
            Transactions
          • 2
            Data structure server
          • 2
            Performance & ease of use
          • 1
            Existing Laravel Integration
          • 1
            Automatic failover
          • 1
            Easy to use
          • 1
            Object [key/value] size each 500 MB
          • 1
            Simple
          • 1
            Channels concept
          • 1
            Scalable
          • 1
            Temporarily kept on disk
          • 1
            Dont save data if no subscribers are found
          • 0
            Jk
          CONS OF REDIS
          • 12
            Cannot query objects directly
          • 1
            No WAL
          • 1
            No secondary indexes for non-numeric data types

          related Redis posts

          Robert Zuber

          We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.

          As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).

          When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.

          See more

          I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.

          We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.

          Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis  for cache and other time sensitive operations.

          We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.

          Since we have different frontend apps we have found useful to have Bit to document visual components and utils in JavaScript.

          See more
          Kubernetes logo

          Kubernetes

          33.9K
          28.4K
          601
          Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops
          33.9K
          28.4K
          + 1
          601
          PROS OF KUBERNETES
          • 152
            Leading docker container management solution
          • 121
            Simple and powerful
          • 96
            Open source
          • 73
            Backed by google
          • 56
            The right abstractions
          • 24
            Scale services
          • 17
            Replication controller
          • 9
            Permission managment
          • 6
            Simple
          • 5
            Supports autoscaling
          • 5
            Cheap
          • 3
            Reliable
          • 3
            No cloud platform lock-in
          • 3
            Self-healing
          • 3
            Open, powerful, stable
          • 3
            Scalable
          • 3
            Promotes modern/good infrascture practice
          • 2
            Cloud Agnostic
          • 2
            Backed by Red Hat
          • 2
            Custom and extensibility
          • 2
            Quick cloud setup
          • 2
            Captain of Container Ship
          • 2
            A self healing environment with rich metadata
          • 1
            Everything of CaaS
          • 1
            Easy setup
          • 1
            Expandable
          • 1
            Runs on azure
          • 1
            Sfg
          • 1
            Golang
          • 1
            Gke
          CONS OF KUBERNETES
          • 13
            Poor workflow for development
          • 11
            Steep learning curve
          • 5
            Orchestrates only infrastructure
          • 2
            High resource requirements for on-prem clusters

          related Kubernetes posts

          Conor Myhrvold
          Tech Brand Mgr, Office of CTO at Uber · | 38 upvotes · 3.7M views

          How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

          Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

          Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

          https://eng.uber.com/distributed-tracing/

          (GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

          Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

          See more
          Yshay Yaacobi

          Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

          Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

          After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

          See more