If you're going to call something half-assed because it's not HAProxy then I for one would consider it more productive if this was framed in terms of metrics instead of something like "half-assed." Does HAProxy have a suite of metrics that can serve as benchmarks for all the projects out there that would dare to be less half-assed?
Why didn't you ask the question the other way around -- does vulcand have anything to show that it is better in any way than the current best-practice load balancer?
Reading the docs, the only thing that stands out is that it's tightly coupled with etcd, which seems like a really bad idea architecturally.
I'm wondering why do you think that tightly coupling with Etcd is a bad idea?
Etcd provides advanced features for configuration and service discovery - serialized updates, high availability and ttls for keys that's why it was a reasonable choice for me to use it and not file system that does not provide any of the above features out of the box.
One of the main reasons I wrote Vulcand is for experimentation - what would be the next steps for proxy and load balancing out there?
One of the ideas - having a proxy that will embrace the dynamic nature of the Docker enabled backends an provide full support for rapidly changing dockerized landscape.
Another idea is to try out some ideas in error recovery/failure detection algos, like preventing cascading failures:
I don't pretend that Vulcand is somewhat robust and everyone should immediately drop their HAProxy/Nginx solutions and start using Vulcand. I hoped that would be clear from the README and is highlighted in Rob's post as well.
In fact, I'm using Vulcand as well as Nginx and HAproxy, I'm just choosing carefully when should I use one load balancer vs another.
First, let me say up front that I value your verve and appreciate your desire to experiment and learn and push frontiers. Bravo on all that.
The problem with tight coupling -- especially across concerns and software layers, as with 'etcd -> load balancer' -- is that it's an immediate withdrawal from the great Bank of Technical Debt.
Some time in the future, one of the following things will happen:
1. Etcd will want to perform one unit of positive technical change, and either that behavior will break your code, or you will be forced to fork versions, or etcd will be forced not to make that change by the popularity of your code.
2. You will want to perform one unit of positive technical change, but etcd will, for whatever political, architectural, or technical reason not wish to support this change. You will either abandon your idea for lack of upstream technical support or be forced to fork etcd.
The neglect of these incredibly common occurrences is itself now incredibly common. It underpins, e.g., systemd development, which in turn appears to be informing coreos and docker development, and since those are the new-shiny-toys, a lot of people seem to think that's just the way we should all think now, that the 'unix philosophy' is ripe for disruption(tm).
Problem is, invariably, coupling turns out to be the most important artifact in all of computer science. It's worse than naming things, it's worse than cache invalidation, it's worse than off-by-one errors. And the worst kind of coupling is the kind of coupling that crosses stack boundaries for no obviously good reason, because the amount and kind of reasoning that has to happen at an operational level when that stops working in production is both severe and very difficult to resolve.
So again: applaud the desire to learn, and experiment. The coupling: please, please don't. The marketing of a test solution as something to consider using: you don't need that to build your portfolio, just put the project up and say it's a test thing. And preventing cascading failures with weighted round robin, etc: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html...
