Burn Your Laurels

A presentation at CodeBEAM Europe in May 2022 in Stockholm, Sweden by Brooklyn Zelenka

Slide 1

Slide 1

Burn Your Laurels Network Evolution, The Consistency Treadmill, & Transcending Spacetime

Slide 2

Slide 2

Burn Your Laurels Network Evolution, The Consistency Treadmill, & Transcending Spacetime

Slide 3

Slide 3

Slide 4

Slide 4

Slide 5

Slide 5

That’s one heck of a network partition

Slide 6

Slide 6

Slide 7

Slide 7

Not to be bound by certain ‘obvious’ methodological rules […] is both reasonable and absolutely necessary for the growth of knowledge. […] There are always circumstances when it is advisable not only to ignore the rule, but to adopt its opposite. – Paul Feyerabend, Against Method

Slide 8

Slide 8

Brooklyn Zelenka @expede

Slide 9

Slide 9

Brooklyn Zelenka @expede • CTO at Fission (https://fission.codes) • Local-first, globally distributed, trustless

Slide 10

Slide 10

Brooklyn Zelenka @expede • CTO at Fission (https://fission.codes) • Local-first, globally distributed, trustless • PLT, VMs, DSys

Slide 11

Slide 11

Brooklyn Zelenka @expede • CTO at Fission (https://fission.codes) • Local-first, globally distributed, trustless • PLT, VMs, DSys • Original author of Witchcraft, Algae, Exceptional, etc

Slide 12

Slide 12

Brooklyn Zelenka @expede • CTO at Fission (https://fission.codes) • Local-first, globally distributed, trustless • PLT, VMs, DSys • Original author of Witchcraft, Algae, Exceptional, etc • Standards: UCAN (editor), EIPs, FVM, Multiformats, others

Slide 13

Slide 13

Brooklyn Zelenka @expede • CTO at Fission (https://fission.codes) • Local-first, globally distributed, trustless • PLT, VMs, DSys • Original author of Witchcraft, Algae, Exceptional, etc • Standards: UCAN (editor), EIPs, FVM, Multiformats, others • Founded VanFP, VanBEAM, DSys Reading Group (join us!)

Slide 14

Slide 14

Brooklyn Zelenka @expede • CTO at Fission (https://fission.codes) • Local-first, globally distributed, trustless • PLT, VMs, DSys • Original author of Witchcraft, Algae, Exceptional, etc • Standards: UCAN (editor), EIPs, FVM, Multiformats, others • Founded VanFP, VanBEAM, DSys Reading Group (join us!) https://lu.ma/distributed-systems

Slide 15

Slide 15

I have stickers!

Slide 16

Slide 16

Meta 🔄 Let’s Change Everything! (kthxbye) Part I: Empex MTN 🇺🇸 Part II: CodeBEAM EU 🇸🇪

Slide 17

Slide 17

Meta 🔄 We ❤ BEAM

Slide 18

Slide 18

Meta 🔄 We ❤ BEAM The BEAM does so much right 👏

Slide 19

Slide 19

Meta 🔄 We ❤ BEAM The BEAM does so much right 👏 In many ways, we’re actually ahead of the industry

Slide 20

Slide 20

Meta 🔄 We ❤ BEAM The BEAM does so much right 👏 In many ways, we’re actually ahead of the industry …but as our ideas spread, this lead won’t last

Slide 21

Slide 21

Meta 🔄 We ❤ BEAM The BEAM does so much right 👏 In many ways, we’re actually ahead of the industry …but as our ideas spread, this lead won’t last The world changing around us 😃😨

Slide 22

Slide 22

Meta 🔄 We ❤ BEAM The BEAM does so much right 👏 In many ways, we’re actually ahead of the industry …but as our ideas spread, this lead won’t last The world changing around us 😃😨 Let’s ask uncomfortable questions to find new directions for growth

Slide 23

Slide 23

Meta 🔄 We ❤ BEAM The BEAM does so much right 👏 In many ways, we’re actually ahead of the industry …but as our ideas spread, this lead won’t last The world changing around us 😃😨 Let’s ask uncomfortable questions to find new directions for growth

Slide 24

Slide 24

Meta 🔄 Random Walk Image by Pradyumna Yadav

Slide 25

Slide 25

Meta 🔄 Random Walk Image by Pradyumna Yadav

Slide 26

Slide 26

Meta 🔄 Random Walk Image by Pradyumna Yadav

Slide 27

Slide 27

Meta 🔄 Random Walk Image by Pradyumna Yadav

Slide 28

Slide 28

Meta 🔄 Random Walk Image by Pradyumna Yadav

Slide 29

Slide 29

Meta 🔄 Random Walk 😄 Image by Pradyumna Yadav

Slide 30

Slide 30

Meta 🔄 Random Walk 😍 😄 😭 Image by Pradyumna Yadav

Slide 31

Slide 31

Meta 🔄 Random Walk 😍 🧐 😄 😭 Image by Pradyumna Yadav

Slide 32

Slide 32

Meta 🔄 A Cambrian Explosion of Approaches! CC BY-SA 3.0: mariowiki.com

Slide 33

Slide 33

Meta 🔄 A Cambrian Explosion of Approaches! ☎→⚗→Gj CC BY-SA 3.0: mariowiki.com

Slide 34

Slide 34

Meta 🔄 A Cambrian Explosion of Approaches! ☎→⚗→Gj → 🍊 CC BY-SA 3.0: mariowiki.com

Slide 35

Slide 35

Meta 🔄 A Cambrian Explosion of Approaches! ☎→⚗→Gj → 🍊 → CC BY-SA 3.0: mariowiki.com

Slide 36

Slide 36

Meta 🔄 A Cambrian Explosion of Approaches! ☎→⚗→Gj → 🍊 → →💥 CC BY-SA 3.0: mariowiki.com

Slide 37

Slide 37

Meta 🔄 A Cambrian Explosion of Approaches! → ☎→⚗→Gj → 🍊 → →💥 CC BY-SA 3.0: mariowiki.com

Slide 38

Slide 38

Meta 🔄 A Cambrian Explosion of Approaches! → 🦋 → ☎→⚗→Gj → 🍊 → →💥 CC BY-SA 3.0: mariowiki.com

Slide 39

Slide 39

Meta 🔄 A Cambrian Explosion of Approaches! 🦄 → → 🦋 → ☎→⚗→Gj → 🍊 → →💥 CC BY-SA 3.0: mariowiki.com

Slide 40

Slide 40

Meta 🔄 Let’s Go Exploring! Photo credit: Chad Kohalyk

Slide 41

Slide 41

Meta 🔄 Let’s Go Exploring! • Has the world meaningfully changed? • What are the resulting tradeo s? • Is anything holding us back? ff Photo credit: Chad Kohalyk

Slide 42

Slide 42

Meta 🔄 Let’s Go Exploring! • Has the world meaningfully changed? • What are the resulting tradeo s? • Is anything holding us back? ff Photo credit: Chad Kohalyk

Slide 43

Slide 43

Meta 🔄 Balance Avoid Success at All Cost

Slide 44

Slide 44

Meta 🔄 Balance Avoid Success at All Cost

Slide 45

Slide 45

Meta 🔄 Where Do We Go From Here? Are processes central?

Slide 46

Slide 46

How We Got Here Context & Consequence 🧬

Slide 47

Slide 47

Context & Consequence 🧬 Actors in the Sky

Slide 48

Slide 48

Context & Consequence 🧬 Actors in the Sky Actors are an amazing fit for cloud computing. …why?

Slide 49

Slide 49

Context & Consequence 🧬 We All Know the Story

Slide 50

Slide 50

Context & Consequence 🧬 We All Know the Story Erlang was designed with a specific objective in mind: “to provide a better way of programming telephony applications.” […] Language features that were not used were removed. – Joe Armstrong, A History of Erlang

Slide 51

Slide 51

Context & Consequence 🧬 Good Design Tradeoffs Aguilera et al., Designing Far Memory Data Structures: Think Outside the Box (HotOS’19)

Slide 52

Slide 52

Context & Consequence 🧬 Good Design Tradeoffs 🤏 Near Memory 🪐 Far Memory Aguilera et al., Designing Far Memory Data Structures: Think Outside the Box (HotOS’19)

Slide 53

Slide 53

Context & Consequence 🧬 Good Design Tradeoffs 📍 Feels Local 🤏 Near Memory 🪐 Far Memory ✅ 🥳 Hidden, automatic 😱 Leaky abstraction 🛠 Exposing knobs Aguilera et al., Designing Far Memory Data Structures: Think Outside the Box (HotOS’19)

Slide 54

Slide 54

Context & Consequence 🧬 Good Design Tradeoffs 📍 Feels Local ✉ Feels Remote 🤏 Near Memory 🪐 Far Memory ✅ 🥳 Hidden, automatic 😱 Leaky abstraction 🛠 Exposing knobs 🥳 Powerful control 😱 Manual boilerplate 🛠 Adding abstraction ✅ Aguilera et al., Designing Far Memory Data Structures: Think Outside the Box (HotOS’19)

Slide 55

Slide 55

Context & Consequence 🧬 The Year Was 1994…

Slide 56

Slide 56

Context & Consequence 🧬 The Year Was 1994…

Slide 57

Slide 57

Context & Consequence 🧬 Cascading Architectural Decisions

Slide 58

Slide 58

Context & Consequence 🧬 Cascading Architectural Decisions 💁 🖥

Slide 59

Slide 59

Context & Consequence 🧬 Cascading Architectural Decisions 💁 🖥 🐢

Slide 60

Slide 60

Context & Consequence 🧬 Cascading Architectural Decisions 💁 🖥 🐢 🗃

Slide 61

Slide 61

Context & Consequence 🧬 Cascading Architectural Decisions 💁 🖥 🐢 ⚙ 🗃

Slide 62

Slide 62

Context & Consequence 🧬 Cascading Architectural Decisions 💁 🖥 🐢 ⚙ 🗃

Slide 63

Slide 63

Context & Consequence 🧬 Cascading Architectural Decisions 💁 💁 💁 🖥 🐢 🖥 🐢 🖥 🐢 ⚙ 🗃

Slide 64

Slide 64

Context & Consequence 🧬 Cascading Architectural Decisions 💁 💁 💁 🖥 🐢 🖥 🐢 🖥 🐢 ⚙ 🔐 🗃

Slide 65

Slide 65

Context & Consequence 🧬 Scaling Up 💁 💁 💁 🖥 🖥 🖥 🐙 ⚙ ⚙ ⚙ 🔐 🔐 🔐 🗃 🗃 🗃

Slide 66

Slide 66

Context & Consequence 🧬 Scaling Up 💁 💁 💁 🖥 🖥 🖥 🐙 ⚙ ⚙ ⚙ 🔐 🔐 🔐 🗃 🗃 🗃

Slide 67

Slide 67

Context & Consequence 🧬 Scaling Up 💁 💁 💁 🖥 🖥 🖥 ⚙ 🗃 🔐 🐙 ⚙ 🗃 “Cloud” 🔐 ⚙ 🗃 ☁ 🔐

Slide 68

Slide 68

Context & Consequence 🧬 Less is More 💁 💁 💁 🖥 🖥 🖥 ⚙ 🗃 🔐 🐙 ⚙ 🗃 “Serverless” 🔐 (Somehow⚙ MORE servers) 🗃 🌩 🔐

Slide 69

Slide 69

Context & Consequence 🧬 So Much Leakage 🚰

Slide 70

Slide 70

Context & Consequence 🧬 So Much Leakage 🚰 • Single source of truth (“the” database)

Slide 71

Slide 71

Context & Consequence 🧬 So Much Leakage 🚰 • Single source of truth (“the” database) • Server-centric • “Full stack development” • DevOps, Docker, k8s • How to train enough engineers?

Slide 72

Slide 72

Context & Consequence 🧬 So Much Leakage 🚰 • Single source of truth (“the” database) • Server-centric • “Full stack development” • DevOps, Docker, k8s • How to train enough engineers?

Slide 73

Slide 73

Context & Consequence 🧬 So Much Leakage 🚰 • Single source of truth (“the” database) • Server-centric • “Full stack development” • DevOps, Docker, k8s • How to train enough engineers? • Infrastructure Hegemony • AWS (47%), Azure (19%), GCP (9%)

Slide 74

Slide 74

Context & Consequence 🧬 So Much Leakage 🚰

Slide 75

Slide 75

Context & Consequence 🧬 So Much Leakage 🚰 …how fix? 🥺

Slide 76

Slide 76

Getting Out of the Painted Corner New Space to Play 🪁

Slide 77

Slide 77

New Space to Play 🪁 Natural Progression 📈

Slide 78

Slide 78

New Space to Play 🪁 Natural Progression 📈

Slide 79

Slide 79

New Space to Play 🪁 Natural Progression 📈 👀🦺 🫥👻 ff Invention Custom O -the-Shelf Utility

Slide 80

Slide 80

New Space to Play 🪁 Natural Progression 📈 👀🦺 🫥👻 ff Invention Custom O -the-Shelf Utility

Slide 81

Slide 81

New Space to Play 🪁 Natural Progression 📈 👀🦺 🫥👻 ff Invention Custom O -the-Shelf Utility

Slide 82

Slide 82

New Space to Play 🪁 Natural Progression 📈 👀🦺 🫥👻 ff Invention Custom O -the-Shelf Utility

Slide 83

Slide 83

New Space to Play 🪁 Natural Progression 📈 💶 👀🦺 🫥👻 ff Invention Custom O -the-Shelf Utility

Slide 84

Slide 84

New Space to Play 🪁 Natural Progression 📈 💶 👀🦺 🫥👻 ff Invention Custom O -the-Shelf Utility

Slide 85

Slide 85

New Space to Play 🪁 Natural Progression 📈 💶 👀🦺 🫥👻 ff Invention Custom O -the-Shelf Utility

Slide 86

Slide 86

New Space to Play 🪁 Evolution of Concerns Rajsbaum & Raynal, 60 Years of Mastering Concurrent Computing Through Sequential Thinking

Slide 87

Slide 87

New Space to Play 🪁 Evolution of Concerns Physical Resource Management Immaterial Objects 💿 📊 Distributed State Machines Adversaries, Asynchrony, Failure, &c Scalability ⚙ 👩🚒 🌐 Rajsbaum & Raynal, 60 Years of Mastering Concurrent Computing Through Sequential Thinking

Slide 88

Slide 88

New Space to Play 🪁 Evolution of Concerns Physical Resource Management Immaterial Objects 💿 📊 Distributed State Machines Adversaries, Asynchrony, Failure, &c Scalability ⚙ 👩🚒 🌐 Rajsbaum & Raynal, 60 Years of Mastering Concurrent Computing Through Sequential Thinking

Slide 89

Slide 89

New Space to Play 🪁 Evolution of Concerns Physical Resource Management Immaterial Objects 💿 📊 Distributed State Machines Adversaries, Asynchrony, Failure, &c Scalability ⚙ 👩🚒 🌐 Rajsbaum & Raynal, 60 Years of Mastering Concurrent Computing Through Sequential Thinking

Slide 90

Slide 90

New Space to Play 🪁 Important Progress, But Early Days ‘60 ‘70 ‘80 ‘90 ‘00 ‘10 ‘20

Slide 91

Slide 91

New Space to Play 🪁 Important Progress, But Early Days Semaphores Mutex ‘60 Distributed State Machines Concurrent Reads & ‘70 PAXOS FLP Impossibility ‘80 Byzantine Generals Problem Shared Memory In Message Passing With Crashes CALM Wait-Free Sync PBFT ‘90 ‘00 Transactional Memory CRDT CAP zk-SNARK ‘10 Nakamoto Consensus ‘20 Twizzler

Slide 92

Slide 92

Paradigm Shift Locality 🤳

Slide 93

Slide 93

Locality 🤳

Slide 94

Slide 94

Locality 🤳 […] existing infrastructure will not be able to handle the volumes or the rates We are absolutely going to return to a peer-to-peer computing […] not unlike distributed computing – Andreessen Horowitz, The End of Cloud Computing

Slide 95

Slide 95

Locality 🤳 Users vs Cloud Infra Source: AWS

Slide 96

Slide 96

Locality 🤳 Users vs Cloud Infra 6 7 6 2 1 1 1 1 Source: AWS

Slide 97

Slide 97

Locality 🤳 Users vs Cloud Infra 6 7 6 2 1 1 1 1 Source: AWS

Slide 98

Slide 98

Locality 🤳 Users vs Cloud Infra 6 7 6 2 1 1 1 1 Source: AWS

Slide 99

Slide 99

Locality 🤳 Users vs Cloud Infra 6 7 6 2 1 1 1 1 Source: AWS

Slide 100

Slide 100

Locality 🤳 Users vs Cloud Infra 6 7 2 6 50M 1 1 1 1 Source: AWS

Slide 101

Slide 101

Locality 🤳 Users vs Cloud Infra 371 million 56M/centre 6 7 2 6 50M 1 1 1 1 Source: AWS

Slide 102

Slide 102

Locality 🤳 Users vs Cloud Infra 371 million 56M/centre 6 7 2 6 50M 1 1 ~435 million 435M/centre 1 1 Source: AWS

Slide 103

Slide 103

Locality 🤳 Users vs Cloud Infra 371 million 56M/centre 6 7 2 6 50M 1 1 ~435 million 435M/centre 1 ~1.4 billion 1400M/centre 1 Source: AWS

Slide 104

Slide 104

Locality 🤳 Users vs Cloud Infra 371 million 56M/centre 6 7 2 6 50M 1 1 ~435 million 435M/centre 1 ~1.4 billion 1400M/centre 1 Source: AWS

Slide 105

Slide 105

Locality 🤳 Sending a “Direct” Message

Slide 106

Slide 106

Locality 🤳 Sending a “Direct” Message

Slide 107

Slide 107

Locality 🤳 Sending a “Direct” Message

Slide 108

Slide 108

Locality 🤳 Sending a “Direct” Message 7.2x ⏳🔋🛢🪠

Slide 109

Slide 109

Locality 🤳 Latency is a Physical Limit 🚧 • Bandwidth max not even close • Speed of light causality • Edge dominates < 40ms • Best at ~8ms • 1ms applications exist • “Ultra Reliable Low Latency” Ericsson, http://cscn2017.ieee-cscn.org/files/2017/08/Janne_Peisa_Ericsson_CSCN2017.pdf

Slide 110

Slide 110

Locality 🤳 Latency is a Physical Limit 🚧 • Bandwidth max not even close • Speed of light causality • Edge dominates < 40ms • Best at ~8ms • 1ms applications exist • “Ultra Reliable Low Latency” Ericsson, http://cscn2017.ieee-cscn.org/files/2017/08/Janne_Peisa_Ericsson_CSCN2017.pdf

Slide 111

Slide 111

Locality 🤳 Latency is a Physical Limit 🚧 • Bandwidth max not even close • Speed of light causality • Edge dominates < 40ms • Best at ~8ms • 1ms applications exist • “Ultra Reliable Low Latency” Ericsson, http://cscn2017.ieee-cscn.org/files/2017/08/Janne_Peisa_Ericsson_CSCN2017.pdf

Slide 112

Slide 112

Locality 🤳

Slide 113

Slide 113

Locality 🤳 By 2025, 75% of data will be processed outside the traditional data centre or cloud – Gartner, What Edge Computing Means for Infrastructure and Operations Leaders

Slide 114

Slide 114

Locality 🤳 edge, on de vice, etc By 2025, 75% of data will be processed outside the traditional data centre or cloud – Gartner, What Edge Computing Means for Infrastructure and Operations Leaders

Slide 115

Slide 115

Locality 🤳 edge, on de vice, etc By 2025, 75% of data will be processed outside the traditional data centre or cloud – Gartner, What Edge Computing Means for Infrastructure and Operations Leaders

Slide 116

Slide 116

Locality 🤳 New Environment

Slide 117

Slide 117

Locality 🤳 New Environment Then 📠 Now 🚀

Slide 118

Slide 118

Locality 🤳 New Environment Need Then 📠 Now 🚀 Convenient 💁 Critical 🚨

Slide 119

Slide 119

Locality 🤳 New Environment Then 📠 Now 🚀 Need Convenient 💁 Critical 🚨 Location Data Centre 🏢 Powerful Clients (M1, IoT) ⌚🚙👟

Slide 120

Slide 120

Locality 🤳 New Environment Then 📠 Now 🚀 Need Convenient 💁 Critical 🚨 Location Data Centre 🏢 Powerful Clients (M1, IoT) ⌚🚙👟 🖥 📱 Access

Slide 121

Slide 121

Locality 🤳 New Environment Then 📠 Now 🚀 Need Convenient 💁 Critical 🚨 Location Data Centre 🏢 Powerful Clients (M1, IoT) ⌚🚙👟 🖥 📱 Bandwidth 🚚 Latency ⏲ Access Bottleneck

Slide 122

Slide 122

Locality 🤳 New Environment Then 📠 Now 🚀 Need Convenient 💁 Critical 🚨 Location Data Centre 🏢 Powerful Clients (M1, IoT) ⌚🚙👟 🖥 📱 Bandwidth 🚚 Latency ⏲ 🇺🇸🇪🇺 🌎🌍🌏 … 🌔 Access Bottleneck Market

Slide 123

Slide 123

Locality 🤳 A New Topology

Slide 124

Slide 124

Locality 🤳 A New Topology 🤳

Slide 125

Slide 125

Locality 🤳 A New Topology 🛰 🤳 🗼 💾⚙

Slide 126

Slide 126

Locality 🤳 A New Topology 🛰 🤳 🗼 💾⚙ 🏢 💾⚙

Slide 127

Slide 127

Locality 🤳 A New Topology 🛰 🤳 🗼 💾⚙ 🏢 💾⚙ ☁ 💾⚙ ⚙ 💾 ⚙ 💾 ⚙ 💾 💾⚙ ⚙

Slide 128

Slide 128

Locality 🤳 A New Topology 🛰 🤳 🗼 💾⚙ 🐇 🛰 🛰 🏢 ☁ 💾⚙ 💾⚙ ⚙ 💾 ⚙ 💾 ⚙ 💾 💾⚙ ⚙ 🐘

Slide 129

Slide 129

Locality 🤳 A New Topology 🛰 Local 🤳 First 🐇 🗼 💾⚙ 🛰 🛰 🏢 ☁ 💾⚙ 💾⚙ ⚙ 💾 ⚙ 💾 ⚙ 💾 💾⚙ ⚙ 🐘

Slide 130

Slide 130

Locality 🤳 A New Topology 🛰 Local 🤳 First 🐇 🗼 Realtime, Storage, Caching, OLTP 💾⚙ 🛰 🛰 🏢 ☁ 💾⚙ 💾⚙ ⚙ 💾 ⚙ 💾 ⚙ 💾 💾⚙ ⚙ 🐘

Slide 131

Slide 131

Locality 🤳 A New Topology 🛰 Local 🤳 First 🐇 🗼 Realtime, Storage, Caching, OLTP 💾⚙ 🛰 Relay, Replication, Consistency, Tasks 💾⚙ 🏢 🛰 ☁ 💾⚙ ⚙ 💾 ⚙ 💾 ⚙ 💾 💾⚙ ⚙ 🐘

Slide 132

Slide 132

Locality 🤳 A New Topology 🛰 Local 🤳 First 🐇 🗼 Realtime, Storage, Caching, OLTP 💾⚙ 🛰 Relay, Replication, Consistency, Tasks 💾⚙ 🏢 🛰 ☁ Aggregation, Batching, Training, ⚙ 💾 ⚙ 💾 ⚙ 💾 OLAP ⚙ 💾 💾⚙ ⚙ 🐘

Slide 133

Slide 133

Locality 🤳 Evolving Toolbox Serverless Networked Data Cloud Commons Networks Local-First Blockchain O ffl P2P ine

Slide 134

Slide 134

Locality 🤳 Evolving Toolbox Serverless Networked Data Radical shifts how we think about auth, locality of reference, ownership, and reliability Cloud Commons Networks Local-First Blockchain O ffl P2P ine

Slide 135

Slide 135

Let Them Eat CAP Consistency is a Lie 🍰

Slide 136

Slide 136

Let Them Eat CAP Consistency is a Lie 🍰

Slide 137

Slide 137

Consistency is a Lie 🍰

Slide 138

Slide 138

Consistency is a Lie 🍰 The limitation of local knowledge is the fundamental fact about the setting in which we work, and it is a very powerful limitation – Nancy Lynch, A Hundred Impossibility Proofs for Distributed Computing

Slide 139

Slide 139

Consistency is a Lie 🍰 CAP → PACELC 📦🦌 Daniel J. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design

Slide 140

Slide 140

Consistency is a Lie 🍰 CAP → PACELC 📦🦌 • If network partition, pick from: • Availability (A) ✅ Uptime! • Consistency (C) Daniel J. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design

Slide 141

Slide 141

Consistency is a Lie 🍰 CAP → PACELC 📦🦌 • If network partition, pick from: C • Availability (A) ✅ Uptime! • Consistency (C) A Daniel J. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design

Slide 142

Slide 142

Consistency is a Lie 🍰 CAP → PACELC 📦🦌 • If network partition, pick from: C • Availability (A) ✅ Uptime! P • Consistency (C) A Daniel J. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design

Slide 143

Slide 143

Consistency is a Lie 🍰 CAP → PACELC 📦🦌 • If network partition, pick from: C • Availability (A) ✅ Uptime! P • Consistency (C) • Else (E) running normally, pick from: A • Latency (L) ✅ Speed! • Consistency (C) Daniel J. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design

Slide 144

Slide 144

Consistency is a Lie 🍰 CAP → PACELC 📦🦌 • If network partition, pick from: C • Availability (A) ✅ Uptime! P E • Consistency (C) • Else (E) running normally, pick from: A L • Latency (L) ✅ Speed! • Consistency (C) Daniel J. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design

Slide 145

Slide 145

Consistency is a Lie 🍰 CAP → PACELC 📦🦌 • If network partition, pick from: C • Availability (A) ✅ Uptime! P E • Consistency (C) • Else (E) running normally, pick from: A L • Latency (L) ✅ Speed! • Consistency (C) Daniel J. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design

Slide 146

Slide 146

Consistency is a Lie 🍰 CAP → PACELC 📦🦌 • If network partition, pick from: C • Availability (A) ✅ Uptime! P E • Consistency (C) • Else (E) running normally, pick from: • Latency (L) ✅ Speed! A L PA/EL • Consistency (C) Daniel J. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design

Slide 147

Slide 147

Consistency is a Lie 🍰 Causal Islands 🏖🏝 Meiklejohn, A Certain Tendency Of The Database Community

Slide 148

Slide 148

Consistency is a Lie 🍰 Causal Islands 🏖🏝 Meiklejohn, A Certain Tendency Of The Database Community

Slide 149

Slide 149

Consistency is a Lie 🍰 Causal Islands 🏖🏝 Meiklejohn, A Certain Tendency Of The Database Community

Slide 150

Slide 150

Consistency is a Lie 🍰 Causal Islands 🏖🏝 Meiklejohn, A Certain Tendency Of The Database Community

Slide 151

Slide 151

Consistency is a Lie 🍰 Causal Islands 🏖🏝 Meiklejohn, A Certain Tendency Of The Database Community

Slide 152

Slide 152

Consistency is a Lie 🍰 Causal Islands 🏖🏝 Meiklejohn, A Certain Tendency Of The Database Community

Slide 153

Slide 153

Consistency is a Lie 🍰 Causal Islands 🏖🏝 Meiklejohn, A Certain Tendency Of The Database Community

Slide 154

Slide 154

Consistency is a Lie 🍰 Causal Islands 🏖🏝 “Causal Subjectivity” Meiklejohn, A Certain Tendency Of The Database Community

Slide 155

Slide 155

Consistency is a Lie 🍰

Slide 156

Slide 156

Consistency is a Lie 🍰 As we continue to increase the number of globally connected devices, we must embrace a design that considers every single member in the system as the primary site for the data that it is generates. It is completely impractical that we can look at a single, or a small number, of globally distributed data centers as the primary site for all global information that we desire to perform computations with. – Christopher Meiklejohn, A Certain Tendency Of The Database Community

Slide 157

Slide 157

Place & Time PLOP 🗺

Slide 158

Slide 158

Place & Time PLOP 🗺

Slide 159

Slide 159

PLOP 🗺

Slide 160

Slide 160

PLOP 🗺 As data becomes increasingly distributed, traditional RPC and data serialization limits performance, result in rigidity, and hamper expressivity – Bittman et al, Don’t Let RPCs Constrain Your API

Slide 161

Slide 161

PLOP 🗺 Small Steps in Aggregate

Slide 162

Slide 162

PLOP 🗺 Small Steps in Aggregate 🛠 💿 📨 📨 ⚒ 📀

Slide 163

Slide 163

PLOP 🗺 Small Steps in Aggregate 🛠 💿 📨 ✉ 📨 ⚒ 📀

Slide 164

Slide 164

PLOP 🗺 Small Steps in Aggregate 🛠 💿 📨 ✉ 📨 ⚒ 📀

Slide 165

Slide 165

PLOP 🗺 Irreducible Complexity

Slide 166

Slide 166

PLOP 🗺 Irreducible Complexity 💿 👨🎤 📨 💿 👩🎤 📨 💿 🧑🎤 📨

Slide 167

Slide 167

PLOP 🗺 Irreducible Complexity 💿 👨🎤 📨 💿 👩🎤 📨 💿 🧑🎤 📨 ✉ ✉ ✉ ✉ ✉ ✉ ✉ ✉ ✉ ✉ ✉ ✉

Slide 168

Slide 168

PLOP 🗺 Irreducible Complexity 💿 👨🎤 📨 ✉ ✉ ✉ ✉ 🔒 💿 👩🎤 📨 💿 🧑🎤 📨 ✉ ✉ ✉ ✉ ✉ ✉ ✉ ✉

Slide 169

Slide 169

PLOP 🗺 Irreducible Complexity 💿 👨🎤 📨 ✉ ✉ ✉ ✉ 🔒 💿 👩🎤 ☠📨 💿 🧑🎤 📨 ✉ ✉ ✉ ✉ ✉ ✉ ✉ ✉

Slide 170

Slide 170

PLOP 🗺 Irreducible Complexity 💿 👨🎤 📨 ✉ ✉ ✉ ✉ 🔒 🫠 💿 👩🎤 ☠📨 💿 🧑🎤 📨 ✉ ✉ ✉ ✉ ✉ ✉ ✉ ✉

Slide 171

Slide 171

PLOP 🗺 Coordination Costs

Slide 172

Slide 172

PLOP 🗺 Throughput Coordination Costs Parallelization

Slide 173

Slide 173

PLOP 🗺 Ideal (Linear) Throughput Coordination Costs Parallelization

Slide 174

Slide 174

PLOP 🗺 Coordination Costs Ideal (Linear) Throughput Amdahl’s Law Parallelization

Slide 175

Slide 175

PLOP 🗺 Coordination Costs Ideal (Linear) Throughput Amdahl’s Law Universal Scaling Law Parallelization

Slide 176

Slide 176

PLOP 🗺 Coordination Costs Ideal (Linear) Throughput Amdahl’s Law Incoherence, Data Contention Universal Scaling Law Parallelization

Slide 177

Slide 177

PLOP 🗺 Semantics Non-Preservation https://www.hillelwayne.com/post/spec-composition/

Slide 178

Slide 178

PLOP 🗺 Semantics Non-Preservation 👨🎨 🧑🎤 👩🌾 https://www.hillelwayne.com/post/spec-composition/

Slide 179

Slide 179

PLOP 🗺 Semantics Non-Preservation 👨🎨 🧑🎤 👩🌾 https://www.hillelwayne.com/post/spec-composition/

Slide 180

Slide 180

PLOP 🗺 Semantics Non-Preservation 👨🎨 🧑🎤 👩🌾 👽 🛸 🧙 https://www.hillelwayne.com/post/spec-composition/

Slide 181

Slide 181

PLOP 🗺 Semantics Non-Preservation 👨🎨 🧑🎤 👩🌾 Changes the meaning 👽 🛸 🧙 https://www.hillelwayne.com/post/spec-composition/

Slide 182

Slide 182

PLOP 🗺 Bad Actors 👨🎨 🧑🎤 👩🌾

Slide 183

Slide 183

PLOP 🗺 Bad Actors 👨🎨 🧑🎤 👩🌾

Slide 184

Slide 184

PLOP 🗺 Bad Actors 👨🎨 🧑🎤 👩🌾

Slide 185

Slide 185

PLOP 🗺 Bad Actors 👨🎨 🧑🎤 👩🌾

Slide 186

Slide 186

PLOP 🗺 Bad Actors 👨🎨 🧑🎤 👩🌾

Slide 187

Slide 187

PLOP 🗺 Bad Actors 😈 👨🎨 🧑🎤 👩🌾

Slide 188

Slide 188

PLOP 🗺 Bad Actors 😈 👨🎨 🧑🎤 👩🌾

Slide 189

Slide 189

PLOP 🗺 And Yet…

Slide 190

Slide 190

PLOP 🗺 And Yet… These metastable failures have caused widespread outages at large internet companies, lasting from minutes to hours. Paradoxically, the root cause of these failures is often features that improve the efficiency or reliability of the system. – Bronson et al, Metastable Failures in Distributed Systems

Slide 191

Slide 191

PLOP 🗺 The Great 73-Hour Roblox Outage of 2021 https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/ https://www.theverge.com/2021/10/30/22754107/roblox-down-outage-chipotle-server-issues-status

Slide 192

Slide 192

PLOP 🗺 The Great 73-Hour Roblox Outage of 2021 https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/ https://www.theverge.com/2021/10/30/22754107/roblox-down-outage-chipotle-server-issues-status

Slide 193

Slide 193

PLOP 🗺 The Great 73-Hour Roblox Outage of 2021 https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/ https://www.theverge.com/2021/10/30/22754107/roblox-down-outage-chipotle-server-issues-status

Slide 194

Slide 194

PLOP 🗺 The Great 73-Hour Roblox Outage of 2021 👀 https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/ https://www.theverge.com/2021/10/30/22754107/roblox-down-outage-chipotle-server-issues-status

Slide 195

Slide 195

PLOP 🗺 The Great 73-Hour Roblox Outage of 2021 🧨 👀 https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/ https://www.theverge.com/2021/10/30/22754107/roblox-down-outage-chipotle-server-issues-status

Slide 196

Slide 196

PLOP 🗺 Paradoxical Performance

Slide 197

Slide 197

PLOP 🗺 Paradoxical Performance [Streaming was] designed to lower the CPU usage and network bandwidth of the Consul cluster, [and] worked as expected […] In order to prepare for the increased traffic we typically see at the end of the year, we also increased the number of nodes supporting traffic routing by 50%. […] Under very high load [this] causes blocking during writes, making it significantly less efficient. This behavior also explained the effect of higher corecount servers: those servers were dual socket architectures with a NUMA memory model. The additional contention on shared resources thus got worse under this architecture. — Daniel Sturman & co, Roblox Return to Service 10/28-10/31 2021

Slide 198

Slide 198

PLOP 🗺 Metastable Mechanism Bronson et al, Metastable Failures in Distributed Systems

Slide 199

Slide 199

PLOP 🗺 Metastable Mechanism Bronson et al, Metastable Failures in Distributed Systems

Slide 200

Slide 200

PLOP 🗺 Metastable Mechanism ⚡ ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 201

Slide 201

PLOP 🗺 Metastable Mechanism ⚡ ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 202

Slide 202

PLOP 🗺 Metastable Mechanism ⚡ ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 203

Slide 203

PLOP 🗺 Metastable Mechanism ⚡ ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 204

Slide 204

PLOP 🗺 Metastable Mechanism ⚡ ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 205

Slide 205

PLOP 🗺 Metastable Mechanism ⚡ ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 206

Slide 206

PLOP 🗺 Metastable Mechanism ⚡ ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 207

Slide 207

PLOP 🗺 Metastable Mechanism ⚡ ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 208

Slide 208

PLOP 🗺 Metastable Mechanism ⚡ 🛑 ⚖ Bronson et al, Metastable Failures in Distributed Systems

Slide 209

Slide 209

PLOP 🗺 Metastable Mechanism ⚡ 🛑 • Retries / let it crash • Work amplification ⚖ • General thrash 🫡 Bronson et al, Metastable Failures in Distributed Systems

Slide 210

Slide 210

PLOP 🗺 Values Over Time

Slide 211

Slide 211

PLOP 🗺 Values Over Time Places are “a” way to organize concurrency. They are not “the” way.

Slide 212

Slide 212

Nine Nines Is So 1999 Massive Reliability 🏔

Slide 213

Slide 213

Massive Reliability 🏔

Slide 214

Slide 214

Massive Reliability 🏔 You can never step into the same river twice – Heraclitus

Slide 215

Slide 215

Massive Reliability 🏔 process You can never step into the same river twice – Heraclitus

Slide 216

Slide 216

Massive Reliability 🏔 Values ≠ References ≠ Processes

Slide 217

Slide 217

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate

Slide 218

Slide 218

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate • Modular! Mobile! Universal!

Slide 219

Slide 219

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate • Modular! Mobile! Universal! • “Pure”

Slide 220

Slide 220

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate • Modular! Mobile! Universal! • “Pure” • Compared by equality

Slide 221

Slide 221

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate • Modular! Mobile! Universal! • “Pure” • Compared by equality • Processes occur over time

Slide 222

Slide 222

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate • Modular! Mobile! Universal! • “Pure” • Compared by equality • Processes occur over time • Can move, but always unique

Slide 223

Slide 223

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate • Modular! Mobile! Universal! • “Pure” • Compared by equality • Processes occur over time • Can move, but always unique • Actors colocate mutable references with processes

Slide 224

Slide 224

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate • Modular! Mobile! Universal! • “Pure” • Compared by equality • Processes occur over time • Can move, but always unique • Actors colocate mutable references with processes • Specific interface

Slide 225

Slide 225

Massive Reliability 🏔 Values ≠ References ≠ Processes • Values are eternal • Only pointers mutate • Modular! Mobile! Universal! • “Pure” • Compared by equality • Processes occur over time • Can move, but always unique • Actors colocate mutable references with processes • Specific interface • Often limited reuse, especially when distributed

Slide 226

Slide 226

Massive Reliability 🏔 Decoupling, Abundance, Redundancy

Slide 227

Slide 227

Massive Reliability 🏔 Decoupling, Abundance, Redundancy 🖼 99.99999%

Slide 228

Slide 228

Massive Reliability 🏔 Decoupling, Abundance, Redundancy 🖼 99.99999% 🖼 99.0% 🖼 99.99% 🖼 99.999%

Slide 229

Slide 229

Massive Reliability 🏔 Decoupling, Abundance, Redundancy 🖼 99.99999% 🖼 99.0% 🖼 99.99% 🖼 99.999%

Slide 230

Slide 230

Massive Reliability 🏔 Decoupling, Abundance, Redundancy 🖼 99.99999% 👩🎤 🖼 99.0% 🖼 99.99% 🖼 99.999%

Slide 231

Slide 231

Massive Reliability 🏔 Decoupling, Abundance, Redundancy 🖼 99.99999% 👩🎤 🖼 99.0% 🖼 99.99% 🖼 99.999% 👩🎤 🧑🎤

Slide 232

Slide 232

Massive Reliability 🏔 Decoupling, Abundance, Redundancy 🖼 99.99999% 👩🎤 🖼 99.0% 🖼 99.99% 🖼 99.999% 👩🎤 🧑🎤

Slide 233

Slide 233

Massive Reliability 🏔 Decoupling, Abundance, Redundancy 🖼 99.99999% 👩🎤 🖼 99.0% 🖼 99.99% 🖼 99.999% 11-nines 👩🎤 🧑🎤

Slide 234

Slide 234

Massive Reliability 🏔 Decoupling, Abundance, Redundancy 🖼 👩🎤 99.99999% 👩🎤 🖼 99.0% 🧑🎤 🖼 99.99% 🖼 99.999% 11-nines 👩🎤

Slide 235

Slide 235

Massive Reliability 🏔 Pure Parallel

Slide 236

Slide 236

Massive Reliability 🏔 Pure Parallel

Slide 237

Slide 237

Massive Reliability 🏔 Pure Parallel

Slide 238

Slide 238

Massive Reliability 🏔 Pure Parallel

Slide 239

Slide 239

Massive Reliability 🏔 Pure Parallel

Slide 240

Slide 240

Massive Reliability 🏔 Pure Parallel Commutes!

Slide 241

Slide 241

Massive Reliability 🏔 Pure Parallel Commutes!

Slide 242

Slide 242

Massive Reliability 🏔 Pure Parallel Commutes!

Slide 243

Slide 243

Massive Reliability 🏔 Pure Parallel Commutes!

Slide 244

Slide 244

Massive Reliability 🏔 DB.static_fetch Pure Parallel msg recipient upcase last_update sign Email.send Commutes!

Slide 245

Slide 245

Massive Reliability 🏔 DB.static_fetch Pure Parallel msg recipient upcase Pure: run anywhere, by anyone last_update sign Email.send Commutes!

Slide 246

Slide 246

Massive Reliability 🏔 PIDs for Values & CAS Transactions 📰 🪩 🧸 📔 🪪 🧾 👑 https://www.cs.umd.edu/~jkatz/papers/ADS.pdf https://cs.nyu.edu/~fazio/research/publications/accumulators.pdf

Slide 247

Slide 247

Massive Reliability 🏔 PIDs for Values & CAS Transactions 123 ACF CF4 C4A 0FC 1F3 📰 A83 🪩 ED2 🧸 D55 823 247 81D F0A 📔 🪪 🧾 B92 👑 https://www.cs.umd.edu/~jkatz/papers/ADS.pdf https://cs.nyu.edu/~fazio/research/publications/accumulators.pdf

Slide 248

Slide 248

Massive Reliability 🏔 PIDs for Values & CAS Transactions 123 ACF CF4 C4A 0FC 1F3 📰 A83 🪩 ED2 🧸 D55 823 247 81D F0A 📔 🪪 🧾 B92 👑 https://www.cs.umd.edu/~jkatz/papers/ADS.pdf https://cs.nyu.edu/~fazio/research/publications/accumulators.pdf

Slide 249

Slide 249

Massive Reliability 🏔 PIDs for Values & CAS Transactions 123 ACF CF4 C4A 0FC 1F3 📰 A83 🪩 ED2 🧸 D55 823 247 81D F0A 📔 🪪 🧾 B92 👑 https://www.cs.umd.edu/~jkatz/papers/ADS.pdf https://cs.nyu.edu/~fazio/research/publications/accumulators.pdf

Slide 250

Slide 250

Massive Reliability 🏔 PIDs for Values & CAS Transactions A7B ACF CF4 👩💻 C4A 0FC 1F3 📰 A83 🪩 ED2 🧸 D55 823 247 81D F0A 📔 🪪 🧾 B92 👑 https://www.cs.umd.edu/~jkatz/papers/ADS.pdf https://cs.nyu.edu/~fazio/research/publications/accumulators.pdf

Slide 251

Slide 251

Massive Reliability 🏔 PIDs for Values & CAS Transactions A7B ACF CF4 👩💻 C4A 0FC 1F3 📰 A83 🪩 ED2 🧸 D55 823 247 81D F0A 📔 🪪 🧾 B92 👑 https://www.cs.umd.edu/~jkatz/papers/ADS.pdf https://cs.nyu.edu/~fazio/research/publications/accumulators.pdf

Slide 252

Slide 252

Beyond Services, Beyond Open Source Trustless Modularity 🔌

Slide 253

Slide 253

Trustless Modularity 🔌

Slide 254

Slide 254

Trustless Modularity 🔌 Jesper, I have this idea in which we’ll connect all of the worlds Erlang systems to each other, imagine if every process could talk to every other process, world-wide! – Joe Armstrong to Jesper L. Andersen

Slide 255

Slide 255

Trustless Modularity 🔌 Jesper, I have this idea in which we’ll connect all of the worlds Erlang systems to each other, imagine if every process could talk to every other process, world-wide! , s n o i t a c d i e l t p a p i a t o L g e L n A e r p t o n f i n eve – Joe Armstrong to Jesper L. Andersen

Slide 256

Slide 256

Trustless Modularity 🔌

Slide 257

Slide 257

Trustless Modularity 🔌 What happens when everything is reachable by default?

Slide 258

Slide 258

Trustless Modularity 🔌 PLOP 🤝 ACLs

Slide 259

Slide 259

Trustless Modularity 🔌 PLOP 🤝 ACLs 🧑🌾

Slide 260

Slide 260

Trustless Modularity 🔌 PLOP 🤝 ACLs 🧑🌾 ⚙

Slide 261

Slide 261

Trustless Modularity 🔌 PLOP 🤝 ACLs 🧑🌾 💂 ✋ ⚙

Slide 262

Slide 262

Trustless Modularity 🔌 PLOP 🤝 ACLs 🧑🌾 📑 💂 ✋ ⚙

Slide 263

Slide 263

Trustless Modularity 🔌 PLOP 🤝 ACLs 🧑🌾 📑 💂 ✋ ⚙

Slide 264

Slide 264

Trustless Modularity 🔌 PLOP 🤝 ACLs 🧑🌾 📑 💂 ✋ ⚙

Slide 265

Slide 265

Trustless Modularity 🔌 PLOP 🤝 ACLs 🧑🌾 📑 💂 ✋ Not in control ⚙

Slide 266

Slide 266

Trustless Modularity 🔌 PLOP 🤝 ACLs 📑 In control 🧑🌾 💂 ✋ Not in control ⚙

Slide 267

Slide 267

Trustless Modularity 🔌 PLOP 🤝 ACLs 📑 In control 🧑🌾 💂 ✋ Not in control ⚙

Slide 268

Slide 268

Trustless Modularity 🔌 PLOP 🤝 ACLs 📑 💂 ✋ In control 🧑🌾 💂 ✋ Not in control ⚙

Slide 269

Slide 269

Trustless Modularity 🔌 Trustless SPKI

Slide 270

Slide 270

Trustless Modularity 🔌 Trustless SPKI 🕵

Slide 271

Slide 271

Trustless Modularity 🔌 Trustless SPKI 🕵 📬

Slide 272

Slide 272

Trustless Modularity 🔌 Trustless SPKI PID ✊ ✊ 🕵 🗺 📬

Slide 273

Slide 273

Trustless Modularity 🔌 Trustless SPKI PID ✊ ✊ 🕵 🗺 💌 📬

Slide 274

Slide 274

Trustless Modularity 🔌 Trustless SPKI 🕵 PID ✊ ✊ 🕵 🗺 💌 📬

Slide 275

Slide 275

Trustless Modularity 🔌 Trustless SPKI 🕵 PID ✊ ✊ 🕵 🗺 ⚙ 💌 📬

Slide 276

Slide 276

Trustless Modularity 🔌 Trustless SPKI 🕵 🗺 🕵 🗺 ⚙ ✊ ✊ PID ✊ ✊ Addr 💌 📬

Slide 277

Slide 277

Trustless Modularity 🔌 Trustless SPKI ✊ ⚙ PID 💌 📬 ✊ Addr 🎟 ✊ 🕵 🗺 🕵 🗺 ✊

Slide 278

Slide 278

Trustless Modularity 🔌 Trustless SPKI ✊ ⚙ PID 💌 📬 ✊ Addr 🎟 ✊ 🕵 🗺 🕵 🗺 In control ✊

Slide 279

Slide 279

Trustless Modularity 🔌 Trustless SPKI 🕵 🗺 🕵 🗺 ✊ ✊ PID ✊ ✊ Addr In control 🎟 ⚙ All req info 💌 📬

Slide 280

Slide 280

Trustless Modularity 🔌 Trustless SPKI ✊ ⚙ PID 💌 📬 ✊ Addr 🎟 ✊ 🕵 🗺 🕵 🗺 ✊

Slide 281

Slide 281

Trustless Modularity 🔌 Trustless SPKI ✊ PID 📬 ✊ Addr ⚙ ✊ 🕵 🎟 🗺 🎟 🎟 🕵 💌 🗺 💌 💌 ✊

Slide 282

Slide 282

Trustless Modularity 🔌 Trustless SPKI ✊ ⚙ PID 💌 📬 ✊ Addr 🎟 ✊ 🕵 🗺 🕵 🗺 ✊

Slide 283

Slide 283

Trustless Modularity 🔌 Trustless SPKI ✊ ⚙ 🧑🎨 PID 💌 📬 ✊ Addr 🎟 ✊ 🕵 🗺 🕵 🗺 ✊

Slide 284

Slide 284

Trustless Modularity 🔌 Trustless SPKI 🕵 🗺 🕵 🗺 ✊ ✊ PID ✊ ✊ Addr 🎟 💌 ⚙ 🧑🎨 🗺 📬

Slide 285

Slide 285

Trustless Modularity 🔌 Trustless SPKI 🕵 🗺 🕵 🗺 ✊ ✊ PID ✊ ✊ Addr 🎟 💌 ⚙ 🧑🎨 🗺 📬 💌

Slide 286

Slide 286

👨🎨 Trustless Modularity 🔌 Trustless SPKI 🕵 🗺 🕵 🗺 ✊ ✊ PID ✊ ✊ Addr 🎟 💌 ⚙ 🧑🎨 🗺 📬 💌

Slide 287

Slide 287

👨🎨 Trustless Modularity 🔌 Trustless SPKI 🕵 🗺 🕵 🗺 ✊ ✊ PID ✊ ✊ Addr 🎟 💌 🎟 🗺 ⚙ 🧑🎨 📬 💌

Slide 288

Slide 288

👨🎨 Trustless Modularity 🔌 Trustless SPKI 🕵 🗺 🕵 🗺 ✊ ✊ PID ✊ ✊ Addr 🎟 💌 🎟 🗺 🎟 ⚙ 🧑🎨 📬 💌

Slide 289

Slide 289

Trustless Modularity 🔌

Slide 290

Slide 290

Trustless Modularity 🔌 We have a system that applies cutting edge CS research to tackle day-to-day problems in the applications we all write. Phoenix Presence - has no single point of failure - has no single source of truth -[…] - self heals ~ Chris McCord, “What Makes Phoenix Presence Special”

Slide 291

Slide 291

Trustless Modularity 🔌 Phoenix LiveView

Slide 292

Slide 292

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻

Slide 293

Slide 293

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾

Slide 294

Slide 294

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 💾💾💾💾 🗃 ⚙ WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾

Slide 295

Slide 295

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 💾💾💾💾 🗃 ⚙ WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾

Slide 296

Slide 296

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 💾💾💾💾 🗃 ⚙ WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾

Slide 297

Slide 297

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 💾💾💾💾 🗃 ⚙ WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾

Slide 298

Slide 298

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 💾💾💾💾 🗃 ⚙ ⚙ WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾

Slide 299

Slide 299

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 💾💾💾💾 🗃 ⚙ ⚙ WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾 🖥 💾

Slide 300

Slide 300

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 💾💾💾💾 🗃 ⚙ ⚙ WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾 🖥 💾

Slide 301

Slide 301

Trustless Modularity 🔌 Phoenix LiveView Users 👨🏫👩🏭🧑⚕👷 Client 🖥 💾💾💾💾 🗃 ⚙ ⚙ WSS / REST / GraphQL ↕ Controller Logic ⚙ Data Store 🗃 DevOps 📤 Developer 👩💻 🖥 💾 🖥 💾

Slide 302

Slide 302

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 303

Slide 303

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 304

Slide 304

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 305

Slide 305

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 306

Slide 306

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 307

Slide 307

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 308

Slide 308

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 309

Slide 309

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 310

Slide 310

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 311

Slide 311

Trustless Modularity 🔌 Tug of War 🪢🕊 🤳 🗃

Slide 312

Slide 312

Trustless Modularity 🔌 LiveView Inside Out 🐣 🖥 💾💾 🖥 💾💾💾 ⚙ 💾 🗃

Slide 313

Slide 313

Trustless Modularity 🔌 LiveView Inside Out 🐣 🖥 💾💾 🖥 💾💾💾 ⚙ 💾 🗃 “P2P is the new client-server” – Joe Armstrong, Building Highly Available Systems in Erlang

Slide 314

Slide 314

Trustless Modularity 🔌 Reading the Universal Dataspace🪐🔮

Slide 315

Slide 315

Trustless Modularity 🔌 Reading the Universal Dataspace🪐🔮 📁 📰 📁 📁 📁 📅 📁 📁 📁 📁 📁 📑 📊 📉 📑 📜 📑 📈

Slide 316

Slide 316

Trustless Modularity 🔌 Reading the Universal Dataspace🪐🔮 👨🏫 👩🔬 📁 📁 📰 📁 📁 📅 📁 📁 📁 📁 📁 📑 📊 📉 📑 📜 📑 📈 🧑🌾

Slide 317

Slide 317

Trustless Modularity 🔌 Reading the Universal Dataspace🪐🔮 👨🏫 👩🔬 📁 📁 📰 📁 📁 📅 📁 📁 📁 📁 📁 📑 📊 📉 📑 📜 📑 📈 🧑🌾

Slide 318

Slide 318

Trustless Modularity 🔌 Reading the Universal Dataspace🪐🔮 👨🏫 👩🔬 📁 📁 📰 📁 📁 📅 📁 📁 📁 📁 📁 📑 📊 📉 📑 📜 📑 📈 🧑🌾

Slide 319

Slide 319

Trustless Modularity 🔌 Reading the Universal Dataspace🪐🔮 👨🏫 👩🔬 📁 📁 📰 📁 📁 📅 📁 📁 📁 📁 📁 📑 📊 📉 📑 📜 📑 📈 🧑🌾

Slide 320

Slide 320

Trustless Modularity 🔌 Different Viewers ~ Schema Drift 🔍 https://www.inkandswitch.com/cambria.html

Slide 321

Slide 321

Trustless Modularity 🔌 Properties & Time Travel

Slide 322

Slide 322

Let’s Build Better Together The Soul of a New BEAM 🌈🌈

Slide 323

Slide 323

The Soul of a New BEAM 🌈 BEAM Me Up ✨💎🪐🚀✨ 📱💻🖥⚙

Slide 324

Slide 324

The Soul of a New BEAM 🌈 (Neither “Web” Nor “Assembly”) …One More Thing

Slide 325

Slide 325

The Soul of a New BEAM 🌈 Further Reading 📚

Slide 326

Slide 326

The Soul of a New BEAM 🌈 ff Further Reading 📚 • Peter Alvaro — CALM, Twizzler • Christopher Meiklejohn— Lasp, Partisan • Martin Kleppmann — Automerge, BFT-CRDT • Lindsey Kuper — LVar, Deterministic Parallelism • Joseph Hellerstein — BOOM, Distributed Logic • Geo rey Litt — Cambria, BYOC

Slide 327

Slide 327

The Soul of a New BEAM 🌈 We’re Uniquely Qualified

Slide 328

Slide 328

The Soul of a New BEAM 🌈 We’re Uniquely Qualified 1. Embrace the subjective nature of reality 🤗👀

Slide 329

Slide 329

The Soul of a New BEAM 🌈 We’re Uniquely Qualified 1. Embrace the subjective nature of reality 🤗👀 2. Values are redundant & cache friendly

Slide 330

Slide 330

The Soul of a New BEAM 🌈 We’re Uniquely Qualified 1. Embrace the subjective nature of reality 🤗👀 2. Values are redundant & cache friendly 3. Openly interoperate from the ground up

Slide 331

Slide 331

The Soul of a New BEAM 🌈 We’re Uniquely Qualified 1. Embrace the subjective nature of reality 🤗👀 2. Values are redundant & cache friendly 3. Openly interoperate from the ground up 4. Massive reliability in a time of abundant disk

Slide 332

Slide 332

The Soul of a New BEAM 🌈 We’re Uniquely Qualified 1. Embrace the subjective nature of reality 🤗👀 2. Values are redundant & cache friendly 3. Openly interoperate from the ground up 4. Massive reliability in a time of abundant disk 5. Build a Wasm solution… stat!

Slide 333

Slide 333

🎉 Thank You, Stockholm! 🇸🇪 https://lu.ma/distributed-systems https://fission.codes/discord github.com/expede @expede