mirror of https://github.com/hashicorp/consul
parent
63e9369405
commit
dbeccf4642
@ -0,0 +1,45 @@
|
||||
---
|
||||
layout: "intro"
|
||||
page_title: "Consul vs. Serf"
|
||||
sidebar_current: "vs-other-serf"
|
||||
---
|
||||
|
||||
# Consul vs. Serf
|
||||
|
||||
[Serf](http://www.serfdom.io) is a service 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. In fact, the internal
|
||||
[gossip protocol](/docs/internals/gossip.html) used within Consul, is powered by
|
||||
the Serf library. Consul leverages the membership and failure detection features,
|
||||
and builds upon them.
|
||||
|
||||
The health checking provided by Serf is very low level, and only indicates if the
|
||||
agent is alive. Consul extends this to provide a rich health checking system,
|
||||
that handles liveness, in addition to arbitrary host and service-level checks.
|
||||
Health checks are integrated with a central catalog that operators can easily
|
||||
query to gain insight into the cluster.
|
||||
|
||||
The membership provided by Serf is at a node level, while Consul focuses
|
||||
on the service level abstraction, with a single node to multiple service model.
|
||||
This can be simulated in Serf using tags, but it is much more limited, and does
|
||||
not provide useful query interfaces. Consul also makes use of a strongly consistent
|
||||
Catalog, while Serf is only eventually consistent.
|
||||
|
||||
In addition to the service level abstraction and improved health checking,
|
||||
Consul provides a key/value store and support for multiple datacenters.
|
||||
Serf can run across the WAN but with degraded performance. Consul makes use
|
||||
of [multiple gossip pools](/docs/internals/architecture.html), so that
|
||||
the performance of Serf over a LAN can be retained while still using it over
|
||||
a WAN for linking together multiple datacenters.
|
||||
|
||||
Consul is also more opinionated in its usage than Serf, enabling Serf
|
||||
to be used in a wider variety of cases. Consul also uses a CP architecture,
|
||||
favoring consistency over availability. Serf is a AP system, and sacrifices consistency
|
||||
for availability. This means Consul cannot operate if the central servers cannot
|
||||
form a quorum, while Serf will continue to function under almost all circumstances.
|
||||
|
Loading…
Reference in new issue