WEBINAR

The Basics Of Reactive System Design For Traditional Java Enterprises

By Sean Walsh (@SeanWalshEsq) and Duncan DeVore (@ironfish)

What is Reactive?

• Responsive, even in the face of failure

• Elastic, responsive under load

• Resilient, expect failure, programmatic and systemic

• Message Driven, the only way to communicate asynchronously in a distributed environment

Why Reactive?

Exploding User Bases and Cheaper

The CAP Theorem

You can’t have your cake and eat it too.

The Monolith• Traditional way of building applications

• Monoliths do not distribute

• Typically blocking code is used everywhere

• Tight coupling all over the place

• Many times leading to…

Big Ball of Mud

• Cumulative damage due to rushed fixes and enhancements…sweeping it under the rug

• Don’t touch it, you’ll break it

• Piecemeal growth

• Too many hands in the pudding

• Can actually stop you from doing business…

A Big Ball of Mud You Say?

Story Timeof many millions of users running on

a ball of mud.

How do we avoid the monolith and distribute our systems?

Microservices

• Are not necessarily “micro” and of no strictly defined size

• Do one thing and do it well

• Are of little value individually but have great value as part of an overall system of micro services

• Distribute!

Microservices…

Ok microservices but where to start?

Help has been out there all along

Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES)

Domain Driven Design• Mapping behavior as closely as possible to the real world

• Lots of us have been doing it all along as simply “good architecture”

• Gives us a structure of practices and vocabulary via the ubiquitous language

• It also introduces the bounded context…

Bounded Contexts

• A bounded context contains its own knowledge and view of the world

• An aircraft in the flight control context may have a different meaning from the aircraft used by ground control

• When data is interchanged between contexts it is done via an anti-corruption layer…

Anti-corruption Layers

Data and events from the outside world

A bounded context as a micro service

Each bounded context is really a first pass at defining a microservice!

A bounded context becomes the basis of a microservice but there are a couple

more mechanisms that will help us not only further break it down but also help us

share data between them!

CQRS (command query responsibility segregation)

• The domain command side only accepts imperative commands such as AddFlight, which usually become events or facts such as FlightAdded

• The command side is optimized for writes only

• The command side is fully independent and runs by its lonesome

Cqrs - The Command Side

cQrs - The Query Side• The query side is purpose built for the clients

query needs and is optimized for reads and is a first class customer, not an afterthought!

• The separation of read concerns avoids the common problem of impedance mismatch

• A query side is also a fully independent microservice

All this talk of separate microservices being either read or

write…

How do the services communicate with each other? Do they even do that?

Event Sourcing FTW!• The state of any domain is the accumulation of the events that have

occurred on it over time

• Events are facts and can be published without the need to know who is subscribing

• Events are immutable and are the only storage mechanism of the domain

• Proper event sourcing will help save you from…

THIS

Events are an easy to reason about thing to publish

• Event producers (command sides) need not be aware of all their event consumers

• Services may be up or down without message loss

• New services may be brought into existence with the benefit of catching up with previous domain activities from the beginning of time!

Durable Event Pub/Sub

i s o l a t i o n

The Akka Actor Modelisolation through supervision

Why Akka?• Concurrency is hard

• Blocking is bad

• Divide and conquer through the actor model

• Reactive first, not as an afterthought

What about my current stack?• Lots of blocking code

• Distributed microservices require a bigger leap than in the past

• Reactive last, if at all; asynchronous <> reactive!

• But I’m so comfortable, maybe my tooling with catch up!

–Oren Harari

“Edison’s electric light did not come about from the continuous

improvement of the candle”

–Henry Ford

“If I had asked people what they wanted, they’d have told me ‘a faster

horse”

A final word about resilience• Resilience is like an onion and must appear in every layer

• Though the actor model and supervision hierarchies allowing isolation within each microservice

• Through the specific application cluster with unique intelligence on its own behavior

• At the datacenter OS level, across all deployed services, databases, messaging and nodes

Upgrade your grey matterGet free sample chapters and a 40% off Sean & Duncan’s book

https://www.lightbend.com/resources/e-books

MICROSERVICES.FASTDATAPIPELINES.DISTRIBUTEDSYSTEMS.

Austin(TX)-October18-20,2017

reactivesummit.org

Build modern systems for the modern world www.lightbend.com