thinking asynchronously: events on the realtime web

Post on 20-Dec-2014

351 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

My presentation (speaking as Sherwood McGraw) at the most recent, best, and final RealtimeConf. To really understand the implications of asynchronous distributed systems, it's helpful to think about things from the point of view of the data, and to get as explicit as possible about how your data models and flows bind time and space together.

TRANSCRIPT

Thinking asynchronouslySherwood McGraw

des. rep. Peer Anarchy, es262 librarians’ syndic, zone TC39

HARD REALTIME

> system-centric

> cybernetics & control systems

> trading & arbitrage

> fixed time budgets

SOFT REALTIME

> person-centric

> chat, commerce & social media

> games

> must be “fast”

REALTIME

CONCURRENCY ASYNCHRONY DISTRIBUTION

CONCURRENCY ASYNCHRONY DISTRIBUTION

CONCURRENCY

ASYNCHRONY

DISTRIBUTION

ASYNCHRONY

ASYNCHRONYtime space

VERTICAL

> lockstep> control flow is imposed> independent> PUSH

HORIZONTAL

> fire and forget> control flow is emergent> interdependent> PULL

> browsers & mobile are increasingly peers rather than clients

> the horizontal model maps well to peer-to-peer architectures

> the network becomes an event bus connecting agents, rather than a pipe pushing data

p2p

but

HORIZONTAL

“this happened and then this happened and then this happened and then this happened”

synchronous story

asynchronous story

“This happened. That happened. This other thing happened. You tell me what it all means.”

> self-contained (or isolated)

> each piece self-contained

> or only knows what’s next

asynchronous data

the difference

> in one, the structure of computation determines the sequence of events

> in the other, that structure is relaxed or absent, and the underlying structure is simpler

example: promises

> promises abstract over not just time but space

> each step processes 1 thing & returns 1 thing

> can be composed, which reintroduces dependencies

> most frequently a simple pipeline

async ⊃ sync

> async is more general than sync

> async data have fewer dependencies

> sync data fits in an async frame, but not vice versa

> callbacks & observables are simple and composable

> callbacks & observables are confusing and hard to reason about

simpler != easier

so

> the results can be simpler, more efficient distributed systems

> but, designers & developers of async systems have more work to do

> and to use it effectively you must change your frame of reference

how

> basic principles of software engineering:

> loose coupling

> stratification

> smallest useful units of modularity

why

> smaller, more composable designs

> does less computation because you’ve done more work up front

> matching the native model of the realtime web

top related