Two Reactive approaches to scale

1

Comparing two approaches for scalable, message-driven, backend applications

in Java

Spring Boot μServices and Akka

Lorenzo Nicora Lorenzo.nicora@opencredo.com

2

“Reactive” is…

Reactive

Semantically overloaded term

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

From Latin “reagere”: act in return

• Reactive as ResponsiveQuickly prompt to user actions

Reactive as…

• Reactive as Data bindingDeclarative, as opposed to Imperativea=b+3

e.g. Spreadsheets

• Reactive streams as Asynchronous Data Streams

• Reactive as 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

✗ No Blocking operation✗ No Synchronization✗ No Resource hogging

Decoupling and isolation in…ü Time à Allow concurrencyü Space à Components location decoupling

Reactive Manifesto promotes

Top-down approach: from Macro(at μService boundaries)

o Message based communication between serviceso Isolation at service level

Bottom-Up approach: from Micro(within the service)

o Message based communication between componentso Non-blocking processingo Isolation at component level

Macro and Micro approaches

Two real world projects

Spring BootμService

Akka

Spring Boot μService applicationü Message-based communication between servicesü Non-blocking (where possible)

o Java 8 CompletableFutureso Http non-blocking Servletso Fast-returning API endpoints

ü Event sourcing persistenceo Concursus forerunner

ü Spring Boot and Spring Cloud Config

Spring Boot μService

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

Akka Cluster

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

Actor

Actor

Actor

Mailbox Mailbox

Mailbox

ü Article by Carl Hewitt (1973)

ü Erlang (1986)ü Akka framework (2009)

A different way to concurrency Actors, !Threads

Actor is the primary computational entityo In Java, still a mixed world of Objects and Actors

Actors interact exclusively via asynchronous messageso As opposed to Objects interacting through method callso Actors REACT on receiving a messageo No synchronisation; no lock

Actor model for dummies

Actor

Actor

Actor

Mailbox Mailbox

Mailbox

Actor handles one message a timeo Message handling code is intrinsically thread safeo May have simple state: Instance properties in Java

Actor is lightweighto Little overhead over creating an object o May be used to hold request context

• Per-request Actors: a common pattern

Actor model

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

Supervision

Implementing Reactive principles

Implementing Reactive principles

from Macro and from MicroPlain Java/Spring or Akka

Never block threads waitingMacro

o Asynchronous messaging protocols between services

MicroPlain Java

o CompletableFutureo Non-blocking Servletso Low level NIO (!)

Akkao 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

Non-blocking

Handle timeouts, for resiliency

Macro (at service boundaries)o Outbound connection timeouts (client)o Inbound request/response (ack) handling timeouts (server)

MicroPlain Java

o Not easy to handle timeouts consistently à ...unhandled or use default Akka

o Everything has an explicit timeout à impossible to forgeto Actor message receiving timeout handler

Timeouts handlings

Asynchronous Failure handlingJava CompletableFuture à handle exceptional completion

o Error prone; easily forgotteno No way to separate Error and Failure handling

Actors à failure handled by SupervisorAkka: Supervisor is notified when an Actor throws an Exception• Failure : handled externally from message flow• Error: part of message handling behaviour

Handling Failure, Asynchronously

Event/Command sourcing natural persistence patterns

for distributed, asynchronous applications

Plain Java/Springo Write your own Event Sourcing à Concursus

Event Sourcing naturally fits Actorso Actors may be statefulo 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

Persistence: Event-sourcing

Conclusions

Keep in mind Reactive principles…even when not using “reactive” technologies

à Scalable and resilient applications

Many implications behind the generic principles

Reactive principles

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 doesn’t integrate with Spring

Does Akka help?

Akka/Actor model μServices:

NOT mutually exclusive

Consider adopting Akka for some services• The most business-critical (+resilient)• Highest concurrency

Akka and μServices

Reactive Manifesto http://www.reactivemanifesto.org/à Glossary: http://www.reactivemanifesto.org/glossary

Concurrency in Erlang & Scala: The Actor Modelhttps://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

More…

Thanks!

Questions?