website: Adding the Serf comparison
This commit is contained in:
parent
2a8cc6f312
commit
019e2d6ece
45
website/source/intro/vs/serf.html.markdown
Normal file
45
website/source/intro/vs/serf.html.markdown
Normal file
|
@ -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 a new issue