The document discusses principles for designing microservices and reactive systems. It covers topics like the need for microservices due to limitations of monoliths, differences between monoliths and microservices, impact of the Reactive Manifesto, and 10 design principles for microservices/reactive systems including embracing asynchronicity, autonomy, bulkheading, single responsibility, statelessness, distribution transparency, past nature of information, eventual consistency, monitoring/observability, and error recovery. The presentation emphasizes concepts like commands, events, and distributed tracing over buzzwords.

1. Microservices &
Reactive Systems
Lessons learned

2. About me ...
- Passionate software engineer
- Focused mainly on JVM
- Interested in all software development phases
- Having erethic opinions
- Non politically correct, but just correct …
- Personal belief: “living in a distributed and reactive full of actors system”
@bogdan.dina03
Posting on: @dinabogdan03

3. Agenda
1. “The mess we’re in”
2. The need for microservices
3. Monoliths vs microservices?
4. The impact of the Reactive Manifesto
5. Principles of good design in a microservices or reactive world
6. Today’s conclusions and more
7. The future stands in front of us

4. “The mess we’re in”

5. “The mess we’re in”
- Microservices

6. “The mess we’re in”
- Microservices
- Miniservices

7. “The mess we’re in”
- Microservices
- Miniservices
- Self-Contained Systems (SCS)

8. “The mess we’re in”
- Microservices
- Miniservices
- Self-Contained Systems (SCS)
- Reactive microservices

9. “The mess we’re in”
- Microservices
- Miniservices
- Self-Contained Systems (SCS)
- Reactive microservices
- Reactive microsystems

10. “The mess we’re in”.
What about it?

11. “The mess we’re in”. What about it?
- Focus on the fundamental to-be followed ideas

12. “The mess we’re in”. What about it?
- Focus on the fundamental to-be followed ideas
- Think in terms of patterns

13. “The mess we’re in”. What about it?
- Focus on the fundamental to-be followed ideas
- Think in terms of patterns
- Forget about buzzy terminology

14. “The mess we’re in”. What about it?
- Focus on the fundamental to-be followed ideas
- Think in terms of patterns
- Forget about buzzy terminology
- Strive for achieving responsiveness, scalability and,
fault-tolerance

15. The need for
microservices

16. The need for microservices
Q: Why did microservices appeared?

17. The need for microservices
Q: Why did microservices appeared?
A: Because of monoliths!

18. The need for microservices
Q: Why did microservices appeared?
A: Because of monoliths!
* Don’t forget about “Monolith first” approach!

19. The need for microservices
Q: Why did microservices appeared?
A: Because of monoliths!
* Don’t forget about “Monolith first” approach!
** Avoid “Big Ball of Mud”!

20. The need for microservices
Q: Why did microservices appeared?
A: Because of monoliths!
* Don’t forget about “Monolith first” approach!
** Avoid “Big Ball of Mud”!
*** Avoid “Distributed Big Ball of mud”!

21. The need for
microservices - Not
agree?

22. The need for microservices - An iteration

23. The need for microservices - The next iteration

24. Monoliths vs
Microservices?

25. Monoliths vs Microservices? Adopting monoliths
again?
- The initial incarnation of microservices failed

26. Monoliths vs Microservices? Adopting monoliths
again?
- The initial incarnation of microservices failed
- “Correctly built distributed systems” should
raise an alarm!

27. Monoliths vs Microservices?
“[...] a monolithic application puts all its functionality into a single process and
scales by replicating the monolith on multiple servers”,
whilst
“[...] a microservices architecture puts each element of functionality into a separate
service and scales by distributing these services across servers, replicating as
needed”.
Martin Fowler

28. Monoliths vs
Microservices? Main
ideas

29. Monoliths vs Microservices? Main ideas
- Start with a monolith

30. Monoliths vs Microservices? Main ideas
- Start with a monolith
- Don’t forget to modularize it (Domain-Driven Design)

31. Monoliths vs Microservices? Main ideas
- Start with a monolith
- Don’t forget to modularize it
- Decompose into separate components when needed
(microservices)

32. The impact of
Reactive Manifesto

33. The impact of Reactive Manifesto

34. The impact of Reactive Manifesto
- Published in 2014

