The document discusses the transition from monolithic architecture to microservices, emphasizing the challenges and necessary evolution toward creating resilient, scalable systems known as microsystems. It highlights the importance of event-driven design, reactive programming, and event-based persistence to enhance system performance while managing state effectively. The document concludes with practical guidelines for developers, advocating against microliths and promoting the use of reactive principles and event-first methodologies.

1. REACTIVE MICROSYSTEMS
THE EVOLUTION OF MICROSERVICES AT SCALE
JONAS BONÉR
@JBONER

2. WE HAVE BEEN SPOILED BY
THE ALMIGHTY
MONOLITH

3. KNOCK, KNOCK. WHO’S THERE?
REALITY

5. WE CAN'T MAKE THE HORSE FASTER

6. WE NEED CARS FOR WHERE WE ARE GOING

7. BUT DON'T JUST DRINK THE
THINK FOR YOURSELF

8. NO ONE WANTS
MICROSERVICES
IT'S A NECCESSARY EVIL

9. ARCHITECTURAL CONTEXT OF MICROSERVICES:
DISTRIBUTED SYSTEMS

10. TODAY'S JOURNEY

11. LET'S SAY THAT WE WANT TO SLICE THIS MONOLITH UP

12. TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS

13. MICROLITH:
SINGLE INSTANCE
MICROSERVICE
-NOT RESILIENT
-NOT ELASTIC

14. One actor is no actor.
Actors come in systems.
— Carl Hewitt

15. MICROSERVICES
COME IN SYSTEMS

16. 3 HELPFUL TOOLS
1. EVENTS-FIRST DDD
2. REACTIVE DESIGN
3. EVENT-BASED PERSISTENCE

17. PRACTICE
EVENTS-FIRST
DOMAIN-DRIVEN DESIGN

18. DON'T FOCUS ON THE THINGS
the nouns
the domain objects
FOCUS ON WHAT HAPPENS
the verbs
the events

19. When you start modeling events,
it forces you to think about the
behavior of the system,
as opposed to thinking about
structure inside the system.
— Greg Young

20. LET THE
EVENTS DEFINE
THE BOUNDED CONTEXT

21. EVENTS REPRESENT FACTS

22. To condense fact from
the vapor of nuance
— Neal Stephenson, Snow Crash

23. WHAT ARE THE FACTS?

24. TRY OUT
EVENT STORMING

25. UNDERSTAND HOW FACTS ARE CAUSALLY RELATED
HOW FACTS FLOW IN THE SYSTEM

26. THINK IN TERMS OF
CONSISTENCY BOUNDARIES

27. WE NEED TO
CONTAIN MUTABLE STATE &
PUBLISH FACTS

28. AGGREGATEUNIT OF CONSISTENCY
UNIT OF FAILURE

29. PRACTICE
REACTIVE DESIGN

30. REACTIVE PROGRAMMING
VS
REACTIVE SYSTEMS

31. REACTIVE PROGRAMMING
CAN HELP US MAKE THE
INDIVIDUAL INSTANCE
HIGHLY PERFORMANT & EFFICIENT

32. GOASYNCHRONOUS

33. ASYNCHRONOUS
& NON-BLOCKING
- MORE EFFICIENT USE OF RESOURCES
- MINIMIZES CONTENTION ON SHARED
RESOURCES

34. ALWAYS APPLY BACKPRESSURE
A FAST SYSTEM
SHOULD NOT OVERLOAD
A SLOW SYSTEM

35. BACKPRESSURE

36. LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS

37. WE'RE GETTING THERE, BUT WE STILL HAVE A
SINGLE INSTANCE MICROSERVICE
NOT SCALABLE
NOT RESILIENT

38. REACTIVE SYSTEMS
CAN HELP US BUILD
DISTRIBUTED SYSTEMS THAT ARE
ELASTIC & RESILIENT

39. REACTIVE SYSTEMS ARE BASED ON
ASYNCHRONOUS
MESSAGE-PASSING

40. ALLOWS DECOUPLING IN
SPACEAND
TIME

41. ALLOWS FOR LOCATION TRANSPARENCY
ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE
CORE SOCKET CPU
CONTAINER SERVER RACK
DATA CENTER SYSTEM

42. SELF-HEALING THROUGH BULKHEADING

43. SELF-HEALING THROUGH SUPERVISION

44. MICROSERVICES
COME AS SYSTEMS

45. EACH MICROSERVICENEEDS BE DESIGNED AS
A DISTRIBUTED SYSTEM
A MICROSYSTEM

46. WE NEED TO MOVE
FROM MICROLITHS
TO MICROSYSTEMS

47. SEPARATE THE
STATELESS BEHAVIOR
FROM THE
STATEFUL ENTITY
TO SCALE THEM INDIVIDUALLY

48. SCALING (STATELESS) BEHAVIOR
IS EASY

49. SCALING (STATEFUL) ENTITIES
IS HARD

50. THERE IS NO SUCH THING AS A
"STATELESS" ARCHITECTURE
IT'S JUST SOMEONE ELSE'S PROBLEM

51. REACTIVE
MICROSYSTEM

52. PRACTICE
EVENT-BASED
PERSISTENCE

53. Update-in-place strikes systems
designers as a cardinal sin:
it violates traditional accounting
practices that have been observed
for hundreds of years.
— Jim Gray

54. The truth is the log.
The database is a cache of a
subset of the log.
— Pat Helland

55. EVENT LOGGINGFOR SCALABLE PERSISTENCE

56. CRUD
IS DEAD

57. EVENT SOURCING
A CURE FOR THE CARDINAL SIN

58. Modeling events forces you to
have a temporal focus on what’s
going on in the system.
Time becomes a crucial factor of
the system.
— Greg Young

59. THE LOGIS A DATABASE OF THE PAST
NOT JUST A DATABASE OF THE PRESENT

60. EVENT LOGGING AVOIDS THE INFAMOUS
OBJECT-RELATIONAL
IMPEDENCE MISMATCH

61. UNTANGLE THE
READ & WRITEMODELS WITH
CQRS

62. ADVANTAGES OF USING CQRS:
1. RESILIENCE
2. SCALABILITY
3. POLYGLOT
PERSISTENCE

63. USE
EVENT SOURCING
AND
EVENT STREAMING

64. HOW CAN WE
COORDINATE WORK
ACROSS AGGREGATES?

65. EVENT-DRIVEN
WORKFLOW

66. BUT WHAT ABOUT
TRANSACTIONS?

67. Two-phase commit is the
anti-availability protocol.
— Pat Helland

68. In general,
application developers
simply do not implement
large scalable
applications
assuming distributed
transactions.
— Pat Helland

69. USE A PROTOCOL OF
GUESS.
APOLOGIZE.
COMPENSATE.

70. IT'S HOW THE
WORLD WORKS

71. USE SAGASNOT DISTRIBUTED TRANSACTIONS

73. IN SUMMARY
1. Don't build Microliths
2. Microservices come in (distributed) systems
3. Microservices come as (micro)systems
4. Embrace the Reactive principles
5. Embrace Event-first DDD & Persistence
6. Profit!

74. TRY THE
LAGOMMICROSERVICES FRAMEWORK
POWERED BY AKKA & PLAY
LAGOMFRAMEWORK.COM

75. LEARN MOREDOWNLOAD MY BOOK FOR FREE AT:
BIT.LY/REACTIVE-MICROSYSTEMS