“The distributed systems community is split between the two.”
“The distributed systems community” certainly does not describe the academic distributed systems community. Apparently it refers to some sort of pop-culture clique of programmers. For academics, Raft is just another Multi-Paxos variant among dozens.
“The distributed systems community” certainly does not describe the academic distributed systems community. Apparently it refers to some sort of pop-culture clique of programmers. For academics, Raft is just another Multi-Paxos variant among dozens.
I guess that, without further qualification, it’s an umbrella term that includes both academia and industry. I’m sure that Raft is not particularly interesting to academia, but it’s focus on (for lack of a better term) “implementability” has made it categorically different than ~all other Paxos variants for industry practitioners. That is, all evidence suggests that, for a competent engineer, it’s practically feasible to implement Raft, and difficult or infeasible to implement Paxos. With that said, I’m super excited to watch Heidi’s work play out in industry, I’m optimistic it will bridge this gap.
I disagree. The main contribution of the Raft paper was that it made explicit several implementation decisions (e.g. leader election) that are left as an “exercise for the reader” in generic descriptions of Multi-Paxos like “Paxos Made Simple”. But there are already many descriptions of Multi-Paxos, designed for implementors, that also specify these implementation decisions. I don’t perceive that these explicit descriptions of Multi-Paxos are any more difficult or confusing to implement than the Raft paper or thesis. Some examples (by no means an exhaustive list):
The main contribution of the Raft paper was that it made explicit several implementation decisions (e.g. leader election) that are left as an “exercise for the reader” in generic descriptions of Multi-Paxos like “Paxos Made Simple”.
That was indeed one of a few important properties of Raft which made it “implementable” in industry! I’d add that the overall tone or phrasing of the paper, speaking in large part to an audience of implementors rather than peer reviewers, was also super important.
But there are already many descriptions of Multi-Paxos, designed for implementors, that also specify these implementation decisions. I don’t perceive that these explicit descriptions of Multi-Paxos are any more difficult or confusing to implement than the Raft paper or thesis.
Appreciated, and I don’t necessarily disagree, but our subjective perception of the difficulty of a given protocol isn’t nearly as good a signal as the actual number of implementations in common use. And I think it’s pretty undeniable that the number of Raft implementations in the wild handily outnumber the Multi-Paxoses! That says a lot.
I wish the article had distinguished between Multi-Paxos and the Synod (single-instance) protocol. The Synod protocol is wonderfully simple yet subtle, and is surprisingly useful even though the conventional wisdom is that only Multi-Paxos is relevant to practice.
Finally, Raft’s efficient elections seem like a huge win in practice. The canonical MultiPaxos election algorithm, it seems to me, could make the system unavailable for an abitrary period while the new leader replicates missing log entries from followers. I wouldn’t deploy such a protocol without a solution to this problem.
In MultiPaxos, couldn’t followers just be removed if they are more than some number of bytes behind the leader?
Heidi is the only person I have seen explain Paxos in such a way that I actually understood it. For at least 30 minutes after she stopped talking.
“The distributed systems community” certainly does not describe the academic distributed systems community. Apparently it refers to some sort of pop-culture clique of programmers. For academics, Raft is just another Multi-Paxos variant among dozens.
I guess that, without further qualification, it’s an umbrella term that includes both academia and industry. I’m sure that Raft is not particularly interesting to academia, but it’s focus on (for lack of a better term) “implementability” has made it categorically different than ~all other Paxos variants for industry practitioners. That is, all evidence suggests that, for a competent engineer, it’s practically feasible to implement Raft, and difficult or infeasible to implement Paxos. With that said, I’m super excited to watch Heidi’s work play out in industry, I’m optimistic it will bridge this gap.
I disagree. The main contribution of the Raft paper was that it made explicit several implementation decisions (e.g. leader election) that are left as an “exercise for the reader” in generic descriptions of Multi-Paxos like “Paxos Made Simple”. But there are already many descriptions of Multi-Paxos, designed for implementors, that also specify these implementation decisions. I don’t perceive that these explicit descriptions of Multi-Paxos are any more difficult or confusing to implement than the Raft paper or thesis. Some examples (by no means an exhaustive list):
“Paxos for System Builders” http://www.dsn.jhu.edu/Paxos-SB.html
“Paxos Made Moderately Complex” https://www.cs.cornell.edu/courses/cs7412/2011sp/paxos.pdf
“Paxos Made Practical” https://www.scs.stanford.edu/~dm/home/papers/paxos.pdf
That was indeed one of a few important properties of Raft which made it “implementable” in industry! I’d add that the overall tone or phrasing of the paper, speaking in large part to an audience of implementors rather than peer reviewers, was also super important.
Appreciated, and I don’t necessarily disagree, but our subjective perception of the difficulty of a given protocol isn’t nearly as good a signal as the actual number of implementations in common use. And I think it’s pretty undeniable that the number of Raft implementations in the wild handily outnumber the Multi-Paxoses! That says a lot.
I wish the article had distinguished between Multi-Paxos and the Synod (single-instance) protocol. The Synod protocol is wonderfully simple yet subtle, and is surprisingly useful even though the conventional wisdom is that only Multi-Paxos is relevant to practice.
In MultiPaxos, couldn’t followers just be removed if they are more than some number of bytes behind the leader?