How to Split Your System into Microservices

Slide 1

Slide 1 text

How to Split Your System into Microservices Eberhard Wolff @ewolff Fellow

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

No content

Slide 6

Slide 6 text

Microservices: Definition > No consistent definition > Microservices are modules > Independent deployment units > E.g. Docker container > Microservice owned by one team

Slide 7

Slide 7 text

Microservices: Definition Server / Container Server / Container Micro Service Micro Service

Slide 8

Slide 8 text

Microservices aim for decoupling

Slide 9

Slide 9 text

Why is the Split so Important? > Microservices implement a part of the logic > Allow isolated development of features > …and independent teams > If split is wrong, you won’t achieve goals. > …and there is just more complexity. > But there are even more goals!

Slide 10

Slide 10 text

Why Microservices? Strong Modularization Scaling Agile Sustainable development Replaceable Services Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Small teams develop and deploy independently Add services – not code Small Services Failure limited to single Microservice

Slide 11

Slide 11 text

Why Microservices? Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology

Slide 12

Slide 12 text

There are many reasons for microservices.

Slide 13

Slide 13 text

There are many scenarios for microservices.

Slide 14

Slide 14 text

Scenario and reason influence the split.

Slide 15

Slide 15 text

Bounded Context

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

UBIQUITOUS LANGUAGE VALUE OBJECT ENTITY

Slide 18

Slide 18 text

Address VALUE OBJECT ENTITY or

Slide 19

Slide 19 text

529 pages

Slide 20

Slide 20 text

529 pages Part IV

Slide 21

Slide 21 text

529 pages Part IV Chapter 14

Slide 22

Slide 22 text

A domain model is only useful in a BOUNDED CONTEXT.

Slide 23

Slide 23 text

There is no universal data model in a large system.

Slide 24

Slide 24 text

Address for a customer VALUE OBJECT ENTITY or

Slide 25

Slide 25 text

Address for calculating the drones’ routes VALUE OBJECT ENTITY or

Slide 26

Slide 26 text

Microservice = Bounded Context

Slide 27

Slide 27 text

Create some Bounded Contexts! Sir, yes, sir!

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

Why would you build a universal data model if that is neither possible nor useful??

Slide 32

Slide 32 text

Bounded Context: Challenge > Not a way to design a great architecture > …but consequence of good domain architecture > i.e. clearly separated domains will lead to separated BOUNDED CONTEXTS > …containing logic and data > How can you find BOUNDED CONTEXTS?

Slide 33

Slide 33 text

Bounded Context: Challenge > Coarse-grained > Ideal: implement a functionality in one unit > Ideal: Independence > Might have relationships > …limiting independence

Slide 34

Slide 34 text

Divide by Use Cases > Microservice should implement a use case > …ideally without calling other microservices > Divide use cases among microservices > …then decide about the BOUNDED CONTEXT

Slide 35

Slide 35 text

Browsing Registration Creating Microservices User Registration Search Products by Keywords Browse Products by Category Checkout Payment Define Shipment Update Profile Basic customer data Preferences Recommendations Billing address Payment information All these services have data about the customer!!

Slide 36

Slide 36 text

Bounded Context Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology

Slide 37

Slide 37 text

What about other scenarios??

Slide 38

Slide 38 text

Existing Architecture Product Customer Warehouse Product Service Customer Service Warehouse Service iOS Android PoS Web

Slide 39

Slide 39 text

Let’s create some Bounded Contexts!

Slide 40

Slide 40 text

Existing Architecture Product Customer Warehouse Product Service Customer Service Warehouse Service iOS Android PoS Web Browsing

Slide 41

Slide 41 text

Bounded Contexts > Browsing distributed in many artifacts > Change to Browsing might influence all of them > …or not > BOUNDED CONTEXTS would be desirable

Slide 42

Slide 42 text

Migrate to Bounded Context Product Customer Warehouse Product Service Customer Service Warehouse Service iOS Android PoS Web Browsing Browsing

Slide 43

Slide 43 text

Introducing Bounded Contexts > …would change the architecture completely > …might be very hard > …and risky > Is it worth it? > Is it even doable? > Might also change the organization

Slide 44

Slide 44 text

Add services Product Customer Warehouse Product Service Customer Service Warehouse Service iOS Android PoS Web

Slide 45

Slide 45 text

Add services Product Customer Warehouse Product Service Customer Service Warehouse Service iOS Android PoS Web News- letter Web

Slide 46

Slide 46 text

Add Service > Might replace the old system stepwise > Immediate benefits > Low risk > Major reason for microservices

Slide 47

Slide 47 text

Cut existing services Product Customer Warehouse Product Service Customer Service Warehouse Service iOS Android PoS Web

Slide 48

Slide 48 text

Existing Architecture Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology

Slide 49

Slide 49 text

Existing Architecture > ...has an impact on the target architecture > What good is an architecture you cannot migrate into? > Might overrule everything else > Even BOUNDED CONTEXT

Slide 50

Slide 50 text

Browsing Registration External Systems User Registration Search Products by Keywords Browse Products by Category Checkout Payment Define Shipment Update Profile Browse Products by Category Payment Provider Logistic Partner

Slide 51

Slide 51 text

Browsing Registration External Systems User Registration Search Products by Keywords Browse Products by Category Checkout Update Profile Browse Products by Category Payment Provider Logistic Partner Payment Shipping

Slide 52

Slide 52 text

External Systems > Limit integration for each external system to one Microservice > External system might belong to a domain > …or BOUNDED CONTEXT > ...or not > Simplifies integration > Easier to achieve robustness

Slide 53

Slide 53 text

External Systems Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology

Slide 54

Slide 54 text

We expect a lot more registrations!

Slide 55

Slide 55 text

Browsing Registration External Systems User Registration Search Products by Keywords Browse Products by Category Checkout Payment Define Shipment Update Profile Browse Products by Category

Slide 56

Slide 56 text

Browsing Registration External Systems Search Products by Keywords Browse Products by Category Checkout Payment Define Shipment Browse Products by Category Regis- tration Update Profile

Slide 57

Slide 57 text

Technical Reasons > Independent scalability is just one technical reason > There are many more > Might be OK to share database in this scenario > Might even split read and write

Slide 58

Slide 58 text

CQRS > Command – Query Responsibility Segregation > Commands change data > Query provide data > Implement in separate microservices

Slide 59

Slide 59 text

Command Queue Command Command Command Command Handler Query Handler Command Store Database Read Replica

Slide 60

Slide 60 text

Technical Reasons Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology

Slide 61

Slide 61 text

Registration Requirements Browsing Checkout Marketing Sales Fulfillment Finance

Slide 62

Slide 62 text

Requirements > One microservice should implement one stream of requirements > Otherwise: coordinate priorities > …and therefore less independence

Slide 63

Slide 63 text

Registration Requirements Browsing Payment Marketing Sales Fulfillment Finance Shipping

Slide 64

Slide 64 text

Requirements Scaling Agile Sustainable development Continuous Delivery Free choice of technology Handle Legacy efficient Independent Scaling Robustness Organization Deployment Units Technology

Slide 65

Slide 65 text

Conclusion

Slide 66

Slide 66 text

Microservices = Bounded Context

Slide 67

Slide 67 text

Split Bounded Context Migration External Systems Technical Reasons Require- ments

Slide 68

Slide 68 text

EMail slideswjax2016@ewolff.com to get: Slides + Microservices Primer + Sample Microservices Book + Sample of Continuous Delivery Book Powered by Amazon Lambda & Microservices