Thinking asynchronously
Sherwood 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
ASYNCHRONY

CONCURRENCY

DISTRIBUTION
ASYNCHRONY
time

ASYNCHRONY

space
V
E
R
T
I
C
A
L
>
>
>
>

lockstep
control flow is imposed
independent
PUSH
HORIZONTAL

>
>
>
>

fire and forget
control flow is emergent
interdependent
PULL
p2p
> browsers & mobile are increasingly peers rather
than clients
> the horizontal model maps well to peer-to-peer
archit...
but
HORIZONTAL
synchronous story

“this happened and then this happened and then this
happened and then this happened”
asynchronous story

“This happened. That happened. This other thing
happened. You tell me what it all means.”
asynchronous data
> self-contained (or isolated)
> each piece self-contained
> or only knows what’s next
the difference
> in one, the structure of computation determines
the sequence of events
> in the other, that structure is ...
example: promises
> promises abstract over not just time but space
> each step processes 1 thing & returns 1 thing
> can b...
async ⊃ sync
> async is more general than sync
> async data have fewer dependencies
> sync data fits in an async frame, bu...
simpler != easier
> callbacks & observables are simple and composable
> callbacks & observables are confusing and hard to
...
so
> the results can be simpler, more efficient
distributed systems
> but, designers & developers of async systems have
mo...
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 nativ...
Thinking asynchronously: events on the realtime web
Thinking asynchronously: events on the realtime web
Thinking asynchronously: events on the realtime web
Thinking asynchronously: events on the realtime web
Upcoming SlideShare
Loading in...5
×

Thinking asynchronously: events on the realtime web

391

Published on

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.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
391
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • “traditional” realtime
    the risks: hardware destroyed, life risks
    consistent time & memory costs – inflexible, absolute
  • the realtime web
    the risks: engagement and stickiness lost (lower stakes)
    asynchronous and session-based
  • we commonly conflate all these things together when talking about realtime, but they deserve independent consideration
  • transactions vs sessions, request/responses vs streams of events
  • transactions vs sessions, request/responses vs streams of events
  • transactions vs sessions, request/responses vs streams of events
  • transactions vs sessions, request/responses vs streams of events
  • transactions vs sessions, request/responses vs streams of events
  • transactions vs sessions, request/responses vs streams of events
  • transactions vs sessions, request/responses vs streams of events
    without additional annotation, asynchronous events are just data points in time
  • this is simpler but comes with less context
  • fundamentally reactive
  • in fact, one of the most popular asynchronous control-flow tools, promises, were designed explicitly to accommodate the idea that the result of an action may be realized somewhere else
    in p2p architectures, events are decoupled across time and space – they’re asynchronous
  • “more general” also means “simpler”
    the key insight here is that this relaxation of dependencies as we move into the asynchronous world strongly suggests that asynchronous modeling is more general than synchronous
  • sometimes we can see what’s going on from the code but can’t figure out what’s going on by looking at what’s happening in the system
  • an asynchronous model is a synchronous model with many of its restrictions removed.
    this shifts a lot of the hard work off of languages and runtimes and onto designers, developers and operational engineers, but it can result in simpler and cheaper distributed systems
  • this is more about analysis than software design – complex systems hide the flow o
  • Thinking asynchronously: events on the realtime web

    1. 1. Thinking asynchronously Sherwood McGraw des. rep. Peer Anarchy, es262 librarians’ syndic, zone TC39
    2. 2. HARD REALTIME > system-centric > cybernetics & control systems > trading & arbitrage > fixed time budgets
    3. 3. SOFT REALTIME > person-centric > chat, commerce & social media > games > must be “fast”
    4. 4. REALTIME CONCURRENCY ASYNCHRONY DISTRIBUTION
    5. 5. CONCURRENCY ASYNCHRONY DISTRIBUTION
    6. 6. ASYNCHRONY CONCURRENCY DISTRIBUTION
    7. 7. ASYNCHRONY
    8. 8. time ASYNCHRONY space
    9. 9. V E R T I C A L > > > > lockstep control flow is imposed independent PUSH
    10. 10. HORIZONTAL > > > > fire and forget control flow is emergent interdependent PULL
    11. 11. p2p > 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
    12. 12. but
    13. 13. HORIZONTAL
    14. 14. synchronous story “this happened and then this happened and then this happened and then this happened”
    15. 15. asynchronous story “This happened. That happened. This other thing happened. You tell me what it all means.”
    16. 16. asynchronous data > self-contained (or isolated) > each piece self-contained > or only knows what’s next
    17. 17. 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
    18. 18. 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
    19. 19. async ⊃ sync > async is more general than sync > async data have fewer dependencies > sync data fits in an async frame, but not vice versa
    20. 20. simpler != easier > callbacks & observables are simple and composable > callbacks & observables are confusing and hard to reason about
    21. 21. 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
    22. 22. how > basic principles of software engineering: > loose coupling > stratification > smallest useful units of modularity
    23. 23. why > smaller, more composable designs > does less computation because you’ve done more work up front > matching the native model of the realtime web
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×