slides of the talk I did at QCon New York 2015

1. becoming reactive.
without overreacting

3. boundary

4. primary:
this is an architectural talk
that describes the reactive
approach

5. secondary:
responsiveness is a
behavioural, UI/UX specific
requirement

6. secondary:
resilience is an
operational requirement

7. secondary:
event-orientation is a
transport detail

8. secondary:
async is an
invocation detail

9. secondary:
scalability is a
business requirement

10. prelude

11. form follows function

12. function follows
requirement

13. requirement follows idea

14. idea follows demand

15. demand, idea, function
are given.
what is form?

16. placement

17. cooperation between
components through
minimal contracts and
expectations

18. addition to “classic”
approaches to building
enterprise level systems

19. layering,
separation of duties,
loose coupling,
modularisation,
domain logic etc.
don’t change

20. invocation,
behaviour in the
presence of failures
eventually change

21. claim

22. becoming reactive
means moving
from implicit to explicit
reactiveness

23. argumentation

24. data expected to be received
on input, processed and
delivered on output
<=>
context is reactive

25. every UNIX pipeline is a
reactive context

26. every function call in a
program is embedded into a
reactive context

27. logic is lazy
until being called
<=>
context is reactive

28. every application runtime
platform is
a reactive context

29. there is always some sort
of threading, actors,
message passing,
schedulers, executors,
callbacks etc. around
custom code

30. the OS kernel is
a reactive context

31. there is always some sort
of event loop, push,
callbacks, switching etc.
around custom code

32. von Neumann computers
are reactive systems

33. there is always some sort
of processor, pipelines,
instructions, interrupts,
message passing etc.
around custom code

34. conclusion

35. every not explicitly
or obviously
reactive system is
reactive under the hood

36. thus, becoming reactive
means moving
from implicit to explicit
reactiveness

37. benefit

38. responsiveness to change
add, remove, replace
functionality on demand,
keeping the
small core stable

39. resource efficiency
stay lazy until
there is work to do

40. fight or flight
react adequately to
changes of behaviour

41. use case

42. network server
foundations

43. (web) service
foundations

44. stream processing

45. every application
frequently accessed
by real users
or machines

46. challenge

47. largest challenge is to
overcome temptation
to go full reactive

48. example strategy:
notification of change,
with explicit data
querying as reaction

49. second largest
challenge is to
overcome temptation
to go partial reactive

50. example strategy:
CRUD if user number
is steady and database
load is predictable

51. third largest
challenge is to
overcome temptation
to write an own
reactive framework

52. example strategy:
Rx will work just fine
in 99.99% of all cases.
Akka family or Reactor
when among the
lucky 0.01%

53. much higher
implementation
complexity

54. example strategy:
don’t trust advertisement -
complexity will not go away
just because it’s ignored

55. example strategy:
in most cases,
Rx’s observables
will be sufficient

56. example strategy:
don’t necessarily blow
bits directly, try
implicit store
and forward first

57. example strategy:
learn concepts from
(functional) reactive
programming, think of
signalling and value
manifestation

58. orchestration and flow

59. example strategy:
build on streams and
their topologies to
bring explicitness
into reactiveness

60. example strategy:
embrace functional
programming for it’s
laziness, composition,
side-effect freedom etc.

61. error handling

62. example strategy:
let-it-crash and
bring-it-back

63. example strategy:
don’t bind, instead parse
and compensate,
ignore or alert

64. debugging

65. example strategy:
program to quickly switch
from non-deterministic
to deterministic
(from async to sync)

66. example strategy:
always look for an
erroneous condition in
your own code first

67. example strategy:
avoid later debugging
through early
randomised simulation

68. testing

69. example strategy:
test non-determinism
with property tests

70. monitoring

71. example strategy:
switch from
eyeball intelligence
to probabilistic,
analytical intelligence

72. automation

73. example strategy:
make implicit order
of presence explicit
through dependencies,
expectations, listeners

74. “legacy”

75. ideas from
networking
applicable:
slow start,
back-off,
back-pressure,
correlation

76. ideas from
distributed systems
applicable:
consensus,
voting,
leader election,
quorum

77. ideas from
SOA/BPM
applicable:
orchestration,
composition,
long-running transactions,
compensation,
parallel versions

78. ideas from
batch processing
applicable:
fork/join,
work queue,
rerun-on-failure,
map/reduce

79. try it rather earlier
than later, but keep
your eyes open

80. thank you