There is now a sketch (hack!) demoing the happy path flow of a UPaxos reconfiguration written up on the TRex wiki.
A good friend of mine is working on a project which hosts media libraries in his cloud service. At the end of 2015, I integrated Cassandra into a big financial services platform. Cassandra is a great fit for my friend’s service. In this post, I will outline an appropriate Cassandra data model and along the way outline some of the killer features of Cassandra. Read the rest of this entry »
In my last couple of posts, I gave an example of a successful agile team that didn’t do estimates, then made the case that estimation is aligned to “wagile” ways of working. This post is going to make the case that the approach is fundamentally flawed when viewed as a measurement activity.
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 which we will discuss in the next post. 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″