Declarative, Convergent, Edge Computation

Declarative, Convergent, Edge Computation

Craft Conference, 2017

3e09fee7b359be847ed5fa48f524a3d3?s=128

Christopher Meiklejohn

April 28, 2017
Tweet

Transcript

  1. 1.

    Declarative, Convergent, Edge Computation Christopher S. Meiklejohn Université catholique de

    Louvain, Belgium Instituto Superior Técnico, Portugal LIGHT ONE
  2. 2.
  3. 5.

    RA RB 1 set(1) 3 2 set(2) set(3) ? ?

    Nondeterministic outcome.
  4. 7.

    Synchronization • To enforce an order
 Makes programming easier •

    Eliminate accidental nondeterminism
 Prevent race conditions 6
  5. 8.

    Synchronization • To enforce an order
 Makes programming easier •

    Eliminate accidental nondeterminism
 Prevent race conditions • Techniques
 Locks, mutexes, semaphores, monitors, Paxos, Raft, etc. 6
  6. 10.

    Difficult Cases • “Internet of Things”, 
 Low power, limited

    memory and connectivity • Mobile Gaming
 Offline operation with replicated, shared state 7
  7. 11.

    8

  8. 14.

    Distributed Computation • Concurrent to distributed programming
 Consistency and now

    partial failure • Enforcing the “single system” illusion
 Traditional approach for gaining performance, scalability, fault- tolerance while still “easy to program” 10
  9. 15.

    Distributed Computation • Concurrent to distributed programming
 Consistency and now

    partial failure • Enforcing the “single system” illusion
 Traditional approach for gaining performance, scalability, fault- tolerance while still “easy to program” • Consistency models
 Contract between the system and the programmer 10
  10. 16.

    Distributed Computation • Concurrent to distributed programming
 Consistency and now

    partial failure • Enforcing the “single system” illusion
 Traditional approach for gaining performance, scalability, fault- tolerance while still “easy to program” • Consistency models
 Contract between the system and the programmer • Correctness criteria
 For both distributed and concurrent programs 10
  11. 17.

    Distributed Computation • Concurrent to distributed programming
 Consistency and now

    partial failure • Enforcing the “single system” illusion
 Traditional approach for gaining performance, scalability, fault- tolerance while still “easy to program” • Consistency models
 Contract between the system and the programmer • Correctness criteria
 For both distributed and concurrent programs • Synchronization as “knob”
 Models live along a spectrum requiring more or less synchronization 10
  12. 29.

    R2 C1 C2 Value 2 Value 1 Value 2 R1

    R3 Paxos 22 Coordination is extremely expensive.
  13. 37.

    R1 R2 R3 C1 C2 Write C1 30 Do I

    store both values or do I choose a value arbitrarily?
  14. 38.

    R1 R2 R3 C1 C2 Read 31 If I store

    both, the programmer must expect multiple values…
  15. 39.

    R1 R2 R3 C1 C2 Write 32 …and be able

    to semantically resolve them in application code.
  16. 41.

    Strong Eventual Consistency (SEC) • Convergent
 Same updates realize the

    same state • Primary requirement
 “Eventual” replica-to-replica communication 33
  17. 42.

    Strong Eventual Consistency (SEC) • Convergent
 Same updates realize the

    same state • Primary requirement
 “Eventual” replica-to-replica communication • Order insensitive!
 Operations are commutative 33
  18. 43.

    Strong Eventual Consistency (SEC) • Convergent
 Same updates realize the

    same state • Primary requirement
 “Eventual” replica-to-replica communication • Order insensitive!
 Operations are commutative • Duplicate insensitive!
 Operations are idempotent 33
  19. 44.
  20. 47.

    RA RB 1 3 2 3 3 set(1) set(2) set(3)

    max(2,3) max(2,3) Automatic resolution of conflicting updates.
  21. 50.

    Programming SEC 1. Eliminate accidental nondeterminism
 (ex. deterministic, modeling non-monotonic

    operations monotonically) 2. Retain the properties of functional programming
 (ex. confluence, “correct-by-construction” applications) 39
  22. 51.

    Programming SEC 1. Eliminate accidental nondeterminism
 (ex. deterministic, modeling non-monotonic

    operations monotonically) 2. Retain the properties of functional programming
 (ex. confluence, “correct-by-construction” applications) 3. Distributed, and fault-tolerant runtime
 (ex. replication, membership, dissemination) 39
  23. 52.

    Programming SEC 1. Eliminate accidental nondeterminism
 (ex. deterministic, modeling non-monotonic

    operations monotonically) 2. Retain the properties of functional programming
 (ex. confluence, “correct-by-construction” applications) 3. Distributed, and fault-tolerant runtime
 (ex. replication, membership, dissemination) 40
  24. 54.

    Conflict-Free 
 Replicated Data Types • Many types exist with

    different properties
 Sets, counters, registers, flags, maps 42
  25. 55.

    Conflict-Free 
 Replicated Data Types • Many types exist with

    different properties
 Sets, counters, registers, flags, maps • Strong Eventual Consistency
 Instances satisfy SEC property per-object 42
  26. 56.

    Conflict-Free 
 Replicated Data Types • Many types exist with

    different properties
 Sets, counters, registers, flags, maps • Strong Eventual Consistency
 Instances satisfy SEC property per-object • Bounded join-semilattices
 Formalized using bounded join-semilattices where the merge operation is the join 42
  27. 58.
  28. 61.

    RA RB RC {1} (1, {a}, {}) add(1) {1} (1,

    {b}, {}) add(1) {} (1, {b}, {b}) remove(1)
  29. 62.

    RA RB RC {1} (1, {a}, {}) add(1) {1} (1,

    {b}, {}) add(1) {} (1, {b}, {b}) remove(1) {1} {1} {1} (1, {a, b}, {b}) (1, {a, b}, {b}) (1, {a, b}, {b}) Convergence reached.
  30. 64.

    RA {1} (1, {a}, {}) {1} (1, {a, b}, {a})

    RB {1} (1, {b}, {}) {1} (1, {a, b}, {a}) {} (1, {a}, {a}) add(1) remove(1) add(1) Replicated set of naturals across two nodes.
  31. 65.

    RA {1} (1, {a}, {}) {1} (1, {a, b}, {a})

    RB {1} (1, {b}, {}) {1} (1, {a, b}, {a}) {} (1, {a}, {a}) add(1) remove(1) add(1) Map Process \x.2x F(RA) {2} {2} {} F(RB) {2} ? Map Process \x.2x Map Process \x.2x Map Process \x.2x Map Process \x.2x {2} Map \x.2x over a set of naturals.
  32. 66.

    RA {1} (1, {a}, {}) {1} (1, {a, b}, {a})

    RB {1} (1, {b}, {}) {1} (1, {a, b}, {a}) {} (1, {a}, {a}) add(1) remove(1) add(1) Map Process \x.2x F(RA) {2} {2} {} F(RB) {2} ? Map Process \x.2x Map Process \x.2x Map Process \x.2x Map Process \x.2x {2} One node…
  33. 67.

    RA {1} (1, {a}, {}) {1} (1, {a, b}, {a})

    RB {1} (1, {b}, {}) {1} (1, {a, b}, {a}) {} (1, {a}, {a}) add(1) remove(1) add(1) Map Process \x.2x F(RA) {2} {2} {} F(RB) {2} ? Map Process \x.2x Map Process \x.2x Map Process \x.2x Map Process \x.2x {2} …another node.
  34. 68.

    RA {1} (1, {a}, {}) {1} (1, {a, b}, {a})

    RB {1} (1, {b}, {}) {1} (1, {a, b}, {a}) {} (1, {a}, {a}) add(1) remove(1) add(1) Map Process \x.2x F(RA) {2} {2} {} F(RB) {2} ? Map Process \x.2x Map Process \x.2x Map Process \x.2x Map Process \x.2x {2}
  35. 69.

    RA {1} (1, {a}, {}) {1} (1, {a, b}, {a})

    RB {1} (1, {b}, {}) {1} (1, {a, b}, {a}) {} (1, {a}, {a}) add(1) remove(1) add(1) Map Process \x.2x F(RA) {2} {2} {} F(RB) {2} ? Map Process \x.2x Map Process \x.2x Map Process \x.2x Map Process \x.2x {2} Nondeterministic outcome.
  36. 70.

    RA {1} (1, {a}, {}) {1} (1, {a, b}, {a})

    RB {1} (1, {b}, {}) {1} (1, {a, b}, {a}) {} (1, {a}, {a}) add(1) remove(1) add(1) Map Process \x.2x F(RA) {2} {2} {} F(RB) {2} ? Map Process \x.2x Map Process \x.2x Map Process \x.2x Map Process \x.2x {2} Correct output that’s seen all updates.
  37. 71.

    RA {1} (1, {a}, {}) {1} (1, {a, b}, {a})

    RB {1} (1, {b}, {}) {1} (1, {a, b}, {a}) {} (1, {a}, {a}) add(1) remove(1) add(1) Map Process \x.2x F(RA) {2} {2} {} F(RB) {2} ? Map Process \x.2x Map Process \x.2x Map Process \x.2x Map Process \x.2x {2} “Earlier” value that’s been delayed.
  38. 72.

    Programming SEC 1. Eliminate accidental nondeterminism
 (ex. deterministic, modeling non-monotonic

    operations monotonically) 2. Retain the properties of functional programming
 (ex. confluence, “correct-by-construction” applications) 3. Distributed, and fault-tolerant runtime
 (ex. replication, membership, dissemination) 58
  39. 75.

    Lattice Processing • Asynchronous dataflow with streams
 Combine and transform

    streams of inputs into streams of outputs • Convergent data structures
 Data abstraction (inputs/outputs) is the CRDT 60
  40. 76.

    Lattice Processing • Asynchronous dataflow with streams
 Combine and transform

    streams of inputs into streams of outputs • Convergent data structures
 Data abstraction (inputs/outputs) is the CRDT • Confluence
 Provides composition that preserves the SEC property 60
  41. 79.

    A’ A’’ B’ B’’ Map Process \x.2x Map Process \x.2x

    A B Map Process \x.2x 63 Replication per node.
  42. 80.

    A’ A’’ B’ B’’ Map Process \x.2x Map Process \x.2x

    A B Map Process \x.2x 64 Replication per node.
  43. 81.

    A’ A’’ B’ B’’ Map Process \x.2x Map Process \x.2x

    A B Map Process \x.2x 65 Replication per node.
  44. 82.

    A’ A’’ B’ B’’ Map Process \x.2x Map Process \x.2x

    A B Map Process \x.2x 66 One possible schedule….
  45. 83.

    A’ A’’ B’ B’’ Map Process \x.2x Map Process \x.2x

    A B Map Process \x.2x 67 …another possible schedule.
  46. 88.

    72 %% Create initial set. S1 = declare(set), %% Add

    elements to initial set and update. update(S1, {add, [1,2,3]}), %% Create second set. S2 = declare(set), %% Apply map operation between S1 and S2. map(S1, fun(X) -> X * 2 end, S2).
  47. 89.

    73 %% Create initial set. S1 = declare(set), %% Add

    elements to initial set and update. update(S1, {add, [1,2,3]}), %% Create second set. S2 = declare(set), %% Apply map operation between S1 and S2. map(S1, fun(X) -> X * 2 end, S2).
  48. 90.

    74 %% Create initial set. S1 = declare(set), %% Add

    elements to initial set and update. update(S1, {add, [1,2,3]}), %% Create second set. S2 = declare(set), %% Apply map operation between S1 and S2. map(S1, fun(X) -> X * 2 end, S2).
  49. 91.

    75 %% Create initial set. S1 = declare(set), %% Add

    elements to initial set and update. update(S1, {add, [1,2,3]}), %% Create second set. S2 = declare(set), %% Apply map operation between S1 and S2. map(S1, fun(X) -> X * 2 end, S2).
  50. 92.

    76 %% Create initial set. S1 = declare(set), %% Add

    elements to initial set and update. update(S1, {add, [1,2,3]}), %% Create second set. S2 = declare(set), %% Apply map operation between S1 and S2. map(S1, fun(X) -> X * 2 end, S2).
  51. 93.

    Processes • Replicas as monotonic streams
 Each replica of a

    CRDT produces a monotonic stream of states 77
  52. 94.

    Processes • Replicas as monotonic streams
 Each replica of a

    CRDT produces a monotonic stream of states • Monotonic processes
 Read from one or more input replica streams and produce a single output replica stream 77
  53. 95.

    Processes • Replicas as monotonic streams
 Each replica of a

    CRDT produces a monotonic stream of states • Monotonic processes
 Read from one or more input replica streams and produce a single output replica stream • Inflationary reads
 Read operation ensures that we only read inflationary updates to replicas 77
  54. 99.

    RA {} (1, {a}, {}) (1, {a, b}, {}) C1

    (1, {a}, {}) {} C2 (1, {b}, {}) {} 81
  55. 100.

    RA {} (1, {a}, {}) (1, {a, b}, {}) (1,

    {a, b}, {a}) C1 (1, {a}, {}) {} (1, {a}, {a}) C2 (1, {b}, {}) {} 82
  56. 101.

    RA {} (1, {a}, {}) (1, {a, b}, {}) (1,

    {a, b}, {a}) C1 (1, {a}, {}) {} (1, {a}, {a}) C2 (1, {b}, {}) {} (1, {a, b}, {a}) (1, {a, b}, {a}) (1, {a, b}, {a}) 83
  57. 102.

    RA {} (1, {a}, {}) (1, {a, b}, {}) (1,

    {a, b}, {a}) C1 (1, {a}, {}) {} (1, {a}, {a}) C2 (1, {b}, {}) {} (1, {a, b}, {a}) (1, {a, b}, {a}) (1, {a, b}, {a}) 84 Clients can operate with partial state…
  58. 103.

    RA {} (1, {a}, {}) (1, {a, b}, {}) (1,

    {a, b}, {a}) C1 (1, {a}, {}) {} (1, {a}, {a}) C2 (1, {b}, {}) {} (1, {a, b}, {a}) (1, {a, b}, {a}) (1, {a, b}, {a}) 85 … and synchronize with their local replica.
  59. 109.

    RA {} P1 F(RA) {} strict_read({}) (1, {a}, {}) F((1,

    {a}, {})) (2, {a}, {}) 91 Every time replica changes…
  60. 110.

    RA {} P1 F(RA) {} strict_read({}) (1, {a}, {}) F((1,

    {a}, {})) (2, {a}, {}) 92 ….the process will compute a new result.
  61. 111.

    RA {} P1 F(RA) {} strict_read({}) (1, {a}, {}) F((1,

    {a}, {})) (2, {a}, {}) strict_read((1, {a}, {}) (1, {a}, {}) 93
  62. 112.

    RA {} P1 F(RA) {} strict_read({}) (1, {a}, {}) F((1,

    {a}, {})) (2, {a}, {}) strict_read((1, {a}, {}) (1, {a}, {}) (1, {a}, {a}) F((1, {a}, {a})) (2, {a}, {a}) strict_read((1, {a}, {a}) (1, {a}, {a}) 94
  63. 113.

    RA {} P1 F(RA) {} strict_read({}) (1, {a}, {}) (1,

    {a}, {}) (1, {a}, {a}) F((1, {a}, {a})) (2, {a}, {a}) strict_read((1, {a}, {a}) (1, {a}, {a}) 95 Omitted interleaving does not sacrifice correctness.
  64. 116.

    RC F(RC) {2} Map Process \x.2x (2, {b}, {}) (1,

    {b}, {}) {1} 98 Transform element, map metadata.
  65. 117.

    RC F(RC) {2} Map Process \x.2x (2, {b}, {}) (1,

    {b}, {}) {1} {} (1, {b}, {b}) {} Map Process \x.2x (2, {b}, {b}) 99
  66. 118.

    RC F(RC) {2} Map Process \x.2x (2, {b}, {}) (1,

    {b}, {}) {1} {} (1, {b}, {b}) {} Map Process \x.2x (2, {b}, {b}) {1} (1, {a, b}, {b}) {2} Map Process \x.2x (2, {a, b}, {b}) 100
  67. 119.

    RC F(RC) {2} Map Process \x.2x (2, {b}, {}) (1,

    {b}, {}) {1} {} (1, {b}, {b}) {} Map Process \x.2x (2, {b}, {b}) {1} (1, {a, b}, {b}) {2} Map Process \x.2x (2, {a, b}, {b}) {1} {2} 101
  68. 120.

    Programming SEC 1. Eliminate accidental nondeterminism
 (ex. deterministic, modeling non-monotonic

    operations monotonically) 2. Retain the properties of functional programming
 (ex. confluence, “correct-by-construction” applications) 3. Distributed, and fault-tolerant runtime
 (ex. replication, membership, dissemination) 102
  69. 123.

    Advertisement Counter • Lower-bound invariant
 Advertisements are paid according to

    a minimum number of impressions • Clients will go offline
 Clients have limited connectivity and the system still needs to make progress while clients are offline 104
  70. 124.

    Advertisement Counter • Lower-bound invariant
 Advertisements are paid according to

    a minimum number of impressions • Clients will go offline
 Clients have limited connectivity and the system still needs to make progress while clients are offline • No lost updates
 All displayed advertisements should be accounted for, with no lost updates 104
  71. 126.
  72. 129.

    RA RB 1 set(1) 2 2 set(2) set(2) 2 2

    max(2,2) max(2,2) 109
  73. 130.

    RA RB 1 set(1) 2 2 set(2) set(2) 2 2

    max(2,2) max(2,2) 110 Incorrect value is computed because of incompatible lattice.
  74. 141.

    Ads Contracts Product Filter Map Ads X Contracts Ads With

    Contracts Ads To Display Asynchronous Dataflow Counters Counters Counters Counter Ads Update (Insert) Application Initialization Counter Read > 50,000 Ads Update (Remove) Epsilon-Invariant Ads Map Configure Invariant Enforce Invariant 121
  75. 142.

    Ads Contracts Product Filter Map Ads X Contracts Ads With

    Contracts Ads To Display Asynchronous Dataflow 122
  76. 144.
  77. 145.

    Counter Read > 50,000 Ads Update (Remove) Epsilon-Invariant Ads Map

    Configure Invariant Enforce Invariant 125 Configure invariants for all of the advertisements.
  78. 146.

    Counter Read > 50,000 Ads Update (Remove) Epsilon-Invariant Ads Map

    Configure Invariant Enforce Invariant 126 Remove the advertisement from the list.
  79. 148.

    Advertisement Counter • Completely monotonic
 Disabling advertisements and contracts are

    all modeled through monotonic state growth • Arbitrary distribution
 Use of convergent data structures allows computational graph to be arbitrarily distributed 127
  80. 149.

    Advertisement Counter • Completely monotonic
 Disabling advertisements and contracts are

    all modeled through monotonic state growth • Arbitrary distribution
 Use of convergent data structures allows computational graph to be arbitrarily distributed • Divergence
 Divergence is a factor of synchronization period, concurrency, and throughput rate 127
  81. 150.

    Programming SEC 1. Eliminate accidental nondeterminism
 (ex. deterministic, modeling non-monotonic

    operations monotonically) 2. Retain the properties of functional programming
 (ex. confluence, “correct-by-construction” applications) 3. Distributed, and fault-tolerant runtime
 (ex. replication, membership, dissemination) 128
  82. 153.

    Anabranch • Layered approach
 Cluster membership and state dissemination for

    large clusters • Delta-state synchronization 
 Efficient incremental state dissemination and anti-entropy mechanism [Almeida et al. 2016] 130
  83. 154.

    Anabranch • Layered approach
 Cluster membership and state dissemination for

    large clusters • Delta-state synchronization 
 Efficient incremental state dissemination and anti-entropy mechanism [Almeida et al. 2016] • Epsilon-invariants
 Lower-bound invariants, configurable at runtime 130
  84. 155.

    Anabranch • Layered approach
 Cluster membership and state dissemination for

    large clusters • Delta-state synchronization 
 Efficient incremental state dissemination and anti-entropy mechanism [Almeida et al. 2016] • Epsilon-invariants
 Lower-bound invariants, configurable at runtime • Scalable
 Demonstrated high scalability in production Cloud environments 130
  85. 159.

    Layered Approach • Backend
 Configurable persistence layer depending on application.

    • Membership
 Configurable membership protocol which can operate in a client-server or peer-to-peer mode [Leitao et al. 2007] 132
  86. 160.

    Layered Approach • Backend
 Configurable persistence layer depending on application.

    • Membership
 Configurable membership protocol which can operate in a client-server or peer-to-peer mode [Leitao et al. 2007] • Broadcast (via Gossip, Tree, etc.)
 Efficient dissemination of both program state and application state via gossip, broadcast tree, or hybrid mode [Leitao et al. 2007] 132
  87. 161.

    Mobile Phone Distributed Hash Table Application Language Execution KV Store

    KV Backend Membership Broadcast Layer Client/Server Peer-to-Peer
  88. 162.

    Mobile Phone Distributed Hash Table Application Language Execution KV Store

    KV Backend Membership Broadcast Layer Client/Server Peer-to-Peer Language and applications.
  89. 163.

    Mobile Phone Distributed Hash Table Application Language Execution KV Store

    KV Backend Membership Broadcast Layer Client/Server Peer-to-Peer Storage for CRDT state.
  90. 164.

    Mobile Phone Distributed Hash Table Application Language Execution KV Store

    KV Backend Membership Broadcast Layer Client/Server Peer-to-Peer State dissemination.
  91. 167.

    Delta-based Dissemination • Delta-state based CRDTs
 Reduces state transmission for

    clients • Operate locally
 Objects are mutated locally; delta’s buffered locally and periodically gossiped 138
  92. 168.

    Delta-based Dissemination • Delta-state based CRDTs
 Reduces state transmission for

    clients • Operate locally
 Objects are mutated locally; delta’s buffered locally and periodically gossiped • Only fixed number of clients
 Clients resort to full state synchronization when they’ve been partitioned too long 138
  93. 170.

    RC BufferA BufferB (1, {b}, {}) {1} (1, {b}, {})

    (1, {b}, {}) Buffer minimal change representation…
  94. 171.

    RC BufferA BufferB (1, {b}, {}) {1} (1, {b}, {})

    (1, {b}, {}) {} (1, {b}, {b}) (1, {b}, {b}) (1, {b}, {b})
  95. 172.

    RC BufferA BufferB (1, {b}, {}) {1} (1, {b}, {})

    (1, {b}, {}) {} (1, {b}, {b}) (1, {b}, {b}) (1, {b}, {b}) {2} (1, {b}, {b}) (2, {c}, {}) (2, {c}, {}) (2, {c}, {}) …then, disseminate state in causal order to neighbors.
  96. 173.

    RC BufferA BufferB (1, {b}, {}) {1} (1, {b}, {})

    (1, {b}, {}) {} (1, {b}, {b}) (1, {b}, {b}) (1, {b}, {b}) {2} (1, {b}, {b}) (2, {c}, {}) (2, {c}, {}) (2, {c}, {}) {1, 2} (1, {a, b}, {b}) (2, {c}, {}) {1, 2} (1, {a}, {}) (1, {a}, {}) Only ship inflation from incoming state.
  97. 176.

    Scalability • 1024+ nodes
 Demonstrated scalability to 1024 nodes in

    Amazon cloud computing environment • Modular approach
 Many of the components built and can be operated outside of Lasp to improve scalability of Erlang 145
  98. 177.

    Scalability • 1024+ nodes
 Demonstrated scalability to 1024 nodes in

    Amazon cloud computing environment • Modular approach
 Many of the components built and can be operated outside of Lasp to improve scalability of Erlang • Automated and repeatable
 Fully automated deployment, scenario execution, log aggregation and archival of experimental results 145
  99. 178.

    Programming SEC 1. Eliminate accidental nondeterminism
 (ex. deterministic, modeling non-monotonic

    operations monotonically) 2. Retain the properties of functional programming
 (ex. confluence, “correct-by-construction” applications) 3. Distributed, and fault-tolerant runtime
 (ex. replication, membership, dissemination) 146
  100. 183.

    Programming SEC 1. Eliminate accidental nondeterminism
 Convergent Objects: Conflict-Free Replicated

    Data Types [Shapiro et al. 2011] 2. Retain the properties of functional programming
 Convergent Programs: Lattice Processing
 [Meiklejohn et al. 2015] 149
  101. 184.

    Programming SEC 1. Eliminate accidental nondeterminism
 Convergent Objects: Conflict-Free Replicated

    Data Types [Shapiro et al. 2011] 2. Retain the properties of functional programming
 Convergent Programs: Lattice Processing
 [Meiklejohn et al. 2015] 3. Distributed, and fault-tolerant runtime
 Distributed Runtime: Anabranch
 [Meiklejohn et al. work-in-progress] 149
  102. 185.

    Key Points • Synchronization is sometimes not possible
 Mobile and

    “Internet of Things” applications make synchronization for replicated state impractical 150
  103. 186.

    Key Points • Synchronization is sometimes not possible
 Mobile and

    “Internet of Things” applications make synchronization for replicated state impractical • Apply synchronization only where required
 Global invariants, atomic visibility, etc. 150
  104. 187.

    Key Points • Synchronization is sometimes not possible
 Mobile and

    “Internet of Things” applications make synchronization for replicated state impractical • Apply synchronization only where required
 Global invariants, atomic visibility, etc. • Holistic approach
 Taking a holistic approach to the design of distributed systems is important for building higher-availability applications 150
  105. 189.

    Artifacts • Lasp
 CRDT based programming model: testbed for Loquat


    http://github.com/lasp-lang/lasp • Partisan
 TCP-based pluggable membership service offering client/server, static, and HyParView- based protocols
 https://github.com/lasp-lang/partisan 151
  106. 190.

    Artifacts • Lasp
 CRDT based programming model: testbed for Loquat


    http://github.com/lasp-lang/lasp • Partisan
 TCP-based pluggable membership service offering client/server, static, and HyParView- based protocols
 https://github.com/lasp-lang/partisan • Plumtree
 Epidemic broadcast trees for use with Partisan
 https://github.com/lasp-lang/plumtree 151
  107. 191.

    Artifacts • Lasp
 CRDT based programming model: testbed for Loquat


    http://github.com/lasp-lang/lasp • Partisan
 TCP-based pluggable membership service offering client/server, static, and HyParView- based protocols
 https://github.com/lasp-lang/partisan • Plumtree
 Epidemic broadcast trees for use with Partisan
 https://github.com/lasp-lang/plumtree • Sprinter
 Service discovery and deployment for Mesos and Kubernetes
 https://github.com/lasp-lang/sprinter 151
  108. 192.

    Artifacts • Lasp
 CRDT based programming model: testbed for Loquat


    http://github.com/lasp-lang/lasp • Partisan
 TCP-based pluggable membership service offering client/server, static, and HyParView- based protocols
 https://github.com/lasp-lang/partisan • Plumtree
 Epidemic broadcast trees for use with Partisan
 https://github.com/lasp-lang/plumtree • Sprinter
 Service discovery and deployment for Mesos and Kubernetes
 https://github.com/lasp-lang/sprinter • Types
 CRDT implementations for Erlang
 https://github.com/lasp-lang/types 151