4 ms·

This is why top-down, single-source of truth is mostly the best way for core infrastructure. No pun intended. It's important for some parts to not be infinite

by ballard 13y ago

This is why top-down, single-source of truth is mostly the best way for core infrastructure. No pun intended. It's important for some parts to not be infinitely reconfigurable or dynamic because it would create chaos and service dependency deadlock/DoS. Most people not running bare metal don't know the lessons of how and why things underneath are they way they are and the sensible limits what's possible. It's also more secure because if it's possible to dictate all of the service details, it's much easier to run a lean and locked-down infrastructure. CoreOS by itself looks great. More JEOS distros need to happen. Trying to bundle more unproven things just looks marketing led the product.

nl 13y ago
This is why top-down, single-source of truth is mostly the best way for core infrastructure. What happens when your single source of truth goes down? etcd attempts to provide a source of truth by using the Raft[1] consensus algorithm to determine that "truth" in an environment when relying on merely one place is too risky. Th Raft and Paxos[2] (as used in Zookeeper & Google Chubby) algorithms give guarantees for consensus in an environment with unreliable hardware. That is better than a single source of truth where you get nothing when that source disappears. [1] http://raftconsensus.github.io/ http://raftconsensus.github.io/ [2] http://en.wikipedia.org/wiki/Paxos_(computer_science) http://en.wikipedia.org/wiki/Paxos_(computer_science)
vidarh 13y ago
> This is why top-down, single-source of truth is mostly the best way for core infrastructure. "Top-down, single-source of truth" needs to deal with failover for resilience in any serious setup. The entire point of consensus algorithms like Raft (and Zab, since you've mentioned ZooKeeper) is that they provide a method of providing a consistent source of truth that is resilient without the management overhead. It's explicitly because top-down solutions are a massive hassle to keep consistent and available in the face of stalled replication (OpenLDAP.... DNS based solutions...) or a failed master. > It's important for some parts to not be infinitely reconfigurable or dynamic because it would create chaos and service dependency deadlock/DoS. That is entirely irrelevant to the algorithm used to replicate the configuration information. > It's also more secure because if it's possible to dictate all of the service details, it's much easier to run a lean and locked-down infrastructure. Why exactly do you believe that it is not "possible to dictate all of the service details" while using Etcd? To me it's an entirely orthogonal issue.

by ballard 13y ago

nl 13y ago

This is why top-down, single-source of truth is mostly the best way for core infrastructure. What happens when your single source of truth goes down? etcd attempts to provide a source of truth by using the Raft[1] consensus algorithm to determine that "truth" in an environment when relying on merely one place is too risky. Th Raft and Paxos[2] (as used in Zookeeper & Google Chubby) algorithms give guarantees for consensus in an environment with unreliable hardware. That is better than a single source of truth where you get nothing when that source disappears. [1] http://raftconsensus.github.io/ http://raftconsensus.github.io/ [2] http://en.wikipedia.org/wiki/Paxos_(computer_science) http://en.wikipedia.org/wiki/Paxos_(computer_science)

vidarh 13y ago

> This is why top-down, single-source of truth is mostly the best way for core infrastructure. "Top-down, single-source of truth" needs to deal with failover for resilience in any serious setup. The entire point of consensus algorithms like Raft (and Zab, since you've mentioned ZooKeeper) is that they provide a method of providing a consistent source of truth that is resilient without the management overhead. It's explicitly because top-down solutions are a massive hassle to keep consistent and available in the face of stalled replication (OpenLDAP.... DNS based solutions...) or a failed master. > It's important for some parts to not be infinitely reconfigurable or dynamic because it would create chaos and service dependency deadlock/DoS. That is entirely irrelevant to the algorithm used to replicate the configuration information. > It's also more secure because if it's possible to dictate all of the service details, it's much easier to run a lean and locked-down infrastructure. Why exactly do you believe that it is not "possible to dictate all of the service details" while using Etcd? To me it's an entirely orthogonal issue.