35. The impact of Reactive Manifesto
- Published in 2014
- Rethinking the old distributed systems

36. The impact of Reactive Manifesto
- Published in 2014
- Rethinking the old distributed systems
- Empowers correctly building of distributed systems

37. Principles of good
design in a
microservices or
reactive world

38. 10 Principles of good design
1. Asynchronicity
2. Autonomy
3. Bulkheading
4. Single Responsibility Principle
5. Stateless
6. Distribution transparency
7. Past nature of information
8. Eventual consistency
9. Monitoring, observability and
distributed tracing
10. Recovering from errors

39. Embrace
Asynchronicity!
But Why?

40. Embrace Asynchronicity! But why?

41. Embrace Asynchronicity! But why?
- Loose coupling

42. Embrace Asynchronicity! But why?
- Loose coupling
- Concurrency in time

43. Embrace Asynchronicity! But why?
- Loose coupling
- Concurrency in time
- Mobility and distribution in space

44. Embrace Asynchronicity! But why?
- Loose coupling
- Concurrency in time
- Mobility and distribution in space
- Responsiveness and elasticity

45. Synchronous vs Asynchronous

46. Synchronous vs Asynchronous

47. Act autonomously

48. How to gain autonomy?

49. How to gain autonomy?
- The isolation level between them

50. How to gain autonomy?
- The isolation level between them
- The capacity to act independently in doing business
tasks

51. How to gain autonomy?
- The isolation level between them
- The capacity to act independently in doing business tasks
- The capacity to fail independently

52. How to gain autonomy?
- The isolation level between them
- The capacity to act independently in doing business tasks
- The capacity to fail independently
- The collaboration level between microservices

53. About autonomy when monolith vs microservices

54. Monolith vs microservices - autonomy POV
In the case of monolith:
- multiple software constructions
deployed as a single deployment unit
- no isolation between them
- components are not acting
autonomously
- if one fails => the rest will also fail

55. Monolith vs microservices - autonomy POV
In the case of monolith:
- multiple software constructions
deployed as a single deployment unit
- no isolation between them
- components are not acting
autonomously
- if one fails => the rest will also fail
In the case of microservices:
- individual deployment units
- isolated components
- autonomy
- if one will fail => the rest of other will
still be working

56. Bulkheading

57. Bulkheading
- it covers both monoliths and microservices

58. Bulkheading
- it covers both monoliths and microservices
- isolates application into separate pools => if one fails, the
rest will not

59. Bulkheading
- it covers both monoliths and microservices
- isolates application into separate pools => if one fails, the rest
will not
- coming from ships

61. Single Responsibility
Principle

62. A microservice asks: What is my responsibility ?!
- a microservice/monolith’s module must have a
single responsibility (SRP)

63. A microservice asks: What is my responsibility ?!
- a microservice/monolith’s module must have a single
responsibility (SRP)
- better decoupling

64. A microservice asks: What is my responsibility ?!
- a microservice/monolith’s module must have a single
responsibility (SRP)
- better decoupling
- higher autonomy degree

65. Stateless

66. Just take care of your own state!!!
- a microservice/monolith’s module takes responsibility
for its own state

67. Just take care of your own state!!!
- a microservice/monolith’s module takes responsibility for
its own state
- Law of Demeter

68. Just take care of your own state!!!
- a microservice/monolith’s module takes responsibility for
its own state
- Law of Demeter
- Tell, don’t ask

69. Law of Demeter

70. Tell, don’t ask!

71. Leads us to ...
- commands
- events

72. Distribution
transparency

73. Distribution transparency
- fundamental property of modern distributed
systems

74. Distribution transparency
- fundamental property of modern distributed systems
- components can be moved around

75. Distribution transparency
- fundamental property of modern distributed systems
- components can be moved around
- Location Transparency => 1/7

76. “Information is always
from the past” - Jonas
Bonér

77. Past nature of information
- think in terms of past events containing pieces of
information

78. Past nature of information
- think in terms of past events containing pieces of
information
- avoid querying for “current” state

79. Past nature of information
- think in terms of past events containing pieces of
information
- avoid querying for “current” state
- embrace commands (eg: “enrollNewCustomer”)

