Reactive Programming

Presentation held at the Parallel Conference in Karlsruhe, Germany, on May 6, 2014. Apart from the slides, the presentation featured a demo of RxJava, highlighting its strengths and some of its current limitations.

Transcript

1. codecentric AG Patrick Peschlow Reactive Programming
2. codecentric AG The Challenge Users
3. codecentric AG The Challenge Users don’t like to wait
4. codecentric AG The Challenge Users don’t wait
5. codecentric AG The Challenge Many users don’t wait
6. codecentric AG The Challenge Many many users don’t wait
7. codecentric AG The Challenge Today’s applications don’t cope
8. codecentric AG So we need a Manifesto
9. codecentric AG Reactive Traits From: http://www.reactivemanifesto.org
10. codecentric AG Event-driven Trait − Asynchronous − Synchronous APIs tightly couple client and service (often block) − Asynchronous means the client can decide if and where to block ! − Non-blocking − Blocking APIs may require large numbers of threads (often coupled to users) − Wastes CPU resources (context switches, scheduling) − Non-blocking frees threads to do new work − Define worker thread pools based on resources ! − Share nothing ! − Loose coupling Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
11. codecentric AG Example Time Scale of System Latencies From: Brendan Gregg. „Systems Performance: Enterprise and the Cloud“. Prentice Hall, 2013
12. codecentric AG Futures and Promises − Future: A reference to an asynchronously computed value ! − Promise: A future with additional features − May be completed in various ways (e.g., by a setter) − Enables composition (one promise completes another) ! − (Functional) Reactive Programming − Futures and promises taking to the extreme
13. codecentric AG Futures and Promises Demo
14. codecentric AG RxJava Reactive Extensions for the JVM — A library for composing
 asynchronous and event-based programs using observable sequences for the Java VM From: http://github.com/Netflix/RxJava
15. codecentric AG Observable single items multiple items synchronous T  getData() Iterable<T>  getData() asynchronous Future<T>  getData() Observable<T>  getData() From: http://github.com/Netflix/RxJava/wiki
16. codecentric AG Observable From: http://github.com/Netflix/RxJava/wiki Iterable (pull) Observable (push) T  next() onNext(T) throws Exception onError(Exception) returns onCompleted()
17. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
18. codecentric AG RxJava Demo
19. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
20. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
21. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
22. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
23. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
24. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
25. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
26. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
27. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
28. codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html
29. codecentric AG Benefits of Observables − Life cycle of client and service are decoupled ! − Service API keeps control over its implementation ! − Client decides how its subscription should behave (e.g., timeouts) ! − Note: The „client“ may be another service having its own clients − Not necessarily a human or a browser
30. codecentric AG Back Pressure − An eager producer can overflow its consumer(s) − Due to inversion of control when going from sync to async ! − Consumers need a mechanism for „back pressure“ − Tell the producer how much data you can handle − Similar to, e.g., receiver window in TCP From: http://www.reactive-streams.org
31. codecentric AG So are we Reactive yet? From: http://www.reactivemanifesto.org
32. codecentric AG Responsive Trait − Goal: Achieve bounded latency ! − Parallelize tasks within services ! − Choose algorithms with small variance in execution time − Predictable execution time for some target percentile ! − Use explicit and bounded queues ! − Use circuit breakers that monitor target metrics and react on violation − fail-fast and reject, return partial results, or delegate to another service − e.g., for input queues, reject requests when the queue is full Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
33. codecentric AG Resilient Trait − Goal: Service stays available even in the presence of unexpected failures − software, hardware, human ! − Distribute the system ! − Use bulkheading ! ! ! ! − Let supervisors handle failure − separate failure handling from the actual business logic of the service Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview. From: http://www.reactivemanifesto.org
34. codecentric AG Scalable Trait − Goal: Scale up (and down) based on load ! − Distribute requests to various instances of the services ! − The more stateless services, the better ! − Measure load at run time and react accordingly − But: No reason to forego capacity planning Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
35. codecentric AG What about Actors? − Seem to fulfill the reactive traits much better than reactive programming does − Asynchronous, non-blocking, and event-driven by definition − Supervisors and „let it crash“ − Distributed − Easily scalable ! − But maybe too „heavyweight“ for some problems within services − Often, stateless actors don’t suffice or get highly complex ! − Promising approach: Combine actors and reactive programming − Actors for the backbone and cluster „infrastructure“ − Reactive Programming inside the nodes
36. codecentric AG Conclusion − Clear need for reactive applications ! − Well addressed by the actor model and reactive programming approaches ! − Building reactive applications requires different thinking ! − Helped by various reactive frameworks, in particular on the JVM ! − Brings up the topic of essential complexity vs. incidental complexity
37. codecentric AG Frameworks − Reactive Extensions (Rx)
 http://rx.codeplex.com ! − RxJava
 http://github.com/Netflix/RxJava ! − Akka
 http://akka.io ! − Vert.x
 http://vertx.io ! − Reactor
 https://github.com/reactor/reactor
38. codecentric AG Resources − Reactive Manifesto
 http://www.reactivemanifesto.org ! − Reactive Streams
 http://www.reactive-streams.org ! − Conference „React 2014“
 http://reactconf.com
 http://www.youtube.com/user/reactconf ! − Online course on Reactive Programming
 http://www.coursera.org/course/reactive ! − Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Currently in writing. ! − Michael Nygard. „Release It!“. Pragmatic Bookshelf. 2007.
39. codecentric AG Questions? Dr. rer. nat. Patrick Peschlow
 codecentric AG
 Merscheider Straße 1
 42699 Solingen
 
 tel +49 (0) 212.23 36 28 54
 fax +49 (0) 212.23 36 28 79
 patrick.peschlow@codecentric.de
 
 www.codecentric.de
40. codecentric AG Bonus: What does this mean for my (Big) Data? − If reactive applications focus so much on availability, what about consistency − CAP suggests you need to choose between C and A ! − But: Even with CAP you can have C and A most of the time − You just need to have a reliable strategy for detecting and handling partitions − http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed ! − Note: There is also a „Reactive Programming“ in the context of databases − http://www.espressologic.com/reactive-programming-database-logic/ − Don’t confuse it with the „Functional Reactive Programming“ we have seen