A general overview of Reactive programming, including the history of Reactive application development and why this paradigm is the right fit for developing modern software. Explores examples from JavaScript, Scala, Erlang, and Akka.
5. Expectations in the year 2000
5
• Limited connectivity
• Snapshots of data on hard drives,
centralized databases, etc
6. Expectations in the year 2000
6
• Limited connectivity
• Snapshots of data on hard drives,
centralized databases, etc
• Response times in seconds
7. Expectations in the year 2000
7
• Limited connectivity
• Snapshots of data on hard drives,
centralized databases, etc
• Response times in seconds
• Downtime all the time
8. Hardware in the year 2000
8
• A single machine with a single core
9. Hardware in the year 2000
9
• A single machine with a single core
• Limited networking — e.g, a mix of broadband, dialup internet, FidoNet
10. Hardware in the year 2000
10
• A single machine with a single core
• Limited networking — e.g, a mix of broadband, dialup internet, FidoNet
• Expensive memory, CPU, hard drives
11. Hardware in the year 2000
11
• A single machine with a single core
• Limited networking — e.g, a mix of broadband, dialup internet, FidoNet
• Expensive memory, CPU, hard drives
• Small data
12. “In 1999, one of the busiest FTP sites, cdrom.com, handled 10,000 clients
simultaneously through a Gigabit Ethernet pipe.”
–Dan Kegel: The C10k Problem, 1999
16. Expectations in the year 2014
16
• Limited connectivity ⇨ always connected
• Snapshots of small data ⇨ real-time streams, distributed big data
17. Expectations in the year 2014
17
• Limited connectivity ⇨ always connected
• Snapshots of small data ⇨ real-time streams, distributed big data
• Response times in seconds ⇨ response times in milli/microseconds
18. Expectations in the year 2014
18
• Limited connectivity ⇨ always connected
• Snapshots of small data ⇨ real-time streams, distributed big data
• Response times in seconds ⇨ response times in milli/microseconds
• Downtime all the time ⇨ downtime measured in seconds
19. Hardware in the year 2014
19
• A single machine ⇨ clusters of machines
20. Hardware in the year 2014
20
• A single machine ⇨ clusters of machines
• A single core ⇨ multiple cores
21. Hardware in the year 2014
21
• A single machine ⇨ clusters of machines
• A single core ⇨ multiple cores
• Slow networks ⇨ fast networks
22. Hardware in the year 2014
22
• A single machine ⇨ clusters of machines
• A single core ⇨ multiple cores
• Slow networks ⇨ fast networks
• Small data snapshots ⇨ big data streams
23. “If one node can only serve 10,000 clients, the venture is cost-prohibitive
from the start – just one million devices would require a fleet of 100
servers.”
–Scott Andreas, Urban Airship
24. In 2010, Urban Airship used Java NIO to successfully test 512,000+
concurrent connections on a single 2.5 GB EC2 instance.
25. Realities of modern software development
25
• Applications are distributed by default
26. Realities of modern software development
26
• Applications are distributed by default
• Applications are composed from other applications
27. Realities of modern software development
27
• Applications are distributed by default
• Applications are composed from other applications
• Performance expectations — a slow application is a dead application
28. Realities of modern software development
28
• Applications are distributed by default
• Applications are composed from other applications
• Performance expectations — a slow application is a dead application
• UIs must adapt to multiple screen sizes and types of input
29. Realities of modern software development
29
• Applications are distributed by default
• Applications are composed from other applications
• Performance expectations — a slow application is a dead application
• UIs must adapt to multiple screen sizes and types of input
• Developers can no longer avoid parallelism and concurrency
32. “MigratoryData scales up to 12 million concurrent users from a single
Dell PowerEdge R610 server while pushing up to 1.015 Gbps live data
(each user receives a 512-byte message every minute).”
–Mihai Rotaru, 2013, discussing MigratoryData WebSocket server
35. “Instead of the latest framework of the day or the latest buzzword,
reactive brings the talk back to core principles; the design, the
architecture, the way we think about building software.”
–Jonas Bonér
36. Core principles of reactive software
36
• React to events ⇨ Event-driven
• React to load ⇨ Scalable
• React to failure ⇨ Resilient
• React to users ⇨ Responsive
• Reactive ⇨ Event-driven, Scalable, Resilient, Responsive
38. re·spon·sive
!
“Reacting quickly and positively.”
!
synonyms: quick to react to, reactive to, receptive to, open to suggestions
about, amenable to, flexible to, sensitive to, sympathetic to
39. Responsive — flexibility
39
Progressive UI enhancement
• Never allow slow external dependencies to degrade the user experience
Blue skies
• Never assume blue skies, assume grey skies
40. Responsive — quick to react
40
Beware of blocking IO!
• Asynchronous — non-blocking, blocking
• Synchronous — non-blocking, blocking
• Do you know what type your web framework implements?
Perceived quality
• Perception of responsiveness is key, feel counts!
• Never, ever perform blocking IO on the UI thread!
41. Responsiveness
!
Being quick to react to all users of a system — under blue skies and grey
skies — in order to ensure a consistent experience.
42. scal·able
!
“Capable of being easily expanded or upgraded on demand.”
!
synonyms: ascendable, climbable, extensible, expandable, expansible,
adaptable, elastic, flexible
43. Scalable
43
Important terms
• Performance — a measure of your response time
• Load — impacts performance if not handled properly
Dealing with load
• Scale up — faster CPU, more memory, bigger hard drive
• Scale out — distribute work across nodes and clusters
44. Scalability
!
The capability of your system to be easily upgraded on demand in order
to ensure responsiveness under various load conditions.
45. re·sil·ient
!
“Able to withstand or recover quickly from difficult conditions.”
!
synonyms: strong, tough, hardy
46. Resilient
46
Bulkheads
• Partitioning — partition thread groups for different functionality
Backpressure
• Throttling — wait for a consumer to demand more work
Circuit Breakers
• Stability — Failing external dependencies shouldn’t bring down an entire app
47. Resiliency
!
The proper application of fundamental design and architecture principles
to ensure responsiveness under grey skies.
48. e·vent
!
“Something that happens or is regarded as happening; an occurrence,
especially one of some importance.”
!
driv·en
!
“Propelled or motivated by something.”
49. Traditional concurrency models
49
Thread based concurrency with objects and shared state
• Imperative, sequential execution
• Most common programming paradigm
• Threads for concurrency
• Difficult to reason about, error-prone
• Implementations — most OO based web frameworks, languages, and toolkits
50. Traditional concurrency models
50
Software transactional memory (STM)
• Immutable values
• Atomicity, consistency, isolation and durability
• Cannot perform any operation that cannot be undone, including (most) I/O
• Think command pattern/interface
• Implementations — Haskell STM (native), libs for Scala, Java, OCaml, Clojure, etc
51. Share nothing concurrency
51
Event driven concurrency
• Thread based event loops
• Often single threaded
• Implementations — Node.js, Twisted Python, EventMachine (Ruby)
52. Share nothing concurrency
52
Actor based concurrency
• Mutable state, but completely isolated
• State only mutated by the actor
• Asynchronous message passing between actors using mailboxes
• Thread based actors or event based actors
• Implementations — Erlang, Akka
53. Event driven
!
An event driven architecture forces programmers to deal with scalability
and resilience at a code level in order to facilitate responsiveness.
57. A programmer had a problem. They thought to themselves, "I know, I'll
solve it with threads". have Now problems two they.
–@davidlohr
58. Non-deterministic — mutable state, threads, locks
58
var a = foo.getB() + bar.getC()!
System.out.println(a) // “42”!
a = foo.getB() + bar.getC()!
System.out.println(a) // Who knows?
59. Non-deterministic — mutable state, threads, locks
59
var a = foo.getB() + bar.getC()!
System.out.println(a) // “42”!
a = foo.getB() + bar.getC()!
System.out.println(a) // Who knows?!
!
• The value of a may or may not still be 42
• Is another thread is mutating foo or bar?
• Pull-based — getB() and getC() must be explicitly invoked
• Later mutation to foo and bar doesn’t effect a
• Based on time and space
60. Why is non-determinism the root of all evil?
60
Key terms
• Parallelism — when at least two threads are executing simultaneously
• Concurrency — when at least two threads are making progress
Mutable state + threads + locks
• Code that is error prone and difficult to reason about
• Extremely difficult to implement parallelism and concurrency with MuSTL
61. Akka is a toolkit and runtime for building highly concurrent, distributed,
and fault tolerant event-driven applications on the JVM.
62. A simple Akka code example
62
class GameActor extends Actor {!
def receive = {!
case handshakeRequest: HandshakeRequest => !
sender ! computeHandshakeResponse(handshakeRequest)!
case turnMessage: TurnMessage => !
sender ! computeTurnResponse(turnMessage) !
}!
}!
!
• Time, space, mutation ⇨ flow, events, messages
63. Akka Actors
63
• Process messages asynchronously
• Pattern match against message types
• Focus on flow and values — not objects, threads, and locks
• Higher-level of abstraction — easier to write concurrent, distributed systems
• Think observable/observer and pub/sub
• Influenced by the Erlang actor model
65. Erlang characteristics and use cases
65
• Share nothing architecture — processes cannot share data
• Pure message passing — copy all the data you need in the messages
• Crash detection and recovery — things will crash, so let them crash then recover
66. Erlang characteristics and use cases
66
Popular Erlang Software
• Wings 3D — 3D modelling
• Ejabberd — instant messaging server
• CouchDB — document database
• RabbitMQ — enterprise-y messaging
Erlang in Production
• Ericsson — 3G mobile networks
• Amazon — SimpleDB, EC2
• Facebook — back-end chat server
• T-Mobile — SMS and authentication
67. “Reactive looks back in history. It doesn't ignore the goldmine of
knowledge that's been around for 30 to 40 years, but rather tries to bring
it into new context.”
–Jonas Bonér
68. Sources and credits
68
• Jonas Bonér — Reactive Supply to Changing Demand
• Joe Armstrong — K things I know about building Resilient Reactive Systems
• Benjamin Erb — Concurrent Programming for Scalable Web Architectures
• Rich Hickey — The Value of Values
• Plus various talks, papers, books, blog posts, and tweets by…
• Dean Wampler, Erik Meijer, Martin Odersky, Martin Thompson, etc