This document discusses the benefits of microservices architecture for maintainability. It argues that microservices help achieve maintainability through three main principles: 1) They allow individual services to be replaced independently without impacting the whole system, 2) They avoid redundant data and code by having separate data models and codebases for different bounded contexts, and 3) They promote independence between services which makes them easier to change and maintain separately. The document uses examples from e-commerce systems to illustrate how microservices can be organized by domain to achieve these principles of replaceability, avoidance of redundancy, and independence between teams and modules.

1. Microservices:
Redundancy =
Maintainability!
Eberhard Wolff
@ewolff
Fellow
innoQ

2. http://microservices-book.com/

3. http://microservices-book.com/primer.html
FREE!!!!

4. Maintainability
Redundant data
Redundant code

5. Legacy System

7. Too many dependencies
Cyclic dependencies
(dotted lines)

8. > COBOL, Assembler
> Not maintainable
> Not replaceable

10. > We will replace it!
> We will make it maintainable!
> It will be beautiful!

11. We will take good care of the
code!

12. Clean
Like
Spring

13. Clean Architecture

14. Developer

15. Developer

16. Result?

18. > Legacy System
> Java
> Not maintainable
> Not replaceable

20. > We didn’t try hard enough!
> We will replace it!
> We will make it
maintainable!

21. I need a new job.

22. While there are still
developers:
Replace the legacy
system.
Repeat

23. Insanity:
Doing the same thing
over and over again
and expecting different results.
Albert Einstein

24. We can achieve
maintainability with
clean architecture +
clean code.

25. We can achieve
maintainability with
clean architecture +
clean code.

26. Clean approach tried
often.
Results?

27. Lots of Legacy Code
…and secure jobs.

28. We need a different
approach!

29. Parnas 1972
Modules

30. ECommerce
System
Order
Catalog
Billing
Search

31. Modules by Domain
> Each domain problem solved in one
module.
> New features easy to add

32. Modules
> Programming language
feature
> Class, package, library …
> Rather weak modules

33. Developer

34. Microservices
> Modules
> Separate deployment units
> Separate VM / process

35. Server Server
Micro
Service
Micro
Service

36. ECommerce
System
Order
Catalog
Billing
Search
Module = separate
deployment units!

37. ECommerce
System
Order
Catalog
Billing
Search
Module = separate
deployment units!
Communication e.g. REST

38. REST REST

39. ECommerce
System
Order
Catalog
Billing
Search
Dependencies between
systems cannot sneak in

40. ECommerce
System
Order
Catalog
Billing
Search
Dependencies between
systems cannot sneak in

41. ECommerce
System
Order
Catalog
Billing
Search
Dependencies between
systems cannot sneak in
“Architecture Firewalls”

42. “Architecture Firewall”
like REST
enforce the architecture

43. ECommerce
System
Order
Catalog
Billing
Search
Components small

44. ECommerce
System
Order
Catalog
Billing
Search
Components small
Hard to mess up

45. ECommerce
System
Order
Catalog
Billing
Search
Components small
Hard to mess up

46. ECommerce
System
Catalog
Billing
Search
Components small
Hard to mess up

47. ECommerce
System
Order
Catalog
Billing
Search
Components small
Hard to mess up
Replace if messed up.

48. Small,
independent deployable
modules
are recyclable.

49. Recycle your
software!

50. How many people
are trying
to replace legacy systems?

51. Replaceability
is usually no goal
for a software project.
Why??

52. We can achieve
maintainability with
clean architecture +
clean code

53. We can achieve
maintainability with
architecture firewalls +
recyclable modules

54. Maintainability✔

55. Redundancy

56. Redundancy
Redundant data

57. Every information should be
stored and updated in one
place.

58. No redundancy for
our product data!

59. ECommerc
e
System
Products
database

60. ECommerc
e
System
Invoicing
System
Products
database

61. ECommerc
e
System
Invoicing
System
Products
database
Products
database

62. ECommerc
e
System
Products
database
Invoicing
System

63. ECommerc
e
System
Products
database
Invoicing
System
Purchase
System

64. ECommerc
e
System
Products
database
Invoicing
System
Purchase
System
Marketing
System

65. Products
data model?

67. No redundancies
High complexity
Hard to change

68. A central,
redundancy-free data
model
is the optimum.

