codecentric AG Patrick Peschlow Reactive Programming 

codecentric AG The Challenge Users 

codecentric AG The Challenge Users don’t like to wait 

codecentric AG The Challenge Users don’t wait 

codecentric AG The Challenge Many users don’t wait 

codecentric AG The Challenge Many many users don’t wait 

codecentric AG The Challenge Today’s applications don’t cope 

codecentric AG So we need a Manifesto 

codecentric AG Reactive Traits From: http://www.reactivemanifesto.org 

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. 

codecentric AG Example Time Scale of System Latencies From: Brendan Gregg. „Systems Performance: Enterprise and the Cloud“. Prentice Hall, 2013 

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 

codecentric AG Futures and Promises Demo 

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 

codecentric AG Observable single items multiple items synchronous T  getData() Iterable  getData() asynchronous Future  getData() Observable  getData() From: http://github.com/Netflix/RxJava/wiki 

codecentric AG Observable From: http://github.com/Netflix/RxJava/wiki Iterable (pull) Observable (push) T  next() onNext(T) throws Exception onError(Exception) returns onCompleted() 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG RxJava Demo 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

codecentric AG Transformations on Observables From: http://netflix.github.io/RxJava/javadoc/rx/Observable.html 

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 

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 

codecentric AG So are we Reactive yet? From: http://www.reactivemanifesto.org 

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. 

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 

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. 

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 

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 

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 

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. 

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
 [email protected]
 
 www.codecentric.de 

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