In the past twelve months I have had the privilege of working across more than a half-dozen teams building digital services. It was interesting that only one of them was attempting to do estimates and it wasn’t clear to anyone, let alone them, exactly why they were attempting it. In this post I will sketch out how a successful large scale team abandoned estimations entirely. Read the rest of this entry »
The year 2016 turned out to be a bumper year for pragmatic Paxos discoveries. Hot on the heels of the FPaxos discovery of more flexible quorums comes Unbounded Pipelining in Dynamically Reconfigurable Paxos Clusters or “UPaxos”. This uses overlapping quorums between consecutive cluster configurations, and a leader “casting vote”, to enable cluster reconfigurations in a non-stop manner even when reconfiguration messages are lost. Read the rest of this entry »
In a previous post I covered using the Paxos engine itself to do cluster reconfiguration as per the 2001 Paxos Made Simple paper. In this post I will cover a problem with that technique know as pipeline stalls. This post is to set the scene for a new technical report published 2016 which fixes the problem with a state-of-the-art Paxos implementation called UPaxos. Read the rest of this entry »
Today’s Morning Paper on “Just say NO to Paxos overhead: replacing consensus with network ordering” was a thrilling disappointment. It’s always with both excitement and trepidation I read about new developments in distributed consensus; is today the day that I learn that Paxos is obsolete? The NOPaxos paper (“network ordered Paxos”) reviewed at the link above has a title which suggests a breakthrough. Unfortunately, it has far less general applicability, and far higher economic cost to implement, than “vanilla” Paxos.
Today’s Morning Paper post is a must read for software engineers: “Designing software for ease of extension and contraction Parnas, IEEE Transactions on Software Engineering, 1979″
When the Agile Manifesto came out in 2001 I was working at a DotCom in the City Of London and missed the memo. In a small startup, with only a few developers, working directly for clients, there wasn’t much scope for any big process waterfall. Oh the good o’ days. Me, the code, the client and the ‘puters in that order. Honour and glory were assured… Read the rest of this entry »
The “Morning Paper” blog has some fascinating insights into critical production failures in distributed data-intensive databases such as Cassandra and HBase. This reveals that simple testing can prevent most critical failures. In this blog post we take a quick look to see what an embeddable Paxos algorithm project such as Trex can learn from this study. Read the rest of this entry »
Up until 2016, it was well understood that the optimal size for typical Paxos clusters is three or five nodes. With typical replication workloads, it was known that four or six nodes clusters are no better, and in fact worse, than having one less node. The FPaxos “Flexible Paxos” paper changes the rules of the consensus game with the “even nodes” optimisation. Read the rest of this entry »
2016 has turned out to be a great year for Paxos with the discovery of a more flexible Paxos known as FPaxos. Only a simple change was required to the TRex paxos JVM library to support this new discovery. You can now supply a pluggable QuorumStraregy which can do things like “grid consensus”. The code on the master branch now has a default strategy which does the “even nodes” optimisation. Enjoy!