4 ms·

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 - seriali

by alexk 12y ago

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: http://mailgun.github.io/vulcan-docs/#weighted-round-robin http://mailgun.github.io/vulcan-docs/#weighted-round-robin 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.

felixgallo 12y ago
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#4.2-balance%20url_param http://cbonte.github.io/haproxy-dconv/configuration-1.5.html...

by alexk 12y ago

felixgallo 12y ago

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#4.2-balance%20url_param http://cbonte.github.io/haproxy-dconv/configuration-1.5.html...