Thinking asynchronously: events on the realtime web

598 views
478 views

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
598
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
5
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

    ×