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