Tweet
Tweet

Slide 1

Slide 1 text

Eberhard Wolff Fellow INNOQ @ewolff http://ewolff.com

Slide 2

Slide 2 text

http://continuous-delivery-buch.de/ http://continuous-delivery-book.com/

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

http://microservices-book.com/ primer.html http://microservices-buch.de/ ueberblick.html FREE!!!!

Slide 5

Slide 5 text

http://microservices-praxisbuch.de/rezepte.html FREE!!!!

Slide 6

Slide 6 text

http://microservices-praxisbuch.de/

Slide 7

Slide 7 text

What are Microservices?

Slide 8

Slide 8 text

What are Microservices? Modules

Slide 9

Slide 9 text

What are Microservices? Separately deployable Modules

Slide 10

Slide 10 text

What are Microservices? Separately deployable Modules =Container

Slide 11

Slide 11 text

What are Microservices? • Modules, so: • Using microservices is a decision per system • Microservice are just one way to do modules. • Old rules apply e.g. low coupling & high cohesion • (There is more: http://isa-principles.org )

Slide 12

Slide 12 text

What is a Great Microservice? • Feature implemented in one microservice. • Feature put into production with one deployment. • A separate part of the domain!

Slide 13

Slide 13 text

Most important part of doing microservice: Getting the split right!!!

Slide 14

Slide 14 text

Domain-driven Design’s Bounded Context provides a specialized domain model for some use cases.

Slide 15

Slide 15 text

Order Invoice Delivery Items Rebates Credit cards Taxes Parcel service Returns

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Events • Allow communication between Bounded Contexts • Model an event in the business domain • Something happened (past) • Immutable • No delete • Instead: cancel event

Slide 18

Slide 18 text

Events • Easily extensible systems • Traditional benefits of events

Slide 19

Slide 19 text

Order Invoice Delivery Asynchronous Communication ???

Slide 20

Slide 20 text

What is in the Event?

Slide 21

Slide 21 text

New Order Item prices Billing address Item sizes Item weights Delivery address ??? Invoice Delivery ??? • Lots of data • Which Bounded Context uses what? • Changes can impact all modules • DDD: Published Language • THE order model? • Contradicts Bounded Context?

Slide 22

Slide 22 text

Delivery New Order Invoice New Order Item prices Billing address Item sizes Item weights Delivery address • Specialized “events” • Independent evolution • Easy to figure out which Bounded Context uses what • Extensibility need new events • DDD: Customer / Supplier ??? New Order ???

Slide 23

Slide 23 text

New Order Order ID • Just an ID • Provide additional specialized API for data for each consumer • Compromise between extensibility and specialized events

Slide 24

Slide 24 text

Events: Conclusion • What data should be included? • Extensibility is not so easy • Probably do not include all data • Prefer specialized events and just IDs

Slide 25

Slide 25 text

Events: Conclusion • Best option for communication between Bounded Contexts • …and “correct” from a domain point. • Implicit replication

Slide 26

Slide 26 text

Inconsistencies!!!

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

What Kind of Inconsistencies? • One system for invoices • One for delivery • One for orders • One source of truth for each information. • No “invoice might be there or not”

Slide 29

Slide 29 text

Inconsistencies • Either delivery without invoice • …or invoice without delivery. • Will eventually be solved. • Delays are not unheard of. • What is the alternative? • Centralized complex database? • Really??

Slide 30

Slide 30 text

Inconsistencies • Ask: What are the consequences if it takes 0.1s / 1s / 1min / 1h / 1d for the new data to appear? • “Invoice has to be there in <1min!!!!!”

Slide 31

Slide 31 text

Cancel Order 42 New Order 23 New Order 42 There is no order 42! Uuups Order 42 might be delivered and invoiced Here is a new order! …even though it was cancelled. Order of events matters!

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

Event Sourcing • Event queue provides events • Event handlers react to events • Event handler might create a snapshot • Event store stores all events

Slide 34

Slide 34 text

Event Queue Event Event Event Event Handler Event Handler Event Store Snapshot

Slide 35

Slide 35 text

Cancel Order 42 • Note problem • Middleware might notify about Out-of-order • Discard snapshot • …rollback to old snapshot • …or complete rebuild • Order events correctly • Replay New Order 23 New Order 42

Slide 36

Slide 36 text

Cancel Order 42 • Not trivial • Has an invoice / delivery been created for order 42? • ”New Order” event not enough • Need to read potentially very old events • …with old schema • …and missing information New Order 23 New Order 42

Slide 37

Slide 37 text

Other Benefits • Radical: State becomes just a snapshot. • Migrate database schemata easier • Replay • Fully History • Time-based queries • Auditing • Event processing

Slide 38

Slide 38 text

Event Queue Event Event Event Event Handler Event Handler Event Store Snapshot

Slide 39

Slide 39 text

Event Store • Must Store all events • …for replay etc • Some event queues store old events. • E.g. Kafka or Atom • Why implement locally?

Slide 40

Slide 40 text

Global Event Store • Event must include more than just the ID. • Microservices need to handle (very?) old events. • Truly global event store = Published Language • …with its challenges.

Slide 41

Slide 41 text

Event Sourcing is Pattern for State Management.

Slide 42

Slide 42 text

State Management • Responsibility of the microservices • Might be changed • Might be different for each microservice • Event Sourcing should be a local decision

Slide 43

Slide 43 text

Invoice • Order needs to be paid • Invoice is generated • Afterwards invoices are only read • Invoices must be immutable • Catalog has a lot more reads than writes • Scale reads independent from writes?

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Commands vs Events • Command: Change that data! • Event: Something has happened • Component decides if data should be changed

Slide 47

Slide 47 text

CQRS • Command store just stores commands • Command handler change data • Query Handler read data • Different specialized data models • …or even Bounded Contexts possible • More independent modules

Slide 48

Slide 48 text

Command Queue Command Command Command Command Handler Query Handler Command Store Database Read Invoice Payment Read Replica? Create Invoice!

Slide 49

Slide 49 text

CQRS • Queries and commands separated • But: shared database model • Quite strong coupling • No independent evolution • Same technology

Slide 50

Slide 50 text

Command Queue Command Command Command Command Handler Query Handler Command Store Database Read Invoice Payment Read Replica? Create Invoice!

Slide 51

Slide 51 text

Command Queue Command Command Command Command Handler Query Handler Command Store Read Invoice Payment Snapshot Event Sourcing Create Invoice! Database?

Slide 52

Slide 52 text

CQRS & Event Sourcing • Full separation of commands and queries • Might choose different technologies • Separate deployment possible • …including data models • Truly separated models / Bounded Context

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

Conclusion • Most important: Getting the split right! • Bounded Context • …communicate via events • Inconsistencies can be dealt with • What is in the event? • Event Sourcing: A pattern for state management. • CQRS: Split commands and queries • Do not overuse Event Sourcing and CQRS

Slide 55

Slide 55 text

• EMail oop2018@ewolff.com to get: • Slides • + Microservices Primer • + Microservices Rezepte • + Sample Microservices Praxisbuch • + Sample Microservices Buch / Book • + Sample of Continuous Delivery Buch / Book • Powered by Amazon Lambda & Microservices