Like most things in life, in software there exists an Old and a New way of doing things. The growth of computing power, increase in the sheer number of users, cheaper and more available hardware, and the explosive IoT market mandates that we build our systems using modern methods that diverge from past. This modern way is called “Reactive”, which was first co-authored by Lightbend in 2013 with the Reactive Manifesto and now has over 15,000 signatories. With 2017 nearly upon us, we now see the market widely embracing Reactive in response to the many Architects, Developers and DevOps practitioners failing to meet tough new demands on their systems using last year’s technologies and monolithic designs. Yet with this popularity, the term Reactive is being overloaded and confused. Some believe that asynchronous messaging alone is good enough. As we will see, this is only part of the puzzle. In this webinar aimed at Architects and Developers working with more traditional Java environments, Lightbend’s Sean Walsh and Duncan DeVore take us on a journey that goes beyond just asynchronous programming and into the very basics of designing Reactive systems as a whole. We will review: *Why simply implementing asynchronous messaging is only part of the puzzle, and what it means to build entire systems as a whole based on the principles of Reactive system design: message-driven, resilient, elastic and responsive. *How to avoid repeatedly building monoliths by embracing tried-and-true concepts of Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS) and Event Sourcing. *How the Actor Model with Akka makes concurrency a breeze and harnesses clustered computing capabilities to divide and conquer work. *How to design systems that can self-heal, self-scale, both up and down and truly provide the most real time and responsive experience for your customers, clients and partners while being a joy to program and maintain.

1. WEBINAR
The Basics Of Reactive System Design For
Traditional Java Enterprises
By Sean Walsh (@SeanWalshEsq) and Duncan DeVore (@ironfish)

2. What is Reactive?

3. • 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

4. Why Reactive?

5. Exploding User Bases and Cheaper

6. The CAP Theorem
You can’t have your cake and eat it too.

7. 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…

8. Big Ball of Mud

9. • 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?

10. Story Time
of many millions of users running on
a ball of mud.

11. How do we avoid the monolith
and distribute our systems?

12. Microservices

13. • 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…

14. Ok microservices
but where to start?

15. Help has been
out there all along
Domain Driven Design (DDD), Command Query
Responsibility Segregation (CQRS) and Event Sourcing (ES)

16. 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…

17. Bounded Contexts

18. • 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…

19. Anti-corruption Layers
Data and events from the outside world
A bounded context
as a micro service

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

21. 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!

22. CQRS (command query
responsibility segregation)

23. • 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

24. 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

25. All this talk of separate
microservices being either read or
write…
How do the services communicate with
each other? Do they even do that?

26. 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…

27. THIS

28. Events are an easy to reason about thing to
publish

29. • 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

30. i s o l a t i o n

31. The Akka Actor Model
isolation through supervision

32. Why Akka?
• Concurrency is hard
• Blocking is bad
• Divide and conquer through the actor model
• Reactive first, not as an afterthought

33. 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!

34. –Oren Harari
“Edison’s electric light did not come
about from the continuous
improvement of the candle”

35. –Henry Ford
“If I had asked people what they
wanted, they’d have told me ‘a faster
horse”

36. 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

37. Upgrade your grey matter
Get free sample chapters and a 40% off Sean & Duncan’s book
https://www.lightbend.com/resources/e-books

38. MICROSERVICES. FAST DATA PIPELINES. DISTRIBUTED SYSTEMS.
Austin (TX) - October 18-20, 2017
reactivesummit.org

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