TAKE A LOOK AT AKKA + JAVA

Dmytro Mantula GlobalLogic, Kyiv

PREVIOUS AGE OF COMPUTING SYSTEMS

• Monolith software architecture

• Managed servers and containers

• RDBMS, transactions isolation

• Scalability: scale-up by more powerful hardware

• Proprietary enterprise solutions

NEW CHALLENGES

• response time: s -> ms

• high availability: 3 nines (8h/y) -> 5+ nines (5– m/y)

• storage: GBs (109) -> PBs (1015)+

• hardware: spread from mobile phone to 1000+ nodes cluster

MOORE’S LAW

EVIL OF CPU PERFORMANCE:

MOORE’S LAW DOESN’T WORK

ANYMORE FOR A SINGLE CORE

The more CPU cores a system has,

the faster it is.

True or false?

EVIL OF PARALLELISM:

AMDAHL’S LAW

Gene Amdahl 1967

STUBBORN AMDAHL’S LAW

The speedup of a program using multiple processors in parallel computing

is limited by the sequential fraction of the program.

EVIL OF CONCURRENCY:

SHARED MUTABLE STATE

«Do not communicate by sharing memory.

Instead, share memory by communicating»

– Effective Go

v1.0: July 2013 v2.0: Sept 2014

REACTIVE SOFTWARE DESIGNhttp://www.reactivemanifesto.org/

• rapid and consistent response times • response in SLA time may be more

important than late correct response • problems may be detected quickly

and dealt with effectively

react to usersResponsive

v1.0: July 2013 v2.0: Sept 2014

REACTIVE SOFTWARE DESIGNhttp://www.reactivemanifesto.org/

react to loadElastic

• No contention points or central bottlenecks • ability to shard or replicate components

and distribute inputs among them

• Automatic resource management • scale-up • scale-out • scale-down • scale-in

v1.0: July 2013 v2.0: Sept 2014

REACTIVE SOFTWARE DESIGNhttp://www.reactivemanifesto.org/

• “Let it crash!”: there is no way to think about every single failure point

• failure is not dealt with as an error • means that some capacity of the

system will be reduced • dealt with as a message

react to failuresResilient

v1.0: July 2013 v2.0: Sept 2014

REACTIVE SOFTWARE DESIGNhttp://www.reactivemanifesto.org/

Asynchronous message-passing • loose coupling • isolation of components • location transparency • failures as messages

Benefits: • load management • elasticity • flow control (monitoring , back-pressure)

react to eventsMessage Driven

Application should be reactive

from top to bottom

v1.0: July 2013 v2.0: Sept 2014

REACTIVE SOFTWARE DESIGNhttp://www.reactivemanifesto.org/

CARL HEWITT, 1973

ACTOR MODEL

• Describes:

• message processing algorithm

• data storage principles

• interaction between modules

• Erlang

• Used in telecommunication systems

• High Availability of 9 “nines”

• Written in Scala • Stable since 2009 • Part of Scala Standard Library since 2013 • Supports Java 8 since 2014

by

ex

WHAT IS AN ACTOR?

Actor is a unit of code with a mailbox

and an internal state that just responds to messages

in a single thread

(br ief ly)

IDLE

TWO STATES OF ACTOR

IDLE

TWO STATES OF ACTOR

MESSAGE PROCESSING

WHAT IS AN ACTOR?

• Similar to object in OOP, but message-driven • Even more isolated than object: no explicit access

exposed (hidden behind ActorRef) • no shared state • location transparent (can live in different JVMs)

• Light-weight: 300B memory footprint (millions per GB) • No threads allocated in idle state • Single-threaded invocation inside, sequential message

processing • Supervises children actors

WHAT CAN ACTOR DO?

• If no messages being processed:

• Nothing

• When message being processed (one at a time):

• make local decisions

• send messages to other actors (incl. sender() and self())

• do other actions with side-effects (IO, logs, DB access)

• change own behavior for next messages

• create more actors (and promise to supervise them)

BENEFITS

• You’re not going to have multiple threads modifying a variable at the same time.

• Forget about:

• Shared state • Threads • Locks, “synchronized” • Concurrent collections • wait/notify/notifyAll

• Describe only business behavior in the code. • Akka and app configuration care about everything else.

MESSAGE CLASS

• Obligatory: purely-immutable

• Desirably: serializable

• Good practice: declared with recipient Actor class

MESSAGE CLASS

• Obligatory: purely-immutable

• Desirably: serializable

• Good practice: declared with recipient Actor class

SCALA:

ACTOR IN JAVA 7

ACTOR IN JAVA 7

Strict @Override

ACTOR IN JAVA 7

Casting boilerplate

Strict @Override

ACTOR IN JAVA 7

Casting boilerplate

Strict @Override

“if” hell

ACTOR IN JAVA 7

Casting boilerplate

Strict @Override

“if” hell

Do not forget!!!

ACTOR IN JAVA 8

Partial function

ACTOR IN JAVA 8

Partial function

Behavior as a constant

ACTOR IN JAVA 8

Partial function

Behavior as a constant

Type inference

within lambda

ACTOR IN JAVA 8

Partial function

Behavior as a constant

Type inference

within lambda

ACTOR IN JAVA 8

Predicate

ACTORSYSTEM AND ENTRY POINT

DONEC QUIS NUNC

SUPERVISION MODEL

ROUTING

• RoundRobin • Random • SmallestMailbox • Broadcast • ScatterGatherFirstCompleted • (Custom)

REMOTE ACTORS

WHERE TO USE AKKA?

• Multi-user concurrency (e.g. gambling systems)

• Rule based systems (like trading systems)

• Data storages with lots of write operations

• Systems with high-uptime requirements (like telecom)

• Processing pipelines

• Streaming data

• Reactive frameworks

DERIVATIVE FRAMEWORKS/TOOLS• For testing actors: Akka TestKit

• Software Transactional Memory: Akka STM

• Finite State Machines: Akka FSM

• Durable mailboxes & other persistence models

• Akka IO, Akka Streams, Akka Cluster

• Akka HTTP (ex. Spray)

• Play Framework

• Akka Camel, Akka Spring

• Activator

RESOURCES

http://akka.io/

http://lightbend.com

http://letitcrash.com

Coursera: Principles of Reactive Programming

THANKS!

Q & A