github.com/outbrain/consul@v1.4.5/website/source/intro/vs/serf.html.md (about)

     1  ---
     2  layout: "intro"
     3  page_title: "Consul vs. Serf"
     4  sidebar_current: "vs-other-serf"
     5  description: |-
     6    Serf is a node discovery and orchestration tool and is the only tool discussed so far that is built on an eventually-consistent gossip model with no centralized servers. It provides a number of features, including group membership, failure detection, event broadcasts, and a query mechanism. However, Serf does not provide any high-level features such as service discovery, health checking or key/value storage. Consul is a complete system providing all of those features.
     7  ---
     8  
     9  # Consul vs. Serf
    10  
    11  [Serf](https://www.serf.io) is a node discovery and orchestration tool and is the only
    12  tool discussed so far that is built on an eventually-consistent gossip model
    13  with no centralized servers. It provides a number of features, including group
    14  membership, failure detection, event broadcasts, and a query mechanism. However,
    15  Serf does not provide any high-level features such as service discovery, health
    16  checking or key/value storage. Consul is a complete system providing all of those
    17  features. 
    18  
    19  The internal [gossip protocol](/docs/internals/gossip.html) used within Consul is in
    20  fact powered by the Serf library: Consul leverages the membership and failure detection
    21  features and builds upon them to add service discovery. By contrast, the discovery
    22  feature of Serf is at a node level, while Consul provides a service and node level
    23  abstraction.
    24  
    25  The health checking provided by Serf is very low level and only indicates if the
    26  agent is alive. Consul extends this to provide a rich health checking system
    27  that handles liveness in addition to arbitrary host and service-level checks.
    28  Health checks are integrated with a central catalog that operators can easily
    29  query to gain insight into the cluster.
    30  
    31  The membership provided by Serf is at a node level, while Consul focuses
    32  on the service level abstraction, mapping single nodes to multiple services.
    33  This can be simulated in Serf using tags, but it is much more limited and does
    34  not provide useful query interfaces. Consul also makes use of a strongly-consistent
    35  catalog while Serf is only eventually-consistent.
    36  
    37  In addition to the service level abstraction and improved health checking,
    38  Consul provides a key/value store and support for multiple datacenters.
    39  Serf can run across the WAN but with degraded performance. Consul makes use
    40  of [multiple gossip pools](/docs/internals/architecture.html) so that
    41  the performance of Serf over a LAN can be retained while still using it over
    42  a WAN for linking together multiple datacenters.
    43  
    44  Consul is opinionated in its usage while Serf is a more flexible and
    45  general purpose tool. In [CAP](https://en.wikipedia.org/wiki/CAP_theorem) terms,
    46  Consul uses a CP architecture, favoring consistency over availability. Serf is an
    47  AP system and sacrifices consistency for availability. This means Consul cannot
    48  operate if the central servers cannot form a quorum while Serf will continue to
    49  function under almost all circumstances.