Have to say consul is one of the most useful tools for service discovery i've ever used. Only feature I want is better support for multiple environments in the same cluster set.
I've released the latest .NET API too for the dozens of us that use .NET with Consul. It features full (.NETStandard 1.3) support of Core in this version! https://www.nuget.org/packages/Consul/0.7.0
Consul combined with consul-template for dynamic config changes in your environment is an extremely powerful solution which just works with minimum fuss.
Works well when deploying clusters such as zookeeper, allows all the nodes to discover each other automatically and work out their id number.
There's lots of software you might operate that requires zookeeper: kafka, solrcloud, the hadoop ecosystem, etc.
Meanwhile, consul has lots of functionality built in that makes it a snap to use for service discovery within your existing infrastructure. You would have to build all this yourself on top of zookeeper, which just provides a distributed, consistent key-value store.
So it's easy to see why you could end up with both.
You can run Fabio alongside the Consul agent on each node in your cluster and point all your apps to localhost:9999. That way you don't have to manage a central cluster of Fabio instances and if a node dies you just lose the Fabio instance on that host, which was only being used by that host.
Yes I meant something different. Generally with a load balancer the load balancer hosts that VIP(s) that your public facing DNS A records resolve to. In order to avoid a single point of failure you employ things like keepalived or ECMP/BGP etc.
The general setup seems to be that you have a public facing LB which just forwards all incoming traffic to any available fabio instance which handles the dynamic routing. fabio does not solve the public VIP problem for you.
Glad to see both etcd and consul support changing multiple keys atomically which I think is a critical feature.
Has someone recently compared the two in production?
Both projects have made some bigger changes in their Raft implementation since the last Jepsen test. I'd love for Kyle to re-do the test and also take into account the transaction feature.
The new Lifeguard feature looks really neat. False monitoring alarms are a big issue. If they happen a lot you begin to not trust a real alarm and ignore them - the boy who cried wolf as the cliche goes.