69. A central,
redundancy-free data
model
is the optimum.

71. UBIQUITOU
S
LANGUAG
EVALUE
OBJECT
ENTITY

72. Address
VALUE
OBJECT
ENTITYor

73. 529 pages

74. 529 pages
Part IV

75. 529 pages
Part IV
Chapter 14

76. A domain model
is only useful
in a BOUNDED CONTEXT.

77. There is no
universal data model
in a large system.

78. Let me repeat:

79. There is no
universal data model
in a large system.

80. Address
for a customer
VALUE
OBJECT
ENTITYor

81. Address
for calculating the
drones’ routes
VALUE
OBJECT
ENTITYor

82. ECommerc
e
System
Products
Invoicing
System
Purchase
System
Marketing
System

83. ECommerc
e
System
Invoicing
System
Purchase
System
Marketing
System
BOUNDED
CONTEXT
BOUNDED
CONTEXT
BOUNDED
CONTEXT
BOUNDED
CONTEXT

84. Create a model
for each BOUNDED
CONTEXT.

85. Each BOUNDED CONTEXT
can be a Microservice
with its own database
schema

86. Low complexity
Easy to change
i.e. easy to
maintain

88. Few redundancies
Separate facets

89. ECommerc
e
System
Invoicing
System
Purchase
System
Marketing
System
Product:
Image
Product:
Price
Product:
Supplier
Product:
Brochure

90. A central,
redundancy-free data
model
is the optimum.

91. A central,
“redundancy-free”
data model
is often hard to maintain
and wrong.

92. Redundancy
Redundant data ✔

93. Redundancy
Redundant code

94. Redundant code:
The ultimate sin
> Fix bug in many different place
> Decisions implemented in many
places
> ...and hard to change

95. DRY
Don’t
Repeat
Yourself

96. DRY Systems?
Great!
DRY between systems?
DRY is a trade-off

97. System System System System
common common common common

98. System System System System
common abstraction

99. Reuse:
The Holy Grail
of the nineties
So where are all the
reusable internal
frameworks?

100. Premature optimization,
that’s like a sneeze.
Premature abstraction
is like Ebola;
it makes my eyes bleed.
Christer
Ericson

101. The entire history of
software engineering
is that of the
rise in levels of
abstraction.
Grady Booch

102. Using code is hard.
Reusing code is
almost impossible.
But we are reusing
Open Source all the
time!

103. Create an Open Source
project!

104. Open Source
> Good code quality
> Documentation
> Model to accept contributions

105. “But high quality Open Source is
hard.
We just share code!”
“You only provide high quality as
Open Source…
...but for colleagues low quality is
OK?”

106. Let’s assume it’s possible to reuse
code.
Reuse is still a tradeoff.

107. System System System System
common common common common

108. System System System System
abstraction

109. System System System System
abstraction
Chang
e!

110. System System System System
abstraction
Chang
e!

111. System System System System
abstraction
Chang
e!
Impact Impact Impact

112. System System System System
abstraction
Chang
e!
Impact Impact Impact

113. Now we have reuse
…and a dependency.

114. Dependency not just in
software!

115. System System System System
common abstraction
Chang
e!
Impact Impact Impact

116. Dependency between
teams
Coordination
Meetings
Getting no real work

118. Reuse is a
tradeoff:
Reuse vs.
Independence
Independence=
Easy to change=

119. Independence is
important
for self-organization.
Self-organization =
deciding yourself

120. Deciding yourself
is only possible,
if teams and
modules
are independent.

121. Redundancies between
systems must be avoided.

122. Redundancies between
systems must be avoided.

123. Reuse is a tradeoff:
Reuse vs.
Independence

124. Microservices focus
on independence

125. The Microservices Manifesto
;-)

126. Microservices Manifesto ;-)
We value:
Replaceability over
maintainability

127. Microservices Manifesto ;-)
We value:
BOUNDED CONTEXT over
redundancy-free data

128. Microservices Manifesto ;-)
We value:
Independence over
“Don’t Repeat Yourself!”

129. Replaceability over
maintainability
BOUNDED CONTEXT over
redundant-free data
Independence over DRY

130. slideslviv@ewolff.com
Slides
+ Microservices Primer
+ Sample Microservices Book
Powered by Amazon Lambda &
Microservices