reactive software systems

Reactive Software Systems

Behrad Zarib.zari@adpdigital.com

Fall 2014

Today Software

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

Our Needs

● Cope to Enterprise Software Complexity

● Scalability / Performance

Reactive Manifesto

Responsive

Resilient

Message Driven

Elastic

http://www.reactivemanifesto.org/

Code Complexity

Complexity

● Programming paradigms

– Imperative → OOP, Statements, …

– Functional → HOF, Immutability, Expressions,...

Programming Paradigms

● Imperative: how to solve– procedural, object-oriented, statements

● Declarative: what to solve– functional, immutability, expressions

Imperative

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

Example

OOP

● Encapsulation

● Inheritance– Reuse → Composition

– Extension

● Polymorphism– Ad-hoc

– Parametric

– Dynamic

Functional

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

Example

Side Effects

● Global Variables

Side Effects

● Function State, Object State

Side Effects Matter

● Harder to reason about program● Harder to test● Harder to extend, parallelize, …

How to avoid them?

Statements vs Expressions

→

Functions as 1st-class Members

Functions as values

Lambda Expressions

● block of code with parameters executed later

Clojures

Immutability

Statelessness

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

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!

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

Scala :D

www.toptal.com

www.toptal.comwww.toptal.comwww.toptal.com

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

Scala Features

● Lambda expressions, closures and currying naturally

● Pattern matching

● Multiple inheritance through Traits

● Comprehensive collections library

Collections

Immutability

● Variables– val VS var

● Collections

● Value objects (case classes)

Case classes

Pattern Matching

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

Learn more

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

Concurrency Models

Thread based Model

● Shared mutable state● Threads concurrently execute code sections

– Synchronization

– Locking mechanism– Not scalable

– Edward A. Lee, The Problem with Threads

Always Blocking

● Latency– CPU → 1ns (=> 1 second)

– RAM → 250,000ns (=> 3 days)

– TCP →150,000,000ns (=> 5 years)

Non blocking Code

Future

Future

Futures in Scala

Event Loop Model

● Implemented in Node.js

Message Passing Model

● 1973, paper by Carl Hewitt● Avoid the problems caused by threading and

locking ● Implemented in Erlang, Scala

Actor Model

● Actors instead of objects

● No shared state between actors

● Asynchronous message-passing

– Immutable messages

● Mailboxes

Actor Benefits

● Higher abstraction level– Easier to reason about

● Easier to avoid– Race conditions– Deadlocks– Starvation– Live locks

● Distributed computing

Example in Erlang

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

JVM implementations

● Java– Kilim, Jetlang, ActorFoundry, Actors Guild

● Scala (FP + actor model)– Akka

● Groovy– GParallelizer

Akka :x

Akka

● Concurrency– mailboxes

– dispatchers

● Scalability– Remote actors, clustering

● Fault tolerance– Actor supervision

Akka Actors

● Define messages● Create new actors● Send messages to others

– Fire & forget

– Send & receive eventually

– Send & receive with future

● Become● Supervise

Akka Actor in Java

Akka actor in Scala

Talk to Actors

Actor Hierarchies

● Name resolution: file system like

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

Scalability & Elasticity

● Scale Up VS Scale Out– Essentially are same thing

● Minimize Contention● Maximize Locality of Reference

– Share Nothing Design

Akka Routers

● RoundRobinRoutingLogic

● RandomRoutingLogic

● SmallestMailboxRoutingLogic

● BroadcastRoutingLogic

● ScatterGatherFirstCompleted

● TailChoppingRoutingLogic

● ConsistentHashingRoutingLogic

Akka Clustering

Simple Bulk Aggregator

Better Bulk Aggregator

Akka Adoption

.End()

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