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 Responsive
Quickly prompt to user actions
Reactive as…
• 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
ü 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 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
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 CompletableFutures
o Http non-blocking Servlets
o Fast-returning API endpoints
ü Event sourcing persistence
o 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 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
o Actors REACT on receiving a message
o No synchronisation; no lock
Actor model for dummies
Actor
Actor
Actor
Mailbox Mailbox
Mailbox
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
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 Micro
Plain Java/Spring or Akka
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
Non-blocking
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
Timeouts handlings
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
Handling Failure, Asynchronously
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
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 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
More…
Thanks!
Questions?

Spring Boot Microservices vs Akka Actor Cluster

  • 1.
    Two Reactive approachesto 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.
    2 “Reactive” is… Reactive Semantically overloadedterm adj. “Readily responsive to stimulus” [Merrian-Webster dictionary] From Latin “reagere”: act in return
  • 3.
    • Reactive asResponsive Quickly prompt to user actions Reactive as… • 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
  • 4.
    ü Responsive àLow latency ü Resilient à Stay responsive on failure ü Elastic à Scale as needed ü Message-Driven • Async messages as only communication between components Reactive Manifesto
  • 5.
    ✗ No Blockingoperation ✗ No Synchronization ✗ No Resource hogging Decoupling and isolation in… ü Time à Allow concurrency ü Space à Components location decoupling Reactive Manifesto promotes
  • 6.
    Top-down approach: fromMacro (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 Macro and Micro approaches
  • 7.
    Two real worldprojects Spring Boot μService Akka
  • 8.
    Spring Boot μServiceapplication ü 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 Spring Boot μService
  • 9.
    Java application usingAkka, 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
  • 10.
    TL;DR “The actor modelin 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)
  • 11.
    A different wayto 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 o Actors REACT on receiving a message o No synchronisation; no lock Actor model for dummies Actor Actor Actor Mailbox Mailbox Mailbox
  • 12.
    Actor handles onemessage 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 Actor model
  • 13.
    Collaborating Actors ≠ DependencyInjection 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
  • 14.
    Implementing Reactive principles ImplementingReactive principles from Macro and from Micro Plain Java/Spring or Akka
  • 15.
    Never block threadswaiting 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 Non-blocking
  • 16.
    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 Timeouts handlings
  • 17.
    Asynchronous Failure handling JavaCompletableFuture à 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 Handling Failure, Asynchronously
  • 18.
    Event/Command sourcing natural persistencepatterns 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 Persistence: Event-sourcing
  • 19.
  • 20.
    Keep in mindReactive principles …even when not using “reactive” technologies à Scalable and resilient applications Many implications behind the generic principles Reactive principles
  • 21.
    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?
  • 22.
    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?
  • 23.
    Akka/Actor model μServices: NOT mutuallyexclusive Consider adopting Akka for some services • The most business-critical (+resilient) • Highest concurrency Akka and μServices
  • 24.
    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 More…
  • 25.