Microservices Meet Real-World Projects: Lessons Learned @ Microservices-Meetup-Rhein-Main

Slide 1

Slide 1 text

MicroServices meet Real World projects www.innoQ.com

Slide 2

Slide 2 text

MicroServices meet Real World projects www.innoQ.com

Slide 3

Slide 3 text

Alexander Heusingfeld [email protected] Senior Consultant @ innoQ @goldstift Tammo van Lessen [email protected] Principal Consultant @ innoQ @taval

Slide 4

Slide 4 text

Architecture Consulting...

Slide 5

Slide 5 text

“We want to have a microservice architecture!”

Slide 6

Slide 6 text

“We want to have a microservice architecture!” — Every Customer, since 2015

Slide 7

Slide 7 text

When reviewing monolithic applications … © innoQ/Roman Stranghöner

Slide 8

Slide 8 text

…and taking a look into the black box… © innoQ/Roman Stranghöner

Slide 9

Slide 9 text

…you’ll likely find it consists of multiple Bounded Contexts. © innoQ/Roman Stranghöner

Slide 10

Slide 10 text

Architectural Decisions

Slide 11

Slide 11 text

Architectural Decisions > Domain Architecture

Slide 12

Slide 12 text

Architectural Decisions > Domain Architecture > Micro Architecture

Slide 13

Slide 13 text

Architectural Decisions > Domain Architecture > Macro Architecture > Micro Architecture

Slide 14

Slide 14 text

…so we show the different levels of decisions…

Slide 15

Slide 15 text

Domain Architecture -Which boxes? -Use Cases -Semantics & Purpose …so we show the different levels of decisions…

Slide 16

Slide 16 text

Domain Architecture -Which boxes? -Use Cases -Semantics & Purpose Macro Architecture -What’s in between? -Protocols, Deployment …so we show the different levels of decisions…

Slide 17

Slide 17 text

Domain Architecture -Which boxes? -Use Cases -Semantics & Purpose Macro Architecture -What’s in between? -Protocols, Deployment Micro Architecture -What’s inside? -Component internals …so we show the different levels of decisions…

Slide 18

Slide 18 text

If you cut a monolithic system along its very domains …

Slide 19

Slide 19 text

… and wrap every domain in a separate, replaceable web application …

Slide 20

Slide 20 text

… then that application can be build as a self-contained system (SCS).

Slide 21

Slide 21 text

http://scs-architecture.org/ more information on self-contained systems (SCS) can be found at

Slide 22

Slide 22 text

Isn't there more than that…

Slide 23

Slide 23 text

At a project meeting…

Slide 24

Slide 24 text

Did you think about the people   who make your architecture exist?

Slide 25

Slide 25 text

WHY do you actually WANT microservices?

Slide 26

Slide 26 text

WHY do you actually WANT microservices? Which business goals does it serve?

Slide 27

Slide 27 text

us vs. them

Slide 28

Slide 28 text

“Don’t care about this, it’s our business!” “Alarming is our concern, don’t bother about it!” “No need for a discussion, we always fix that during deployment.” “That’s part of the handover to operations.”

Slide 29

Slide 29 text

overcome “us vs. them”

Slide 30

Slide 30 text

overcome “us vs. them” > cross-functional != cross-department

Slide 31

Slide 31 text

overcome “us vs. them” > cross-functional != cross-department > have one manager to decide on a team’s targets

Slide 32

Slide 32 text

overcome “us vs. them” > cross-functional != cross-department > have one manager to decide on a team’s targets > don’t neglect team-building

Slide 33

Slide 33 text

overcome “us vs. them” > cross-functional != cross-department > have one manager to decide on a team’s targets > don’t neglect team-building > trust is not optional

Slide 34

Slide 34 text

well-known pros are subjective

Slide 35

Slide 35 text

“Operating a monolith is easier!”

Slide 36

Slide 36 text

Of course it’s easier…

Slide 37

Slide 37 text

It’s always easier for you… …if the complexity is on someone else’s desk.

Slide 38

Slide 38 text

“Operational costs are increased!”

Slide 39

Slide 39 text

Monolith

Slide 40

Slide 40 text

Microservices?

Slide 41

Slide 41 text

Microservices? smaller components!

Slide 42

