We assume software should contain no redundancies and that a clean architecture is the way to a maintainable system. Microservices challenge these assumptions. Keynote from Entwicklertage 2016 in Karlsruhe.

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

2. http://continuous-delivery-buch.de/

3. http://microservices-buch.de/ http://microservices-book.com/

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

5. Maintainablity
Redundant data
Redudant code

6. Legacy System

8. Too many dependencies
Cyclic dependencies
(dotted lines)

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

10. L

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

12. We will take good care
of the code!

13. Clean
Like
Spring

14. Clean Architecture

15. Developer

16. Developer

17. Result?

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

20. L

21. > We didn’t try hard enough!
> We will replace it!
> We will make it maintainable!
> It will be beautiful!

22. LI need a new job.

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

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

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

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

27. Clean approach tried often.
Results?

28. Lots of Legacy Code
…and secure jobs.

29. We need a different
approach!

30. Parnas 1972
Modules

31. ECommerce
System
Order
Catalog
Billing
Search

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

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

34. Developer

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

36. Server Server
Micro
Service
Micro
Service

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

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

39. REST REST

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

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

43. “Architecture Firewall”
like REST
enforce the architecture

44. ECommerce
System
Order
Catalog
Billing
Search
Components small

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

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

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

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

49. Small,
independent deployable
modules
are recyclable.

50. Recycle your
software!
!

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

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

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

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

55. Maintainability

56. Redundancy

57. Redundancy
Redundant data

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

59. No redundancy for
our product data!

60. ECommerce
System
Products
database

61. ECommerce
System
Invoicing
System
Products
database

62. ECommerce
System
Invoicing
System
Products
database
Products
database

63. ECommerce
System
Products
database
Invoicing
System

64. ECommerce
System
Products
database
Invoicing
System
Purchase
System

65. ECommerce
System
Products
database
Invoicing
System
Purchase
System
Marketing
System

66. Products
data model?

68. No redundancies
High complexity
Hard to change

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

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

71. UBIQUITOUS
LANGUAGE
VALUE
OBJECT
ENTITY

72. Address
VALUE
OBJECT
ENTITYor

73. 529 pages
Part IV
Chapter 14

74. A domain model
is only useful
in a Bounded Context.

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

76. Let me repeat:

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

78. Address
for a customer
VALUE
OBJECT
ENTITYor

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

80. ECommerce
System
Products
Invoicing
System
Purchase
System
Marketing
System

81. ECommerce
System
Invoicing
System
Purchase
System
Marketing
System
BOUNDED
CONTEXT
BOUNDED
CONTEXT
BOUNDED
CONTEXT
BOUNDED
CONTEXT

82. Create a model
for each BOUNDED CONTEXT.

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

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

86. Few redundancies
Separate facets

87. ECommerce
System
Invoicing
System
Purchase
System
Marketing
System
Product:
Image
Product:
Price
Product:
Supplier
Product:
Brochure

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

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

90. Redundancy
Redundant data

91. Redundancy
Redundant code

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

93. DRY
Don’t
Repeat
Yourself

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

95. System System System System
common common common common

96. System System System System
common abstraction

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

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

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

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

101. Create an Open
Source project!

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

103. “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?”

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

105. System System System System
common common common common

106. System System System System
abstraction

107. System System System System
abstraction
Change!

108. System System System System
abstractionChange!

109. System System System System
abstractionChange!
Impact Impact Impact

110. System System System System
abstractionChange!
Impact Impact Impact

111. Now we have reuse
…and a dependency.

112. Dependency not just
in software!

113. System System System System
common abstractionChange!
Impact Impact Impact

114. Dependency between teams
Coordination
Meetings
Getting no real work done

115. L

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

117. Independence is important
for self-organization.
Self-organization =
deciding yourself
Not meetings upon meetings

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

119. Redundancies between
systems must be avoided.

120. Redundancies between
systems must be avoided.

121. Reuse is a tradeoff:
Reuse vs.
Independence

122. Microservices focus
on independence

123. The Microservices
Manifesto ;-)

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

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

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

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