My presentation of reactive software adoption in Atieh Dadeh Pardaz

1. Reactive Software Systems
Behrad Zari
b.zari@adpdigital.com
Fall 2014

2. Today Software
● Cluster of multi-core machines
● Fast networks
● Lots of concurrent users
● Large data sets
● Latency in milliseconds

3. Our Needs
● Cope to Enterprise Software Complexity
● Scalability / Performance

4. Reactive Manifesto
Responsive
Resilient
Message Driven
Elastic
http://www.reactivemanifesto.org/

5. Code Complexity

6. Complexity
● Programming paradigms
– Imperative → OOP, Statements, …
– Functional → HOF, Immutability, Expressions,...

7. Programming Paradigms
● Imperative: how to solve
– procedural, object-oriented, statements
● Declarative: what to solve
– functional, immutability, expressions

8. Imperative
● Sequence of statements
● Contents of memory as state
● Statements update variables (mutation)
● Assignment, control structures

9. Example

10. OOP
● Encapsulation
● Inheritance
– Reuse → Composition
– Extension
● Polymorphism
– Ad-hoc
– Parametric
– Dynamic

11. Functional
● Based on Lambda calculus
● Functions form programs
● Same input → same output
● Avoids mutation
● Higher order functions

12. Example

13. Side Effects
● Global Variables

14. Side Effects
● Function State, Object State

15. Side Effects Matter
● Harder to reason about program
● Harder to test
● Harder to extend, parallelize, …
How to avoid them?

16. Statements vs Expressions
→

17. Functions as 1st-class Members
Functions as values

18. Lambda Expressions
● block of code with parameters executed later

19. Clojures

20. Immutability

21. Statelessness
● should perform every task as if for the first time
– ignorant of the past

22. Thinking in Functions
● All of your functions must accept at least one
argument
● All of your functions must return data or another
function
● No loops!

23. Multi paradigm Implementations
● Imperative with functional features
– Java, C#, Python, Ruby
● Functional with OO features
– Scala
– Ocaml, f#
What makes difference?
– Higher order functions
– Immutable data structures
– Recommended functional style idioms

24. Scala :D

25. wwwwwwwww...tttoooppptttaaalll...cccooommm
www.toptal.com

26. Why Scala
● Nice functional support
– Basically functional + immutable data structures + ...
● Type inference system
– Less program code, more type checks
● Designed for scalability
● Stick with JVM echo system

27. Scala Features
● Lambda expressions, closures and currying
naturally
● Pattern matching
● Multiple inheritance through Traits
● Comprehensive collections library

28. Collections

29. Immutability
● Variables
– val VS var
● Collections
● Value objects (case classes)

30. Case classes

31. Pattern Matching

32. Functional Programing Issues
● Input/output difficult to deal with
– Monadic operations
● Requires garbage collection
● Sometimes slower (but usually not by much)
● Stateful operations are cumbersome

33. Learn more
● http://www.scala-lang.org/old/node/8610

34. Concurrency Models

35. Thread based Model
● Shared mutable state
● Threads concurrently execute code sections
– Synchronization
– Locking mechanism
– Not scalable
– Edward A. Lee, The Problem with Threads

36. Always Blocking
● Latency
– CPU → 1ns (=> 1 second)
– RAM → 250,000ns (=> 3 days)
– TCP →150,000,000ns (=> 5 years)

37. Non blocking Code

38. Future

39. Future

40. Futures in Scala

41. Event Loop Model
● Implemented in Node.js

42. Message Passing Model
● 1973, paper by Carl Hewitt
● Avoid the problems caused by threading and
locking
● Implemented in Erlang, Scala

43. Actor Model
● Actors instead of objects
● No shared state between actors
● Asynchronous message-passing
– Immutable messages
● Mailboxes

44. Actor Benefits
● Higher abstraction level
– Easier to reason about
● Easier to avoid
– Race conditions
– Deadlocks
– Starvation
– Live locks
● Distributed computing

45. Example in Erlang

46. Erlang Actors in Real
● Ericson AXD 301 switch
– millions of calls per ,99.9999999 percent uptime
● Facebook chat application
– 70 million concurrent users
● RabbitMQ
– high-performance AMQP, 400,000 messages per second.
● Apache CouchDB
– distributed, fault-tolerant document-oriented database
● Ejabberd XMPP server – jabber.org

47. JVM implementations
● Java
– Kilim, Jetlang, ActorFoundry, Actors Guild
● Scala (FP + actor model)
– Akka
● Groovy
– GParallelizer

48. Akka :x

49. Akka
● Concurrency
– mailboxes
– dispatchers
● Scalability
– Remote actors, clustering
● Fault tolerance
– Actor supervision

50. Akka Actors
● Define messages
● Create new actors
● Send messages to others
– Fire & forget
– Send & receive eventually
– Send & receive with future
● Become
● Supervise

51. Akka Actor in Java

52. Akka actor in Scala

53. Talk to Actors

54. Actor Hierarchies
● Name resolution: file system like

55. Supervision & Resilience
● OneForOneStrategy VS AllForOneStrategy
● Monitor through Death Watch
● Every single actor has a default supervisor
strategy. Which is usually sufficient. But it can
be overridden

56. Scalability & Elasticity
● Scale Up VS Scale Out
– Essentially are same thing
● Minimize Contention
● Maximize Locality of Reference
– Share Nothing Design

57. Akka Routers
● RoundRobinRoutingLogic
● RandomRoutingLogic
● SmallestMailboxRoutingLogic
● BroadcastRoutingLogic
● ScatterGatherFirstCompleted
● TailChoppingRoutingLogic
● ConsistentHashingRoutingLogic

58. Akka Clustering

59. Simple Bulk Aggregator

60. Better Bulk Aggregator

61. Akka Adoption

62. .End()
bacheHa thank { qList =>
qList forEach (_.answer)
}