Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Reaching reliable
agreement in an unreliable
world
Heidi Howard
heidi.howard@cl.cam.ac.uk
@heidiann
Research Students Lect...
Introducing Alice
Alice is new graduate from
Cambridge off to the world of
work.
She joins a cool new start up,
where she ...
Single Server System
Server
Client 2
A 7
B 2
Client 1 Client 3
3
Single Server System
Server
Client 2
A 7
B 2
Client 1 Client 3
A?
7
4
Single Server System
Server
Client 2
A 7
B 2
Client 1 Client 3
B=3 OK
3
5
Single Server System
Server
Client 2
A 7
B 2
Client 1 Client 3
B?
3
3
6
Single Server System
Pros
• linearizable semantics
• durability with write-ahead
logging
• easy to deploy
• low latency (1...
Backups
aka Primary backup replication
Primary
Client 2
Client 1
Backup 1
Backup 1
Backup 1
A 7
B 2
A?
7
A 7
B 2
A 7
B 2
A...
Backups
aka Primary backup replication
Primary
Client 2
Client 1
Backup 1
Backup 1
Backup 1
A 7
B 1
B=1
A 7
B 2
A 7
B 2
A ...
Backups
aka Primary backup replication
Primary
Client 2
Client 1
Backup 1
Backup 1
Backup 1
A 7
B 1
OK
A 7
B 1
A 7
B 1
A 7...
Big Gotcha
We are assuming total ordered broadcast
11
Totally Ordered Broadcast
(aka atomic broadcast) the guarantee that messages
are received reliably and in the same order b...
Requirements
• Scalability - High throughout processing of
operations.
• Latency - Low latency commit of operation as
perc...
Doing the Impossible
14
CAP Theorem
Pick 2 of 3:
• Consistency
• Availability
• Partition tolerance
Proposed by Brewer in 1998, still debated and
...
FLP Impossibility
It is impossible to guarantee consensus when
messages may be delay if even one node may fail.
[JACM’85]
...
Consensus is impossible
[PODC’89]
Nancy Lynch
17
Aside from Simon PJ
Don’t drag your reader or listener
through your blood strained
path.
Simon Peyton Jones
18
Paxos
Paxos is at the foundation of (almost)
all distributed consensus protocols.
It is a general approach of using two
ph...
Beyond Paxos
• Replication techniques - mapping a consensus algorithm to a fault
tolerance system
• Classes of operations ...
Consensus is hard
21
A raft in the sea of
confusion
22
Case Study: Raft
Raft is the understandable replication algorithm.
Provides linearisable client semantics, 1 RTT best
case...
State Machine Replication
Server
Client
ServerServer A 7
B 2
A 7
B 2
A 7
B 2
B=3
24
State Machine Replication
Server
Client
ServerServer A 7
B 2
A 7
B 2
A 7
B 2
B=3
25
State Machine Replication
Server
Client
ServerServer A 7
B 2
A 7
B 2
A 7
B 2
B=3
3
3 3
26
Leadership
Follower Candidate Leader
Startup/
Restart
Timeout Win
Timeout
Step down
27
Step down
Ordering
Each node stores is own perspective on a value
known as the term.
Each message includes the sender’s term and thi...
Ordering
29
ID: 1
ID: 2
ID: 3
1
1
1
2
2 2
2
ID: 1
Term: 0
Vote: n
ID: 2
Term: 0
Vote: n
ID: 5
Term: 0
Vote: n
ID: 4
Term: 0
Vote: n
ID: 3
Term: 0
Vote: n
30
Leadership
Follower Candidate Leader
Startup/
Restart
Timeout Win
Timeout
Step down
31
Step down
ID: 1
Term: 0
Vote: n
ID: 2
Term: 0
Vote: n
ID: 5
Term: 0
Vote: n
ID: 4
Term: 1
Vote: me
ID: 3
Term: 0
Vote: n
Vote for me...
ID: 1
Term: 1
Vote: 4
ID: 2
Term: 1
Vote: 4
ID: 5
Term: 1
Vote: 4
ID: 4
Term: 1
Vote: me
ID: 3
Term: 1
Vote: 4
Ok!
33
ID: 1
Term: 1
Vote: 4
ID: 2
Term: 1
Vote: 4
ID: 5
Term: 1
Vote: 4
ID: 4
Term: 1
Vote: me
ID: 3
Term: 1
Vote: 4
Leader fail...
ID: 1
Term: 2
Vote: 5
ID: 2
Term: 1
Vote: 4
ID: 5
Term: 2
Vote: me
ID: 4
Term: 1
Vote: me
ID: 3
Term: 1
Vote: 4
Vote for m...
ID: 1
Term: 2
Vote: 5
ID: 2
Term: 2
Vote: me
ID: 5
Term: 2
Vote: me
ID: 4
Term: 1
Vote: me
ID: 3
Term: 2
Vote: 2
Vote for ...
ID: 1
Term: 2
Vote: 5
ID: 2
Term: 2
Vote: me
ID: 5
Term: 2
Vote: me
ID: 4
Term: 1
Vote: me
ID: 3
Term: 2
Vote: 2
37
Leadership
Follower Candidate Leader
Startup/
Restart
Timeout Win
Timeout
Step down
38
Step down
ID: 1
Term: 3
Vote: 2
ID: 2
Term: 3
Vote: me
ID: 5
Term: 3
Vote: 2
ID: 4
Term: 3
Vote: 2
ID: 3
Term: 3
Vote: 2
Vote for me...
ID: 1
Term: 3
Vote: 2
ID: 2
Term: 3
Vote: me
ID: 5
Term: 3
Vote: 2
ID: 4
Term: 3
Vote: 2
ID: 3
Term: 3
Vote: 2
40
Replication
Each node has a log of client commands and a index
into this representing which commands have been
committed
41
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 2
A 4
B 2
Simple Replication
42
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 2
A 4
B 2
B=7
Simple Replication
43
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 2
A 4
B 2
B=7
B=7
B=7
Simple Replication
44
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 7
A 4
B 2
B=7
B=7
B=7
Simple Replication
45
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 7
A 4
B 7
A 4
B 7
B=7
B=7
B=7
Simple Replication
46
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 7
A 4
B 7
A 4
B 7
B=7
B=7
B=7
B?
Simple Replication
47
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 7
A 4
B 7
A 4
B 7
B=7
B=7
B=7
B?
B?
B?
Simple Replication
48
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 7
A 4
B 7
A 4
B 7
B=7
B=7
B=7
B?
B?
B?
Simple Replication
49
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 7
A 4
B 7
B=7
B=7
B?
B?
Catchup
A=6
50
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 7
A 4
B 7
B=7
B=7
B?
B?
Catchup
A=6
A=6
:(
51
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 7
A 4
B 7
B=7
B=7
B?
B?
Catchup
A=6
A=6
:(
52
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 7
A 4
B 7
B=7
B=7
B?
B?
Catchup
A=6
A=6
:)
53
ID: 1
ID: 2
ID: 3
A=4
A=4
A=4
A 4
B 2
A 4
B 7
A 4
B 7
B=7
B=7
B?
B?
Catchup
A=6
A=6
B=7 B? A=6
54
Evaluation
• The leader is a serious bottleneck -> limited
scalability
• Can only handle the failure of a minority of node...
Beyond Raft
56
Case Study: Tango
Tango is designed to be a scalable replication
protocol.
It’s a variant of chain replication + Paxos.
It...
Simple Replication
Client 1
A 7
B 2
Client 2
A 4
B 2 Sequencer
Server 1 Server 2 Server 3
0
A=4
Next: 1
0
A=4
0
A=4
B=5
58
Simple Replication
Client 1
A 7
B 2
Client 2
A 4
B 2 Sequencer
Server 1 Server 2 Server 3
0
A=4
Next: 2
0
A=4
0
A=4
Next?
...
Simple Replication
Client 1
A 7
B 2
Client 2
A 4
B 2 Sequencer
Server 1 Server 2 Server 3
0
A=4
Next: 2
0
A=4
0
A=4
B=5 @ ...
Simple Replication
Client 1
A 7
B 2
Client 2
A 4
B 2 Sequencer
Server 1 Server 2 Server 3
0
A=4
Next: 2
0
A=4
0
A=4
1
B=5
...
Simple Replication
Client 1
A 7
B 2
Client 2
A 4
B 2 Sequencer
Server 1 Server 2 Server 3
0
A=4
Next: 2
0
A=4
0
A=4
1
B=5
...
Simple Replication
Client 1
A 7
B 2
Client 2
A 4
B 5 Sequencer
Server 1 Server 2 Server 3
0
A=4
Next: 2
0
A=4
0
A=4
1
B=5
...
Fast Read
Client 1
A 7
B 2
Client 2
A 4
B 5 Sequencer
Server 1 Server 2 Server 3
0
A=4
Next: 2
0
A=4
0
A=4
1
B=5
1
B=5
1
B...
Handling Failures
Sequencer is soft-state which can be reconstructed by
querying head server.
Clients failing between rece...
Evaluation
Tango is scalable, the leader is not longer the
bottleneck.
Dynamic membership and sharding come for free
with ...
Next Steps
67
68
wait… we’re not finished yet!
Requirements
• Scalability - High throughout processing of
operations.
• Latency - Low latency commit of operation as
perc...
Many more examples
• Raft [ATC’14] - Good starting point, understandable
algorithm from SMR + multi-paxos variant
• VRR [M...
Can we do even better?
• Self-scaling replication - adapting resources to
maintain resilience level.
• Geo replication - s...
Evaluation is hard
• few common evaluation metrics.
• often only one experiment setup is used.
• different workloads
• eva...
Lessons Learned
• Reaching consensus in distributed
systems is do able
• Exploit domain knowledge
• Raft is a good startin...
Upcoming SlideShare
Loading in …5
×

Reaching reliable agreement in an unreliable world

7,150 views

Published on

In this lecture, we explore how to construct resilient distributed systems on top of unreliable components. Starting, almost two decades ago, with Leslie Lamport’s work on organising parliament for a Greek island. We will take a journey to today’s datacenter and the systems powering companies like Google, Amazon and Microsoft. Along the way, we will face interesting impossibility results, machines acting maliciously and the complexity to today’s networks. We will discover how to reach agreement between many parties and from this, how we construct the fault-tolerance systems that we depend upon everyday.

This lecture was given on October 13th 2015 at the University of Cambridge, as part of the Research Students Lecture Series.

Published in: Technology
  • Be the first to comment

Reaching reliable agreement in an unreliable world

  1. 1. Reaching reliable agreement in an unreliable world Heidi Howard heidi.howard@cl.cam.ac.uk @heidiann Research Students Lecture Series 13th October 2015 1
  2. 2. Introducing Alice Alice is new graduate from Cambridge off to the world of work. She joins a cool new start up, where she is responsible for a key value store. 2
  3. 3. Single Server System Server Client 2 A 7 B 2 Client 1 Client 3 3
  4. 4. Single Server System Server Client 2 A 7 B 2 Client 1 Client 3 A? 7 4
  5. 5. Single Server System Server Client 2 A 7 B 2 Client 1 Client 3 B=3 OK 3 5
  6. 6. Single Server System Server Client 2 A 7 B 2 Client 1 Client 3 B? 3 3 6
  7. 7. Single Server System Pros • linearizable semantics • durability with write-ahead logging • easy to deploy • low latency (1 RTT in common case) • partition tolerance with retransmission & command cache Cons • system unavailable if server fails • throughput limited to one server 7
  8. 8. Backups aka Primary backup replication Primary Client 2 Client 1 Backup 1 Backup 1 Backup 1 A 7 B 2 A? 7 A 7 B 2 A 7 B 2 A 7 B 2 8
  9. 9. Backups aka Primary backup replication Primary Client 2 Client 1 Backup 1 Backup 1 Backup 1 A 7 B 1 B=1 A 7 B 2 A 7 B 2 A 7 B 2 A 7 B 1 9
  10. 10. Backups aka Primary backup replication Primary Client 2 Client 1 Backup 1 Backup 1 Backup 1 A 7 B 1 OK A 7 B 1 A 7 B 1 A 7 B 1 OK OK OK 10
  11. 11. Big Gotcha We are assuming total ordered broadcast 11
  12. 12. Totally Ordered Broadcast (aka atomic broadcast) the guarantee that messages are received reliably and in the same order by all nodes. 12
  13. 13. Requirements • Scalability - High throughout processing of operations. • Latency - Low latency commit of operation as perceived by the client. • Fault-tolerance - Availability in the face of machine and network failures. • Linearizable semantics - Operate as if a single server system. 13
  14. 14. Doing the Impossible 14
  15. 15. CAP Theorem Pick 2 of 3: • Consistency • Availability • Partition tolerance Proposed by Brewer in 1998, still debated and regarded as misleading. [Brewer’12] [Kleppmann’15] 15 Eric Brewer
  16. 16. FLP Impossibility It is impossible to guarantee consensus when messages may be delay if even one node may fail. [JACM’85] 16
  17. 17. Consensus is impossible [PODC’89] Nancy Lynch 17
  18. 18. Aside from Simon PJ Don’t drag your reader or listener through your blood strained path. Simon Peyton Jones 18
  19. 19. Paxos Paxos is at the foundation of (almost) all distributed consensus protocols. It is a general approach of using two phases and majority quorums. It takes much more to construct a complete fault-tolerance distributed systems. Leslie Lamport 19
  20. 20. Beyond Paxos • Replication techniques - mapping a consensus algorithm to a fault tolerance system • Classes of operations - handling of read vs writes, operating on stale data, soft vs hard state • Leadership - fixed, variable or leaderless, multi-paxos, how to elect a leader, how to discover a leader • Failure detectors - heartbeats & timers • Dynamic membership, Log compaction & GC, sharding, batching etc 20
  21. 21. Consensus is hard 21
  22. 22. A raft in the sea of confusion 22
  23. 23. Case Study: Raft Raft is the understandable replication algorithm. Provides linearisable client semantics, 1 RTT best case latency for clients. A complete(ish) architecture for making our application fault-tolerance. Uses SMR and Paxos 23
  24. 24. State Machine Replication Server Client ServerServer A 7 B 2 A 7 B 2 A 7 B 2 B=3 24
  25. 25. State Machine Replication Server Client ServerServer A 7 B 2 A 7 B 2 A 7 B 2 B=3 25
  26. 26. State Machine Replication Server Client ServerServer A 7 B 2 A 7 B 2 A 7 B 2 B=3 3 3 3 26
  27. 27. Leadership Follower Candidate Leader Startup/ Restart Timeout Win Timeout Step down 27 Step down
  28. 28. Ordering Each node stores is own perspective on a value known as the term. Each message includes the sender’s term and this is checked by the recipient. The term orders periods of leadership to aid in avoiding conflict. Each has one vote per term, thus there is at most one leader per term. 28
  29. 29. Ordering 29 ID: 1 ID: 2 ID: 3 1 1 1 2 2 2 2
  30. 30. ID: 1 Term: 0 Vote: n ID: 2 Term: 0 Vote: n ID: 5 Term: 0 Vote: n ID: 4 Term: 0 Vote: n ID: 3 Term: 0 Vote: n 30
  31. 31. Leadership Follower Candidate Leader Startup/ Restart Timeout Win Timeout Step down 31 Step down
  32. 32. ID: 1 Term: 0 Vote: n ID: 2 Term: 0 Vote: n ID: 5 Term: 0 Vote: n ID: 4 Term: 1 Vote: me ID: 3 Term: 0 Vote: n Vote for me in term 1! 32
  33. 33. ID: 1 Term: 1 Vote: 4 ID: 2 Term: 1 Vote: 4 ID: 5 Term: 1 Vote: 4 ID: 4 Term: 1 Vote: me ID: 3 Term: 1 Vote: 4 Ok! 33
  34. 34. ID: 1 Term: 1 Vote: 4 ID: 2 Term: 1 Vote: 4 ID: 5 Term: 1 Vote: 4 ID: 4 Term: 1 Vote: me ID: 3 Term: 1 Vote: 4 Leader fails 34
  35. 35. ID: 1 Term: 2 Vote: 5 ID: 2 Term: 1 Vote: 4 ID: 5 Term: 2 Vote: me ID: 4 Term: 1 Vote: me ID: 3 Term: 1 Vote: 4 Vote for me in term 2! 35
  36. 36. ID: 1 Term: 2 Vote: 5 ID: 2 Term: 2 Vote: me ID: 5 Term: 2 Vote: me ID: 4 Term: 1 Vote: me ID: 3 Term: 2 Vote: 2 Vote for me in term 2! 36
  37. 37. ID: 1 Term: 2 Vote: 5 ID: 2 Term: 2 Vote: me ID: 5 Term: 2 Vote: me ID: 4 Term: 1 Vote: me ID: 3 Term: 2 Vote: 2 37
  38. 38. Leadership Follower Candidate Leader Startup/ Restart Timeout Win Timeout Step down 38 Step down
  39. 39. ID: 1 Term: 3 Vote: 2 ID: 2 Term: 3 Vote: me ID: 5 Term: 3 Vote: 2 ID: 4 Term: 3 Vote: 2 ID: 3 Term: 3 Vote: 2 Vote for me in term 3! 39
  40. 40. ID: 1 Term: 3 Vote: 2 ID: 2 Term: 3 Vote: me ID: 5 Term: 3 Vote: 2 ID: 4 Term: 3 Vote: 2 ID: 3 Term: 3 Vote: 2 40
  41. 41. Replication Each node has a log of client commands and a index into this representing which commands have been committed 41
  42. 42. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 2 A 4 B 2 Simple Replication 42
  43. 43. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 2 A 4 B 2 B=7 Simple Replication 43
  44. 44. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 2 A 4 B 2 B=7 B=7 B=7 Simple Replication 44
  45. 45. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 7 A 4 B 2 B=7 B=7 B=7 Simple Replication 45
  46. 46. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 7 A 4 B 7 A 4 B 7 B=7 B=7 B=7 Simple Replication 46
  47. 47. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 7 A 4 B 7 A 4 B 7 B=7 B=7 B=7 B? Simple Replication 47
  48. 48. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 7 A 4 B 7 A 4 B 7 B=7 B=7 B=7 B? B? B? Simple Replication 48
  49. 49. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 7 A 4 B 7 A 4 B 7 B=7 B=7 B=7 B? B? B? Simple Replication 49
  50. 50. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 7 A 4 B 7 B=7 B=7 B? B? Catchup A=6 50
  51. 51. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 7 A 4 B 7 B=7 B=7 B? B? Catchup A=6 A=6 :( 51
  52. 52. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 7 A 4 B 7 B=7 B=7 B? B? Catchup A=6 A=6 :( 52
  53. 53. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 7 A 4 B 7 B=7 B=7 B? B? Catchup A=6 A=6 :) 53
  54. 54. ID: 1 ID: 2 ID: 3 A=4 A=4 A=4 A 4 B 2 A 4 B 7 A 4 B 7 B=7 B=7 B? B? Catchup A=6 A=6 B=7 B? A=6 54
  55. 55. Evaluation • The leader is a serious bottleneck -> limited scalability • Can only handle the failure of a minority of nodes • Some rare network partitions render protocol in livelock 55
  56. 56. Beyond Raft 56
  57. 57. Case Study: Tango Tango is designed to be a scalable replication protocol. It’s a variant of chain replication + Paxos. It is leaderless and pushes more work onto clients 57
  58. 58. Simple Replication Client 1 A 7 B 2 Client 2 A 4 B 2 Sequencer Server 1 Server 2 Server 3 0 A=4 Next: 1 0 A=4 0 A=4 B=5 58
  59. 59. Simple Replication Client 1 A 7 B 2 Client 2 A 4 B 2 Sequencer Server 1 Server 2 Server 3 0 A=4 Next: 2 0 A=4 0 A=4 Next? 1 59 B=5
  60. 60. Simple Replication Client 1 A 7 B 2 Client 2 A 4 B 2 Sequencer Server 1 Server 2 Server 3 0 A=4 Next: 2 0 A=4 0 A=4 B=5 @ 1 OK 1 B=5 60 B=5
  61. 61. Simple Replication Client 1 A 7 B 2 Client 2 A 4 B 2 Sequencer Server 1 Server 2 Server 3 0 A=4 Next: 2 0 A=4 0 A=4 1 B=5 1 B=5 61 B=5 @ 1 OK
  62. 62. Simple Replication Client 1 A 7 B 2 Client 2 A 4 B 2 Sequencer Server 1 Server 2 Server 3 0 A=4 Next: 2 0 A=4 0 A=4 1 B=5 1 B=5 1 B=5 62 B=5 @ 1 OK
  63. 63. Simple Replication Client 1 A 7 B 2 Client 2 A 4 B 5 Sequencer Server 1 Server 2 Server 3 0 A=4 Next: 2 0 A=4 0 A=4 1 B=5 1 B=5 1 B=5 63
  64. 64. Fast Read Client 1 A 7 B 2 Client 2 A 4 B 5 Sequencer Server 1 Server 2 Server 3 0 A=4 Next: 2 0 A=4 0 A=4 1 B=5 1 B=5 1 B=5 Check? 1 B? 64
  65. 65. Handling Failures Sequencer is soft-state which can be reconstructed by querying head server. Clients failing between receiving token and first read leaves gaps in the log. Clients can mark these as empty and space (though not address) is reused. Clients may fail before completing a write. The next client can fill-in and complete the operation Server failures are detected by clients, who initiate a membership change, using term numbers. 65
  66. 66. Evaluation Tango is scalable, the leader is not longer the bottleneck. Dynamic membership and sharding come for free with design. High latency of chain replication 66
  67. 67. Next Steps 67
  68. 68. 68 wait… we’re not finished yet!
  69. 69. Requirements • Scalability - High throughout processing of operations. • Latency - Low latency commit of operation as perceived by the client. • Fault-tolerance - Availability in the face of machine and network failures. • Linearizable semantics - Operate as if a single server system. 69
  70. 70. Many more examples • Raft [ATC’14] - Good starting point, understandable algorithm from SMR + multi-paxos variant • VRR [MIT-TR’12] - Raft with round-robin leadership & more distributed load • Tango [SOSP’13] - Scalable algorithm for f+1 nodes, uses CR + multi-paxos variant • Zookeeper [ATC'10] - Primary backup replication + atomic broadcast protocol (Zab [DSN’11]) • EPaxos [SOSP’13] - leaderless Paxos varient for WANs 70
  71. 71. Can we do even better? • Self-scaling replication - adapting resources to maintain resilience level. • Geo replication - strong consistency between wide area links • Auto configuration - adapting timeouts and configure as network changes • Integrated with unikernels, virtualisation, containers and other such deployment tech 71
  72. 72. Evaluation is hard • few common evaluation metrics. • often only one experiment setup is used. • different workloads • evaluation to demonstrate protocol strength 72
  73. 73. Lessons Learned • Reaching consensus in distributed systems is do able • Exploit domain knowledge • Raft is a good starting point but we can do much better! Questions? 73

×