80. Past nature of information
- think in terms of past events containing pieces of
information
- avoid querying for “current” state
- send and receive commands (eg:
“enrollNewCustomer”)
- react to and emit events (eg: “customerEnrolled”)

81. Commands & Events
- loose coupling
- asynchronous communication
- isolation

82. Eventual Consistency
& Transactions

83. What about transactions?
- leverage Domain-Driven Design

84. What about transactions?
- leverage Domain-Driven Design
- one aggregate/microservice or monolith’s module

85. What about transactions?
- leverage Domain-Driven Design
- one aggregate/microservice or monolith’s module
- aggregate’s rule of thumb about transactions

86. What about transactions?
- leverage Domain-Driven Design
- one aggregate/microservice or monolith’s module
- aggregate’s rule of thumb about transactions
- forget about 2PC and heuristic decisions

87. What about transactions? More ...
- business processes involve more than a single
component

88. What about transactions? More ...
- business processes involve more than a single
component
- avoid inconsistent states

89. What about transactions? Solutions!
- SAGA Pattern/long-running business transaction
pattern

90. What about transactions? Solutions!
- SAGA Pattern/long-running business transaction pattern
- pairs like <Transaction, Compensation>

91. SAGA Pattern

92. Async but … I can’t
find the trace!

93. Distributed tracing
- async => finding trace :(

94. Distributed tracing
- async => finding trace :(
- leverage Distributed Tracing

95. Am I under
observation?
Someone should
supervise me! I could
die in thread.SLEEP()

96. Monitoring & Observability
- binary state: working or failed

97. Monitoring & Observability
- binary state: working or failed
- actively monitor and observe components

98. Monitoring & Observability
- binary state: working or failed
- actively monitor and observe components
- SRE practices: SLIs, SLOs & SLAs and error budgets

99. Monitoring & Observability
- binary state: working or failed
- actively monitor and observe components
- SRE practices: SLIs, SLOs & SLAs and error budgets
- preemptively eliminate possible failures

100. What about recovering
from failure?

101. Recovering from failure
- reactive systems must be resilient

102. Recovering from failure
- reactive systems must be resilient
- not avoid failures, but embrace them

103. Recovering from failure
- reactive systems must be resilient
- not avoid failures, but embrace them
- replication

104. Recovering from failure
- reactive systems must be resilient
- not avoid failures, but embrace them
- replication
- isolation

105. Recovering from failure
- reactive systems must be resilient
- not avoid failures, but embrace them
- replication
- isolation
- delegation

106. Recovering from failure
- reactive systems must be resilient
- not avoid failures, but embrace them
- replication
- isolation
- delegation
- elasticity matters

107. The hard part comes
now ...

108. Today’s conclusions
- starting point for creating individual microservices

109. Today’s conclusions
- starting point for creating individual microservices
- easy to reason with

110. Today’s conclusions
- starting point for creating individual microservices
- easy to reason with
- “A microservice is not of much use, they always come
as systems” - Jonas Bonér

111. Systems of microservices includes ...
- coordination (orchestration vs choreography)

112. Systems of microservices includes ...
- coordination (orchestration vs choreography)
- security of the entire system

113. Systems of microservices includes ...
- coordination (orchestration vs choreography)
- security of the entire system
- replication

114. Systems of microservices includes ...
- coordination (orchestration vs choreography)
- security of the entire system
- replication
- data consistency

115. Systems of microservices includes ...
- coordination (orchestration vs choreography)
- security of the entire system
- replication
- data consistency
- deployment models

116. Systems of microservices includes ...
- coordination (orchestration vs choreography)
- security of the entire system
- replication
- data consistency
- deployment models
- integration models

117. The future stands in
front of us

118. What brings the future

119. What brings the future
- ACID 2.0

120. What brings the future
- ACID 2.0
- event streaming

121. What brings the future
- ACID 2.0
- event streaming
- managing state

122. What brings the future
- ACID 2.0
- event streaming
- managing state
- cloud-native deployment strategies

123. What brings the future
- ACID 2.0
- event streaming
- managing state
- cloud-native deployment strategies
- service mesh

124. Thank you !
● Don’t forget to follow me on @dinabogdan03
● Don’t forget to read my articles on @bogdan.dina03