Slide 42 text

Microservices? smaller components! • easier to test • quicker to automate • faster roundtrips

Slide 43

Slide 43 text

“Separating teams duplicates work!”

Slide 44

Slide 44 text

The manageable, domain specific scope enables the development, operation and maintenance of an SCS by an autonomous team. Team 1 Team 2 Team 3

Slide 45

Slide 45 text

share ideas share concepts don’t share functional code Team 1 Team 2 Team 3

Slide 46

Slide 46 text

Conway’s Law “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.” – M.E. Conway Organization ˠ Architecture

Slide 47

Slide 47 text

Golden Rule: Nurture good communication.  Hamper bad communication.

Slide 48

Slide 48 text

“Deployments cannot be faster,   we have an established process!”

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

What this taught us

Slide 53

Slide 53 text

What this taught us > enable fast feedback for your team

Slide 54

Slide 54 text

What this taught us > enable fast feedback for your team > automate what’s next to you first

Slide 55

Slide 55 text

What this taught us > enable fast feedback for your team > automate what’s next to you first > do your homework before you teach others

Slide 56

Slide 56 text

What this taught us > enable fast feedback for your team > automate what’s next to you first > do your homework before you teach others > other people will notice the benefits

Slide 57

Slide 57 text

What this taught us > enable fast feedback for your team > automate what’s next to you first > do your homework before you teach others > other people will notice the benefits > complex processes can be adopted, divide them and take one step at a time

Slide 58

Slide 58 text

“pets vs. cattle”

Slide 59

Slide 59 text

https://www.ﬂickr.com/photos/cornelii/531691572 https://www.ﬂickr.com/photos/cornelii/531691572

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

https://www.ﬂickr.com/photos/cornelii/531691572 https://www.ﬂickr.com/photos/cornelii/531691572 • pets • have names & take time • individual care • you usually only have 1 to 3 of them • when they get sick -> take them to the doctor • cattle • you probably know how many you have • maybe their number • they mostly care for themselves • new ones are born, old ones die • if they get seriously sick -> kill them

Slide 63

Slide 63 text

Summarized: Change Perspectives!

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

http://izismile.com/2013/01/22/buyers_beware_its_a_matter_of_perspective_3_pics.html

Slide 67

Slide 67 text

A company which embraced and evolved

Slide 68

Slide 68 text

http://projectcartoon.com/cartoon/1

Slide 69

Slide 69 text

Modernisation Strategies

Slide 70

Slide 70 text

Big Bang

Slide 71

Slide 71 text

Big Bang not WANTED!

Slide 72

Slide 72 text

Service 2 Frontend Switch Monolith Module 1 Service 3 Service 4 Customer Request Service 5 Reverse Proxy

Slide 73

Slide 73 text

Change via Copy

Slide 74

Slide 74 text

Change via Extraction

Slide 75

Slide 75 text

Strangulate Bad Parts

Slide 76

Slide 76 text

http://aim42.org/ more information on software modernisation   can be found at #javaland #innoQ

Slide 77

Slide 77 text

conclusion

Slide 78

Slide 78 text

Summary

Slide 79

Slide 79 text

Summary > distributed systems are hard - organizational impact, too

Slide 80

Slide 80 text

Summary > distributed systems are hard - organizational impact, too > don't forget: there's always at least one other perspective

Slide 81

Slide 81 text

Summary > distributed systems are hard - organizational impact, too > don't forget: there's always at least one other perspective > Don’t overwhelm people, change one thing at a time

Slide 82

Slide 82 text

Summary > distributed systems are hard - organizational impact, too > don't forget: there's always at least one other perspective > Don’t overwhelm people, change one thing at a time > not everyone who wants microservices is immediately capable to establish them

Slide 83

Slide 83 text

Tammo van Lessen | @taval [email protected] Alexander Heusingfeld | @goldstift [email protected] Thank you! Questions? Comments? innoQ Deutschland GmbH Krischerstr. 100 D-40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 D-10999 Berlin Germany Phone: +49 2173 3366-0 Ludwigstr. 180 E D-63067 Offenbach Germany Phone: +49 2173 3366-0 Kreuzstr. 16 D-80331 München Germany Telefon +49 2173 3366-0 https://www.innoq.com/en/talks/