Slide 1

Slide 1 text

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

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-buch.de/ ueberblick.html http://microservices-book.com/ primer.html FREE!!!!

Slide 5

Slide 5 text

http://microservices-praxisbuch.de http://practical-microservices.com/

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

What are Microservices?

Slide 8

Slide 8 text

Independent Systems Architecture: ISA Creator: INNOQ | http://isa-principles.org

Slide 9

Slide 9 text

1 | Modules Creator: INNOQ | http://isa-principles.org

Slide 10

Slide 10 text

Creator: INNOQ | http://isa-principles.org >Reuse “Module” ideas: >High cohesion, low coupling, >Separation of concerns, >Single Responsibility … 1 | Modules

Slide 11

Slide 11 text

Creator: INNOQ | http://isa-principles.org >Modules provide interfaces >Access only through interface >Microservice must not use other microservices’ internals (e.g. database schemas). 1 | Modules

Slide 12

Slide 12 text

2 | Container Creator: INNOQ / http://isa-principles.org

Slide 13

Slide 13 text

Creator: INNOQ | http://isa-principles.org >Modules = containers (or VMs, processes …) 2 | Container

Slide 14

Slide 14 text

3 | Macro / Micro Architecture Creator: INNOQ / http://isa-principles.org

Slide 15

Slide 15 text

Creator: INNOQ | http://isa-principles.org >Decisions for all modules 3 | Macro / Micro Architecture Macro Architecture

Slide 16

Slide 16 text

Creator: INNOQ | http://isa-principles.org >All modules part of one system 3 | Macro / Miro Architecture Why Macro Architecture?

Slide 17

Slide 17 text

Creator: INNOQ | http://isa-principles.org >Decisions per module 3 | Macro / Miro Architecture Micro Architecture

Slide 18

Slide 18 text

4 | Integration Creator: INNOQ | http://isa-principles.org

Slide 19

Slide 19 text

Creator: INNOQ | http://isa-principles.org >Integrate modules to become a system Synchronous, asynchronous, or UI 4 | Integration

Slide 20

Slide 20 text

5 | Communication Creator: INNOQ | http://isa-principles.org

Slide 21

Slide 21 text

Creator: INNOQ | http://isa-principles.org >Technical implementation >REST, messaging … 5 | Communication

Slide 22

Slide 22 text

6 | Independent Continuous Delivery Pipeline Creator: INNOQ | http://isa-principles.org

Slide 23

Slide 23 text

Creator: INNOQ | http://isa-principles.org >Microservices can only be deployed independently … >... if pipelines are independent 6 | Independent Continuous Delivery Pipeline

Slide 24

Slide 24 text

7 | Standardize Operations Creator: INNOQ | http://isa-principles.org

Slide 25

Slide 25 text

Creator: INNOQ | http://isa-principles.org >Configuration, log analysis, tracing, monitoring, deployment >Reduce effort 7 | Standardize Operations

Slide 26

Slide 26 text

8 | Standards: Interface only Creator: INNOQ | http://isa-principles.org

Slide 27

Slide 27 text

Creator: INNOQ | http://isa-principles.org >Standardize e.g. configuration … or log interface >Do not standardize the library! 8 | Standards: Interface only

Slide 28

Slide 28 text

9 | Resilience Creator: INNOQ | http://isa-principles.org

Slide 29

Slide 29 text

Creator: INNOQ | http://isa-principles.org >Module still work … if other modules fail 9 | Resilience

Slide 30

Slide 30 text

Creator: INNOQ | http://isa-principles.org Independent System Architecture Modules Macro / Micro Architecture Independent Continuous Delivery Pipeline Resilience Integration Communication Standardized Operations Standards: Interface only Container

Slide 31

Slide 31 text

Why Microservices?

Slide 32

Slide 32 text

Organizational Benefits

Slide 33

Slide 33 text

Deployment Monolith Stories Technical Coordination Coordinating Releases

Slide 34

Slide 34 text

Microservice Stories Technical Coordination Stories Technical Coordination Stories Technical Coordination Order Billing Search Release Release Release

Slide 35

Slide 35 text

