Deconstructing a Monolith 1 / 105 Introduction I am Peter - - PowerPoint PPT Presentation

▶
deconstructing a monolith
SMART_READER_LITE
LIVE PREVIEW

Deconstructing a Monolith 1 / 105 Introduction I am Peter - - PowerPoint PPT Presentation

Oct 14, 2023 260 likes •1.33k views

Deconstructing a Monolith 1 / 105 Introduction I am Peter (@pjausovec) Software Engineer at Oracle Working on "cloud-native" stu Books: Cloud Native: Using Containers, Functions, and Data to Build Next-Gen Apps SharePoint

slide-1
SLIDE 1

Deconstructing a Monolith

1 / 105

slide-2
SLIDE 2

Introduction

I am Peter (@pjausovec) Software Engineer at Oracle Working on "cloud-native" stu Books: Cloud Native: Using Containers, Functions, and Data to Build Next-Gen Apps SharePoint Development VSTO For Dummies Courses: Kubernetes Course (https://startkubernetes.com) Istio Service Mesh Course (https://learnistio.com)

2 / 105

slide-3
SLIDE 3

Agenda

  • 1. What are Monoliths and Microservices?
  • 2. Migration Patterns

Strangler Pattern Branch by Abstraction Pattern Parallel Run Pattern

  • 3. Decomposing Databases

Database View Pattern Database Wrapping Service Pattern Database-as-a-Service Pattern Change Data Capture Aggregate Exposing Monolith Change Data Ownership Pattern

  • 4. Data Synchronization
  • 5. Transactions

3 / 105

slide-4
SLIDE 4

4 / 105

slide-5
SLIDE 5

5 / 105

slide-6
SLIDE 6

6 / 105

slide-7
SLIDE 7

7 / 105

slide-8
SLIDE 8

Monolith Challenges

Developers getting in each others way changing same piece of code delaying deployments Ownership

8 / 105

slide-9
SLIDE 9

Monolith Advantages

Simpler/single deployment Simpler inner loop/development also monitoring and E2E testing Code reuse

9 / 105

slide-10
SLIDE 10

Monolithic architecture is an option

10 / 105

slide-11
SLIDE 11

11 / 105

slide-12
SLIDE 12

Microservices Characteristics

Independently deployable Modeled around a business domain Own their own data

12 / 105

slide-13
SLIDE 13

What's the single biggest advantage of microservices?

a) Scaling (like Netix!) b) Use any tech/language c) Flexibility d) Simpler deployment

13 / 105

slide-14
SLIDE 14

FLEXIBILITY

14 / 105

slide-15
SLIDE 15

Microservice Challenges

Networking Distributed system, CAP theorem and all that It's not server-side only - What about the UIs? Urge to use the latest and greatest Culture change

15 / 105

slide-16
SLIDE 16

Recap

Monolithic deployment Monoliths can be a good choice Avoid distributed monoliths Microservices oer exibility A lot of network

16 / 105

slide-17
SLIDE 17

Planning a migration

17 / 105

slide-18
SLIDE 18

Microservices are not the goal

18 / 105

slide-19
SLIDE 19

"Would you tell me, please, which way I ought to go from here?" "That depends a good deal on where you want to get to" "I don't much care where" "Then it doesn't matter which way you go" ...

19 / 105

slide-20
SLIDE 20

Questions to ask

What are you hoping to achieve? Which alternatives did you consider? How do you know if migration worked?

20 / 105

slide-21
SLIDE 21

Reasons

Improve team autonomy Amazon's two-pizza team Spotify's product squads Reduce time to market Scale and robustness Scale the developers Embrace new tech

21 / 105

slide-22
SLIDE 22

Migration Patterns

22 / 105

slide-23
SLIDE 23

Strangler Pattern

23 / 105

slide-24
SLIDE 24

24 / 105

slide-25
SLIDE 25

Strangler Pattern

