Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
Microservices: Redundancy = Maintainability! Eberhard Wolff @ewolff Fellow innoQ
Slide 2
Slide 2 text
http://continuous-delivery-buch.de/
Slide 3
Slide 3 text
http://microservices-buch.de/ http://microservices-book.com/
Slide 4
Slide 4 text
http://microservices-book.com/primer.html FREE!!!!
Slide 5
Slide 5 text
Maintainablity Redundant data Redudant code
Slide 6
Slide 6 text
Legacy System
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
Too many dependencies Cyclic dependencies (dotted lines)
Slide 9
Slide 9 text
> COBOL, Assembler > Not maintainable > Not replaceable
Slide 10
Slide 10 text
L
Slide 11
Slide 11 text
> We will replace it! > We will make it maintainable! > It will be beautiful!
Slide 12
Slide 12 text
We will take good care of the code!
Slide 13
Slide 13 text
Clean Like Spring
Slide 14
Slide 14 text
Clean Architecture
Slide 15
Slide 15 text
Developer
Slide 16
Slide 16 text
Developer
Slide 17
Slide 17 text
Result?
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
> Legacy System > Java > Not maintainable > Not replaceable
Slide 20
Slide 20 text
L
Slide 21
Slide 21 text
> We didn’t try hard enough! > We will replace it! > We will make it maintainable! > It will be beautiful!
Slide 22
Slide 22 text
L I need a new job.
Slide 23
Slide 23 text
While there are still developers: Replace the legacy system. Repeat
Slide 24
Slide 24 text
Insanity: Doing the same thing over and over again and expecting different results. Albert Einstein
Slide 25
Slide 25 text
We can achieve maintainability with clean architecture + clean code.
Slide 26
Slide 26 text
We can achieve maintainability with clean architecture + clean code.
Slide 27
Slide 27 text
Clean approach tried often. Results?
Slide 28
Slide 28 text
Lots of Legacy Code …and secure jobs.
Slide 29
Slide 29 text
We need a different approach!
Slide 30
Slide 30 text
Parnas 1972 Modules
Slide 31
Slide 31 text
ECommerce System Order Catalog Billing Search
Slide 32
Slide 32 text
Modules by Domain > Each domain problem solved in one module. > New features easy to add
Slide 33
Slide 33 text
Modules > Programming language feature > Class, package, library … > Rather weak modules
Slide 34
Slide 34 text
Developer
Slide 35
Slide 35 text
Microservices > Modules > Separate deployment units > Separate VM / process
Slide 36
Slide 36 text
Server Server Micro Service Micro Service
Slide 37
Slide 37 text
ECommerce System Order Catalog Billing Search Module = separate deployment units!
Slide 38
Slide 38 text
ECommerce System Order Catalog Billing Search Module = separate deployment units! Communication e.g. REST
Slide 39
Slide 39 text
REST REST
Slide 40
Slide 40 text
ECommerce System Order Catalog Billing Search Dependencies between systems cannot sneak in
Slide 41
Slide 41 text
ECommerce System Order Catalog Billing Search Dependencies between systems cannot sneak in
Slide 42
Slide 42 text
ECommerce System Order Catalog Billing Search Dependencies between systems cannot sneak in “Architecture Firewalls”
Slide 43
Slide 43 text
“Architecture Firewall” like REST enforce the architecture
Slide 44
Slide 44 text
ECommerce System Order Catalog Billing Search Components small
Slide 45
Slide 45 text
ECommerce System Order Catalog Billing Search Components small Hard to mess up
Slide 46
Slide 46 text
ECommerce System Order Catalog Billing Search Components small Hard to mess up
Slide 47
Slide 47 text
ECommerce System Catalog Billing Search Components small Hard to mess up
Slide 48
Slide 48 text
ECommerce System Order Catalog Billing Search Components small Hard to mess up Replace if messed up.
Slide 49
Slide 49 text
Small, independent deployable modules are recyclable.
Slide 50
Slide 50 text
Recycle your software! !
Slide 51
Slide 51 text
How many people are trying to replace legacy systems?
Slide 52
Slide 52 text
Replaceability is usually no goal for a software project. Why??
Slide 53
Slide 53 text
We can achieve maintainability with clean architecture + clean code
Slide 54
Slide 54 text
We can achieve maintainability with architecture firewalls + recyclable modules
Slide 55
Slide 55 text
Maintainability
Slide 56
Slide 56 text
Redundancy
Slide 57
Slide 57 text
Redundancy Redundant data
Slide 58
Slide 58 text
Every information should be stored and updated in one place.
Slide 59
Slide 59 text
No redundancy for our product data!
Slide 60
Slide 60 text
ECommerce System Products database
Slide 61
Slide 61 text
ECommerce System Invoicing System Products database
Slide 62
Slide 62 text
ECommerce System Invoicing System Products database Products database
Slide 63
Slide 63 text
ECommerce System Products database Invoicing System
Slide 64
Slide 64 text
ECommerce System Products database Invoicing System Purchase System
Slide 65
Slide 65 text
ECommerce System Products database Invoicing System Purchase System Marketing System
Slide 66
Slide 66 text
Products data model?
Slide 67
Slide 67 text
No content
Slide 68
Slide 68 text
No redundancies High complexity Hard to change
Slide 69
Slide 69 text
A central, redundancy-free data model is the optimum.
Slide 70
Slide 70 text
A central, redundancy-free data model is the optimum.
Slide 71
Slide 71 text
UBIQUITOUS LANGUAGE VALUE OBJECT ENTITY
Slide 72
Slide 72 text
Address VALUE OBJECT ENTITY or
Slide 73
Slide 73 text
529 pages Part IV Chapter 14
Slide 74
Slide 74 text
A domain model is only useful in a Bounded Context.
Slide 75
Slide 75 text
There is no universal data model in a large system.
Slide 76
Slide 76 text
Let me repeat:
Slide 77
Slide 77 text
There is no universal data model in a large system.
Slide 78
Slide 78 text
Address for a customer VALUE OBJECT ENTITY or
Slide 79
Slide 79 text
Address for calculating the drones’ routes VALUE OBJECT ENTITY or
Slide 80
Slide 80 text
ECommerce System Products Invoicing System Purchase System Marketing System
Slide 81
Slide 81 text
ECommerce System Invoicing System Purchase System Marketing System BOUNDED CONTEXT BOUNDED CONTEXT BOUNDED CONTEXT BOUNDED CONTEXT
Slide 82
Slide 82 text
Create a model for each BOUNDED CONTEXT.
Slide 83
Slide 83 text
Each BOUNDED CONTEXT can be a Microservice with its own database schema
Slide 84
Slide 84 text
Low complexity Easy to change i.e. easy to maintain
Slide 85
Slide 85 text
No content
Slide 86
Slide 86 text
Few redundancies Separate facets
Slide 87
Slide 87 text
ECommerce System Invoicing System Purchase System Marketing System Product: Image Product: Price Product: Supplier Product: Brochure
Slide 88
Slide 88 text
A central, redundancy-free data model is the optimum.
Slide 89
Slide 89 text
A central, “redundancy-free” data model is often hard to maintain and wrong.
Slide 90
Slide 90 text
Redundancy Redundant data
Slide 91
Slide 91 text
Redundancy Redundant code
Slide 92
Slide 92 text
Redundant code: The ultimate sin > Fix bug in many different place > Decisions implemented in many places > ...and hard to change
Slide 93
Slide 93 text
DRY Don’t Repeat Yourself
Slide 94
Slide 94 text
DRY Systems? Great! DRY between systems? DRY is a trade-off
Slide 95
Slide 95 text
System System System System common common common common
Slide 96
Slide 96 text
System System System System common abstraction
Slide 97
Slide 97 text
Reuse: The Holy Grail of the nineties So where are all the reusable internal frameworks?
Slide 98
Slide 98 text
Premature optimization, that’s like a sneeze. Premature abstraction is like Ebola; it makes my eyes bleed. Christer Ericson
Slide 99
Slide 99 text
The entire history of software engineering is that of the rise in levels of abstraction. Grady Booch
Slide 100
Slide 100 text
Using code is hard. Reusing code is almost impossible. But we are reusing Open Source all the time!
Slide 101
Slide 101 text
Create an Open Source project!
Slide 102
Slide 102 text
Open Source > Good code quality > Documentation > Model to accept contributions
Slide 103
Slide 103 text
“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?”
Slide 104
Slide 104 text
Let’s assume it’s possible to reuse code. Reuse is still a tradeoff.
Slide 105
Slide 105 text
System System System System common common common common
Slide 106
Slide 106 text
System System System System abstraction
Slide 107
Slide 107 text
System System System System abstraction Change!
Slide 108
Slide 108 text
System System System System abstraction Change!
Slide 109
Slide 109 text
System System System System abstraction Change! Impact Impact Impact
Slide 110
Slide 110 text
System System System System abstraction Change! Impact Impact Impact
Slide 111
Slide 111 text
Now we have reuse …and a dependency.
Slide 112
Slide 112 text
Dependency not just in software!
Slide 113
Slide 113 text
System System System System common abstraction Change! Impact Impact Impact
Slide 114
Slide 114 text
Dependency between teams Coordination Meetings Getting no real work done
Slide 115
Slide 115 text
L
Slide 116
Slide 116 text
Reuse is a tradeoff: Reuse vs. Independence Independence= Easy to change= Maintainability
Slide 117
Slide 117 text
Independence is important for self-organization. Self-organization = deciding yourself Not meetings upon meetings
Slide 118
Slide 118 text
Deciding yourself is only possible, if teams and modules are independent.
Slide 119
Slide 119 text
Redundancies between systems must be avoided.
Slide 120
Slide 120 text
Redundancies between systems must be avoided.
Slide 121
Slide 121 text
Reuse is a tradeoff: Reuse vs. Independence
Slide 122
Slide 122 text
Microservices focus on independence
Slide 123
Slide 123 text
The Microservices Manifesto ;-)
Slide 124
Slide 124 text
Microservices Manifesto ;-) We value: Replaceability over maintainability
Slide 125
Slide 125 text
Microservices Manifesto ;-) We value: BOUNDED CONTEXT over redundancy-free data
Slide 126
Slide 126 text
Microservices Manifesto ;-) We value: Independence over “Don’t Repeat Yourself!”
Slide 127
Slide 127 text
Replaceability over maintainability BOUNDED CONTEXT over redundant-free data Independence over DRY