Inverse Conway Maneuver Architecture drives organization Cross-functional team (database, logic, UI) Team responsible for Bounded Context(s) With so much independence… ...teams can decide for themselves Self-organization

Slide 36

Slide 36 text

Take one huge project and make it several small projects…

Slide 37

Slide 37 text

Independent Technologies Independent Bounded Contexts Self- organization Organizational Benefits

Slide 38

Slide 38 text

Technological Benefits

Slide 39

Slide 39 text

Extreme Decoupling Originally: Changing a module does not influence other modules. i.e. independent development Now: Independent … – technical decision – scalability – deployment – crashes – security (e.g. firewall)

Slide 40

Slide 40 text

Clean Architecture

Slide 41

Slide 41 text

Developer

Slide 42

Slide 42 text

Developer

Slide 43

Slide 43 text

REST REST Architecture Firewalls

Slide 44

Slide 44 text

ECommerce System Order Catalog Billing Search

Slide 45

Slide 45 text

ECommerce System Order Catalog Billing Search

Slide 46

Slide 46 text

ECommerce System Catalog Billing Search

Slide 47

Slide 47 text

ECommerce System Order Catalog Billing Search

Slide 48

Slide 48 text

Replaceability Small components hard to mess up Each module can be replaced …small green field project ...different technology stack possible

Slide 49

Slide 49 text

Continuous Delivery

Slide 50

Slide 50 text

Microservices ECommerce System 3rd party systems Database

Slide 51

Slide 51 text

Microservices 3rd party systems Database Order Catalog Billing Search

Slide 52

Slide 52 text

Pipeline per Microservice

Slide 53

Slide 53 text

Build Pipeline for Microservices Smaller Easier to set up Less features (3rd party systems) Faster Feedback: Less tests

Slide 54

Slide 54 text

Decoupled Development Decoupled Scalability Decoupled Crashes Security Architecture Firewalls Replaceability Continuous Delivery Technological Benefits

Slide 55

Slide 55 text

Microservices: Challenges

Slide 56

Slide 56 text

Consistency Order Invoice Delivery What about order #42?

Slide 57

Slide 57 text

Consistency Order Invoice Delivery Order #42 is cancelled!

Slide 58

Slide 58 text

Inconsistencies are quite common also without microservices.

Slide 59

Slide 59 text

Customer Order Catalog Domino Effect

Slide 60

Slide 60 text

Customer Order Catalog Domino Effect

Slide 61

Slide 61 text

Customer Order Catalog Domino Effect

Slide 62

Slide 62 text

Customer Order Catalog Domino Effect

Slide 63

Slide 63 text

Build resilient microservices!

Slide 64

Slide 64 text

Refactoring Move code to a new service: Easy Move code from service to service Might be a port to a different language Hard

Slide 65

Slide 65 text

Global Refactoring Really hard: Global restructuring i.e. moving everything to a different place. …but that is always hard… ...and the result of a major screw-up. Do you want to optimize for this? Bounded Context are quite stable – probably no need for large refactoring.

Slide 66

Slide 66 text

Many New Technologies Microservices framework Service discovery Routing / API Gateway Continuous Delivery pipeline Docker Kubernetes ....

Slide 67

Slide 67 text

Challenges Consistency Fail safeness New Technologies

Slide 68

Slide 68 text

Microservices are an all or nothing approach.

Slide 69

Slide 69 text

Microservices are an all or nothing approach. Too Monolithic!

Slide 70

Slide 70 text

Which benefits are important? Which challenges acceptable?

Slide 71

Slide 71 text

Moving beyond Microservices: Rightsize the Architecture!

Slide 72

Slide 72 text

Layered

Slide 73

Slide 73 text

Layered iOS Android Web Order Product Delivery Invoice Customer Process Layer

Slide 74

Slide 74 text

Layered: Issues Changing a business process cause many changes …in frontends and many backends Lots of communication between teams and components

Slide 75

Slide 75 text

Independent Technologies + Independent Bounded Contexts - Self-organization - Organizational Benefits

Slide 76

Slide 76 text

Decoupled Development - Decoupled Scalability - Decoupled Crashes + Security + Architecture Firewalls + Replaceability + Continuous Delivery - Technological Benefits