Used when doing system rewrites Both systems coexist Allows for incremental changes and pausing/stopping the migration

25 / 105

slide-26
SLIDE 26

Strangler Pattern

  • 1. Identify the functionality
  • 2. Move the functionality
  • 3. Redirect the calls

26 / 105

slide-27
SLIDE 27

27 / 105

slide-28
SLIDE 28

28 / 105

slide-29
SLIDE 29

29 / 105

slide-30
SLIDE 30

30 / 105

slide-31
SLIDE 31

31 / 105

slide-32
SLIDE 32

Branch by Abstraction Pattern

  • 1. Create the abstraction
  • 2. Use the abstraction (with existing implementation)
  • 3. Implement new service
  • 4. Switch the implementation
  • 5. Clean up

32 / 105

slide-33
SLIDE 33

33 / 105

slide-34
SLIDE 34

34 / 105

slide-35
SLIDE 35

35 / 105

slide-36
SLIDE 36

36 / 105

slide-37
SLIDE 37

37 / 105

slide-38
SLIDE 38

DEMO - Branch by Abstraction

38 / 105

slide-39
SLIDE 39

BREAK

39 / 105

slide-40
SLIDE 40

40 / 105

slide-41
SLIDE 41

41 / 105

slide-42
SLIDE 42

42 / 105

slide-43
SLIDE 43

43 / 105

slide-44
SLIDE 44

DEMO

Parallel Run/Mirroring with Service Mesh

44 / 105

slide-45
SLIDE 45

45 / 105

slide-46
SLIDE 46

46 / 105

slide-47
SLIDE 47

47 / 105

slide-48
SLIDE 48

Decomposing Databases

48 / 105

slide-49
SLIDE 49

Sharing a Database

You can't decide what's shared and what's hidden Goes against one of the microservices characteristics Data control - where is the logic?

49 / 105

slide-50
SLIDE 50

50 / 105

slide-51
SLIDE 51
  • 1. Database holds read-only/static data
  • 2. Database-as-a-Service Interface pattern

51 / 105

slide-52
SLIDE 52

52 / 105

slide-53
SLIDE 53

53 / 105

slide-54
SLIDE 54

54 / 105

slide-55
SLIDE 55

55 / 105

slide-56
SLIDE 56

56 / 105

slide-57
SLIDE 57

Wrapper vs. View

Not constrained to a view Ability to create more complex views API for writing requires changes to upstream services

57 / 105

slide-58
SLIDE 58

58 / 105

slide-59
SLIDE 59

Updating the R/O database

Change data capture Batch process Service events

59 / 105

slide-60
SLIDE 60

60 / 105

slide-61
SLIDE 61

Change Data Capture

Database triggers trigger behavior on data changes Transaction log pollers Batch delta copier

61 / 105

slide-62
SLIDE 62

Aggregate Exposing Monolith

62 / 105

slide-63
SLIDE 63

63 / 105

slide-64
SLIDE 64

64 / 105

slide-65
SLIDE 65

Change Data Ownership Pattern

65 / 105

slide-66
SLIDE 66

66 / 105

slide-67
SLIDE 67

Data Sychronization

67 / 105

slide-68
SLIDE 68

68 / 105

slide-69
SLIDE 69

What degree of consistency we need?

  • 1. Keep data in one place
  • 2. Batch copy all the data
  • 3. Sync via code

69 / 105

slide-70
SLIDE 70

70 / 105

slide-71
SLIDE 71

71 / 105

slide-72
SLIDE 72

Sync via Code

  • 1. Batch migrate the data to new database
  • 2. Deploy the new service (sync on write, read from old)
  • 3. Make the new database the source of truth
  • 4. Verify and remove old DB/schema and switching logic

72 / 105

slide-73
SLIDE 73

73 / 105

slide-74
SLIDE 74

74 / 105

slide-75
SLIDE 75

75 / 105

slide-76
SLIDE 76

76 / 105

slide-77
SLIDE 77

Splitting Databases

77 / 105

slide-78
SLIDE 78

78 / 105

slide-79
SLIDE 79

79 / 105

slide-80
SLIDE 80

What to split rst?

Database rst, code second Code rst, database second Both at once

80 / 105

slide-81
SLIDE 81

DEMO

81 / 105

slide-82
SLIDE 82

82 / 105

slide-83
SLIDE 83

83 / 105

slide-84
SLIDE 84

84 / 105

slide-85
SLIDE 85

BREAK

85 / 105

slide-86
SLIDE 86

Transactions

86 / 105

slide-87
SLIDE 87

ACID Transaction

Atomicity Consistency Isolation Durability

87 / 105

slide-88
SLIDE 88

88 / 105

slide-89
SLIDE 89

89 / 105

slide-90
SLIDE 90

Two-Phase Commit (2PC)

90 / 105

slide-91
SLIDE 91

Two-Phase Commit

Pros: Guarantees an atomic transaction Cons: Slow, depends on the transaction coordinator Database row locking can lead to deadlocks Doesn't scale

91 / 105

slide-92
SLIDE 92

Alternatives

  • 1. Don't split the data
  • 2. Sagas

92 / 105

slide-93
SLIDE 93

Sagas

Coordinate multiple state changes How to handle long-lived transactions? Break-up the LLT into sub-transactions Short-lived sub-transactions

93 / 105

slide-94
SLIDE 94

Sagas - Example

Online Purchase

  • 1. Check if in stock and reserve -> Warehouse service
  • 2. Charge the user for the product -> Payment service
  • 3. Send the notication -> Notication service
  • 4. Package and send the order -> Warehouse service

94 / 105

slide-95
SLIDE 95

Handling Failures

Backward recovery Rollback Compensating actions Forward recovery Continue and retry https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

95 / 105

slide-96
SLIDE 96

Compensating transaction

Online Purchase

  • 1. Check if in stock and reserve -> Warehouse service (OK)
  • 2. Charge the user for the product -> Payment service (OK)
  • 3. Send the notication -> Notication service (OK)
  • 4. Package and send the order -> Warehouse service (ERROR)

96 / 105

slide-97
SLIDE 97

Compensating transaction - Rollback

Online Purchase Rollback

  • 1. Check if in stock and reserve -> Warehouse service (OK)

(ROLLBACK) Remove the reservation

  • 2. Charge the user for the product -> Payment service (OK)

(ROLLBACK) Return the money back to the user

  • 3. Send the notication -> Notication service (OK)

(ROLLBACK) Notify use that the item is not available

  • 4. Package and send the order -> Warehouse service (ERROR)

97 / 105

slide-98
SLIDE 98

Implementing Sagas

Orchestrated Sagas rely on centralized coordination Choreographed Sagas no centralized coordination more complicated tracking

98 / 105

slide-99
SLIDE 99

99 / 105

slide-100
SLIDE 100

Orchestrated Sagas

Pros: Whole business process centralized orchestrator Easier to understand Cons Increased coupling (orchestrator knows about everything) Anemic services (logic in the orchestrator)

100 / 105

slide-101
SLIDE 101

101 / 105

slide-102
SLIDE 102

102 / 105

slide-103
SLIDE 103

Choreographed Sagas

Pros: Loose coupling (services react to events) No centralization Cons: Hard to know what's happening Hard to get the state of saga

103 / 105

slide-104
SLIDE 104

Resources

Books: Monolith to Microservices by Sam Newman Cloud Native: Using Containers, Functions, and Data by Scholl, Swanson, and Jausovec Blogs/Articles: SAGAS by Hector Garcia-Molina and Kenneth Salem Chris Richardson's Blog Martin Fowler's Blog

104 / 105

slide-105
SLIDE 105

Thank you

Contact @pjausovec peterj.dev Slides: https://slides.peterj.dev Demos: https://github.com/peterj/gids-deconstructing-monoliths

105 / 105