Two Reactive approaches to scale

Comparing two approaches

for scalable, message-driven, backend applications
in Java

Spring Boot Services and Akka

Lorenzo Nicora Lorenzo.nicora@opencredo.com

1
Reactive is

Reactive
Semantically overloaded term

adj. Readily responsive to stimulus [Merrian-Webster dictionary]

From Latin reagere: act in return

2
Reactive as

Reactive as Responsive
Quickly prompt to user actions

Reactive as Data binding

Declarative, as opposed to Imperative
a=b+3
e.g. Spreadsheets

Reactive streams as Asynchronous Data Streams

Reactive as Reactive Manifesto

Reactive Manifesto

Responsive Low latency

Resilient Stay responsive on failure
Elastic Scale as needed
Message-Driven
Async messages as only communication between components
Reactive Manifesto promotes

No Blocking operation
No Synchronization
No Resource hogging

Decoupling and isolation in

Time Allow concurrency
Space Components location decoupling
Macro and Micro approaches
Top-down approach: from Macro
(at Service boundaries)
o Message based communication between services
o Isolation at service level

Bottom-Up approach: from Micro

(within the service)

o Message based communication between components

o Non-blocking processing
o Isolation at component level
Two real world projects

Akka Spring Boot

Service
Spring Boot Service
Spring Boot Service application
Message-based communication between services
Non-blocking (where possible)
o Java 8 CompletableFutures
o Http non-blocking Servlets
o Fast-returning API endpoints

Event sourcing persistence

o Concursus forerunner

Spring Boot and Spring Cloud Config

Akka Cluster
Java application using Akka, Cluster
Akka Actor programming model

Event-sourcing by Akka Persistence

Akka Cluster

Deployed using ConductR [Commercial]

Akka Http server (no container), non blocking

TypeSafe Config

not Lagom framework

not Akka Streams
 Actor model
Actor
Article by Carl Hewitt (1973)
Erlang (1986) Mailbox Mailbox

Akka framework (2009)

Actor Mailbox

Actor
TL;DR
The actor model in computer science is a mathematical model of
concurrent computation that treats "actors" as the universal primitives of
concurrent computation.
In response to a message that it receives, an actor can: make local
decisions, create more actors, send more messages, and determine how to
respond to the next message received. Actors may modify private state, but
can only affect each other through messages (avoiding the need for any
locks).
[Wikipedia]
Actor model for dummies
A different way to concurrency
Actors, !Threads

Actor is the primary computational entity

o In Java, still a mixed world of Objects and Actors

Actors interact exclusively via asynchronous messages

o As opposed to Objects interacting through method calls
Actor
o Actors REACT on receiving a message
o No synchronisation; no lock Mailbox Mailbox

Actor Mailbox

Actor
Actor model

Actor handles one message a time

o Message handling code is intrinsically thread safe
o May have simple state: Instance properties in Java

Actor is lightweight
o Little overhead over creating an object
o May be used to hold request context
Per-request Actors: a common pattern
Supervision

Collaborating Actors
Dependency Injection
o Akka: Actor Refs (location/lifecycle transparent) object refs

Actors are created by Actors (then may be passed around)

Parent Children

Supervision hierarchy
Failure handling
Implementing Reactive principles

Implementing Reactive principles

from Macro and from Micro
Plain Java/Spring or Akka
Non-blocking

Never block threads waiting

Macro
o Asynchronous messaging protocols between services

Micro
Plain Java
o CompletableFuture
o Non-blocking Servlets
o Low level NIO (!)
Akka
o Actors REACT to messages: never blocks waiting.
o Have to use some discipline not to block
e.g. waiting for a response from a synchronous resource
Timeouts handlings
Handle timeouts,
for resiliency

Macro (at service boundaries)

o Outbound connection timeouts (client)
o Inbound request/response (ack) handling timeouts (server)

Micro
Plain Java
o Not easy to handle timeouts consistently ...unhandled or use default

Akka
o Everything has an explicit timeout impossible to forget
o Actor message receiving timeout handler
Handling Failure, Asynchronously

Asynchronous Failure handling

Java CompletableFuture handle exceptional completion
o Error prone; easily forgotten
o No way to separate Error and Failure handling

Actors failure handled by Supervisor

Akka: Supervisor is notified when an Actor throws an Exception
Failure : handled externally from message flow
Error: part of message handling behaviour
Persistence: Event-sourcing
Event/Command sourcing
natural persistence patterns
for distributed, asynchronous applications

Plain Java/Spring
o Write your own Event Sourcing Concursus

Event Sourcing naturally fits Actors

o Actors may be stateful
o Events and Commands are messages
When received Actor change its state
May be saved and replayed
o Actors may represent Aggregate Root (DDD) or Command Processor

Akka Persistence: Command and Event Sourcing out of the box

Conclusions
Reactive principles

Keep in mind Reactive principles

even when not using reactive technologies

Scalable and resilient applications

Many implications behind the generic principles

Does Akka help?

Does a Reactive technology like Akka help?

at Micro
Simpler, more testable concurrent code
Requires less discipline then plain Java 8
A new programming model to learn
Does Akka help?

Does a Reactive technology like Akka help?

at Macro
Still requires discipline at architectural level
Akka forces to reinvent a lot of wheels on integration
Akka doesnt integrate with Spring
Akka and Services

Akka/Actor model
Services:
NOT mutually exclusive

Consider adopting Akka for some services

The most business-critical (+resilient)
Highest concurrency
More
Reactive Manifesto
http://www.reactivemanifesto.org/
Glossary: http://www.reactivemanifesto.org/glossary

Concurrency in Erlang & Scala: The Actor Model

https://rocketeer.be/articles/concurrency-in-erlang-scala/

Introducing Actors (Akka)

http://rerun.me/2014/09/11/introducing-actors-akka-notes-part-1/

DDD and Actor model (Vaughn Vernon, DDD eXchange 2013)

https://skillsmatter.com/skillscasts/4185-vaughn-vernon

Akka project
https://github.com/akka/akka
Thanks!

Questions?