Slide 77

Slide 77 text

Challenges Consistency + Fail safeness - New Technologies -

Slide 78

Slide 78 text

Layered More challenges, less benefits, same effort Microservices worsen problems caused by strong coupling. Microservices are just modules implemented differently. It the domain architecture, stupid!

Slide 79

Slide 79 text

Centralized DB

Slide 80

Slide 80 text

Billing Order Process CRM Order Order Order True Microservices

Slide 81

Slide 81 text

Shared Database Order Schema Billing Order Process CRM

Slide 82

Slide 82 text

Independent Technologies + Independent Bounded Contexts - Self- organization - Organizational Benefits

Slide 83

Slide 83 text

Decoupled Development - Decoupled Scalability + Decoupled Crashes + Security + Architecture Firewalls - Replaceability - Continuous Delivery - Technological Benefits

Slide 84

Slide 84 text

Challenges Consistency + Fail safeness - New Technologies - -

Slide 85

Slide 85 text

Centralized Database Bad idea Consistency can require lots of compromises Why all the effort for microservices if you allow such strong coupling?

Slide 86

Slide 86 text

Microservice+ Bounded Context

Slide 87

Slide 87 text

Order Shipping address Tracking # Items Item Categories Priority shipping Customs # Account # ... Credit card # Order #

Slide 88

Slide 88 text

My Domain Model is a mess!

Slide 89

Slide 89 text

Bounded Context Domain model is only valid for one context There is no universal data model! See all failed SOA attempts

Slide 90

Slide 90 text

Order Shipping address Tracking # Items Item Categories Priority shipping Customs # Account # ... Credit card # Order # Customs Order Recommen- dations Order Tracking Order Shipping address Tracking # Item Categories Priority shipping Customs # Payment Order Account # Credit card #

Slide 91

Slide 91 text

Self-contained Systems Search Invoice Logistics Checkout Web Web Web Web See http://scs-architecture.org

Slide 92

Slide 92 text

Independent Technologies + Independent Bounded Contexts + Self- organization + Organizational Benefits

Slide 93

Slide 93 text

Decoupled Development + Decoupled Scalability + Decoupled Crashes + Security + Architecture Firewalls + Replaceability + Continuous Delivery + Technological Benefits

Slide 94

Slide 94 text

Challenges Consistency ? Fail safeness ? New Technologies -

Slide 95

Slide 95 text

Microservice + Bounded Context Microservices as they should be. …even though Bounded Context is older than microservices

Slide 96

Slide 96 text

Deployment Monolith

Slide 97

Slide 97 text

Deployment Monolith Deploy everything as one module Might be structured …but most often Makes no sense to talk about benefits and challenges

Slide 98

Slide 98 text

Structured Monolith Modules with Maven Architecture Management OSGi WAR Might be Bounded Contexts

Slide 99

Slide 99 text

Build order / Architecture management Build order / Architecture management

Slide 100

Slide 100 text

Independent Technologies - Independent Bounded Contexts + Self- organization - Organizational Benefits

Slide 101

Slide 101 text

Decoupled Development + Decoupled Scalability - Decoupled Crashes - Security - Architecture Firewalls + Replaceability - Continuous Delivery - Technological Benefits

Slide 102

Slide 102 text

Challenges Consistency + Fail safeness ? New Technologies +

Slide 103

Slide 103 text

Structured Monolith Clean architecture with a lot less technical challenges. Limited deployment speed.

Slide 104

Slide 104 text

Conclusion

Slide 105

Slide 105 text

Conclusion Microservices: set of architecture decision …a new way for modularization Independent System Architecture Architecture is about trade-offs Architecture is different for each project Go beyond microservices & pick the best decisions!

Slide 106

Slide 106 text

Usually bad tradeoffs Centralized database Layered model

Slide 107

Slide 107 text

Usually good tradeoffs SCS, Bounded Context, Microlith Bounded Context in a deployment monolith Strongly separated modules in a deployment monolith …structured monolith

Slide 108

Slide 108 text

EMail [email protected] to get: Slides + Microservices Primer DE / EN + Microservices Recipes DE / EN + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices