Migrating existing monolith to serverless in 8 steps

1. Refactoring a monolith to serverless in 8 steps Yan Cui @theburningmonk

2. @theburningmonk theburningmonk.com

3. @theburningmonk theburningmonk.com FASTER CH€AP€R SCALABLE RESILIENT SECURE

6. @theburningmonk theburningmonk.com **** me, that’s pretty far..

7. @theburningmonk theburningmonk.com 6 months, 6 devs

8. @theburningmonk theburningmonk.com 95% cost saving compared to existing EC2-based solution

9. @theburningmonk theburningmonk.com velocity went from months to days

10. Yan Cui http://theburningmonk.com @theburningmonk AWS user for 10 years

11. http://bit.ly/yubl-serverless

12. Yan Cui http://theburningmonk.com @theburningmonk Developer Advocate @

13. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant advisetraining delivery

14. https://theburningmonk.com/courses

15. lambdabestpractice.com

16. @theburningmonk theburningmonk.com you can do it too, but you have to ﬁrst create the conditions where success is allowed to happen

17. Step 1. Reverse Conway’s Maneuver

18. @theburningmonk theburningmonk.com “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Conway’s Law

19. “we’re doing serverless, but why aren’t thing going faster?”

21. @theburningmonk theburningmonk.com centralised team Team A Team B Team C Team D …

22. @theburningmonk theburningmonk.com centralised team Team A Team B Team C Team D … bottoleneck

23. @theburningmonk theburningmonk.com “but the developers don’t understand AWS and how our infrastructure is set up”

24. @theburningmonk theburningmonk.com “but the developers don’t understand AWS and how our infrastructure is set up” let’s solve this problem instead!

25. @theburningmonk theburningmonk.com the best way to improve system reliability is to put its developers on the on-call rota

26. @theburningmonk theburningmonk.com Reverse Conway’s Maneuver “sturcture your organization to match the software you intent to produce”

27. @theburningmonk theburningmonk.com “we want software that are made up of small, loosely-coupled components, that can be deployed and scaled indepedently, and can fail indepedently affecting each other”

28. @theburningmonk theburningmonk.com small, autonomous teams that can innovate and move quickly, and fail in isolation

29. @theburningmonk theburningmonk.com trust, but verify

30. @theburningmonk theburningmonk.com provide guidance and context over centralized control & gatekeeping

31. @theburningmonk theburningmonk.com align teams with problems, not solutions

32. @theburningmonk theburningmonk.com don’t let everyone start all at once!

33. @theburningmonk theburningmonk.com ﬁnd your Pioneers and Settlers create a success story ﬁrst http://bit.ly/398gv5e

34. @theburningmonk theburningmonk.com accept that your teams need to skill up

35. @theburningmonk theburningmonk.com https://www.jeremydaly.com/newsletter

36. Step 2. Identify service boundaries

37. be a toe-dipper

39. @theburningmonk theburningmonk.com start with low-risk, non-critical business processes

40. @theburningmonk theburningmonk.com incrementally migrate the legacy system by gradually replacing pieces of functionalities to the new system Strangler Pattern

47. @theburningmonk theburningmonk.com Services… are autonomous

48. @theburningmonk theburningmonk.com Services… are autonomous have clear boundaries

49. @theburningmonk theburningmonk.com Services… are autonomous have clear boundaries own their data

50. @theburningmonk theburningmonk.com Services… are autonomous have clear boundaries own their data are loosely coupled through shared contracts

51. @theburningmonk theburningmonk.com beware the “entity service” anti-pattern

53. Step 3. Organize your codebase

54. @theburningmonk theburningmonk.com github repo github repo github repo github repo github repo github repo github repo github repo github repo

55. @theburningmonk theburningmonk.com github repo github repo github repo github repo github repo github repo github repo github repo github repo

56. @theburningmonk theburningmonk.com monorepo

57. @theburningmonk theburningmonk.com github repo

59. @theburningmonk theburningmonk.com share code through symlinks + webpack

60. @theburningmonk theburningmonk.com one CI/CD that deploys them all (in parallel)

62. @theburningmonk theburningmonk.com good for small teams/startups

64. @theburningmonk theburningmonk.com one repo per service

65. @theburningmonk theburningmonk.com github repo github repo github repo github repo user-api timeline-api relationship-api search-api

67. @theburningmonk theburningmonk.com one CI/CD pipeline per service

68. @theburningmonk theburningmonk.com shared infrastructure (VPCs, etc.) in separate repo

69. @theburningmonk theburningmonk.com ref shared infra via CFN output, SSM param, etc.

70. @theburningmonk theburningmonk.com share code through shared libs (NPM, maven, etc.)

71. @theburningmonk theburningmonk.com shared code vs shared service

72. @theburningmonk theburningmonk.com https://theburningmonk.com/2018/02/aws-lambda-how-best-to-manage-shared-code-and-shared-infrastructure/

73. Step 4. Pick your tools

74. @theburningmonk theburningmonk.com deployment framework, CI, monitoring, etc.

75. @theburningmonk theburningmonk.com there’s NO “best tool” for X pick the best one for YOU and stick to it

77. @theburningmonk theburningmonk.com https://lumigo.io/blog/comparison-of-lambda-deployment-frameworks

78. @theburningmonk theburningmonk.com don’t write your own deployment framework

79. @theburningmonk theburningmonk.com standardization maximizes instituational knowledge sharing

80. Step 5. Keep functions simple

81. @theburningmonk theburningmonk.com what got you here won’t get you there

82. @theburningmonk theburningmonk.com if (path == “/user” && method == “GET”) { return getUser(…); } else if (path == “/user” && method == “DELETE”) { return deleteUser(…); } else if (path == “/user” && method == “POST”) { return createUser(…); } else if …. Monolithic Functions

83. @theburningmonk theburningmonk.com GET /user POST /user DELETE /user Single-Purposed Functions

84. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user

85. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user ﬁnd related functions by preﬁx

86. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user discoverability (without having to dig into the code)

87. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user what does it do?

88. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user dynamodb:GetItem dynamodb:PutItem dynamodb:DeleteItem

89. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user dynamodb:GetItem dynamodb:PutItem dynamodb:DeleteItem no least privilege…

90. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user require(x) require(y) require(z)

91. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user require(x) require(y) require(z)

93. @theburningmonk theburningmonk.com more dependecies equals slower cold start

94. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user require(x) require(y) require(z) worse cold start performance

95. @theburningmonk theburningmonk.com keep functions simple, and single-purposed

96. Step 6. Migrate to new service

97. @theburningmonk theburningmonk.com Monolith DB Feature A Feature C Feature B Feature D Feature E Feature F Monolith

98. @theburningmonk theburningmonk.com Monolith DB Feature A Feature C Feature B Feature D Feature E Feature F Monolith

99. @theburningmonk theburningmonk.com Monolith DB Monolith Feature A Feature C Feature B Feature D Feature EFeature F Service DB

101. @theburningmonk theburningmonk.com Monolith DB Monolith Feature A Feature C Feature B Feature D Feature EFeature F Service DB requires challenging & risky coordinated update!

102. @theburningmonk theburningmonk.com Monolith DB Monolith Feature A Feature C Feature B Feature D Feature EFeature F Service

103. @theburningmonk theburningmonk.com Monolith DB Monolith Feature A Feature C Feature B Feature D Feature EFeature F Service migrate the least critical component first

107. @theburningmonk theburningmonk.com Monolith DB Monolith Feature A Feature C Feature B Feature D Feature EFeature F Service DB if your system can tolerate a small downtime, then do the data migration with a downtime!

108. @theburningmonk theburningmonk.com Monolith DB Monolith Feature A Feature C Feature B Feature D Feature EFeature F Service DB if not… consider this approach

109. @theburningmonk theburningmonk.com Monolith DB Monolith Feature A Feature C Feature B Feature D Feature EFeature F Service DB write read treat new DB as a read-through/ write-through cache

110. @theburningmonk theburningmonk.com Monolith DB Monolith Feature A Feature C Feature B Feature D Feature EFeature F Service DB write read migration also run one-off migration job in the background

112. context is king

113. start up

114. STABILITY

115. @theburningmonk theburningmonk.com maintain API compatibility (all versioning schema sucks…)

116. @theburningmonk theburningmonk.com prefer synchronizing data over synchronous API calls

117. @theburningmonk theburningmonk.com System A System B System C System D User User System EUser structural weakness

118. @theburningmonk theburningmonk.com System A System B System C System D User User System EUser cascade failures cascade failures cascade failures

119. @theburningmonk theburningmonk.com System C System DUser upsert

120. @theburningmonk theburningmonk.com be mindful of GDPR! avoid synchronousing PII data

121. Step 7. Rethink testing

122. @theburningmonk theburningmonk.com acceptance integration unit no. of tests in the monolith…

123. @theburningmonk theburningmonk.com most Lambda functions are simple and have a single purpose, the risk of shipping broken software has largely shifted to how they integrate with other services

124. @theburningmonk theburningmonk.com acceptance integration unit won’t catch many integration problems

125. Paul Johnston The serverless approach to testing is different and may actually be easier. http://bit.ly/2t5viwK

126. LambdaAPI Gateway DynamoDB

127. LambdaAPI Gateway DynamoDB Unit Tests

128. LambdaAPI Gateway DynamoDB Unit Tests Mock/Stub

129. is our request correct? is the request mapping set up correctly?is the API resources conﬁgured correctly? are we assuming the correct schema? LambdaAPI Gateway DynamoDB is Lambda proxy conﬁgured correctly? is IAM policy set up correctly? is the table created? what unit tests will not tell you…

130. @theburningmonk theburningmonk.com a passing test is not a guarantee that something works

131. @theburningmonk theburningmonk.com optimize for working software, not your feedback loop (feedback loop is an important ingredient, but not the goal!)

132. @theburningmonk theburningmonk.com avoid local simulation, they’re more work than is worth it, and hides common failure modes such as misconﬁgured permissions and resource policies pro tip #1

133. @theburningmonk theburningmonk.com prefer high-level functional tests pro tip #2

134. @theburningmonk theburningmonk.com integration tests exercise system’s Integration with its external dependencies my code

135. @theburningmonk theburningmonk.com acceptance tests exercise system End-to-End from the outside my code

136. @theburningmonk theburningmonk.com only use mocks for AWS services to simulate hard-to-create failure cases pro tip #3

137. @theburningmonk theburningmonk.com but always mock your own APIs during integration testing - they’re not as stable as AWS services and you know it! pro tip #4

138. @theburningmonk theburningmonk.com use temporary stacks to run e2e tests pro tip #5 https://theburningmonk.com/2019/09/why-you-should-use-temporary-stacks-when-you-do-serverless

139. @theburningmonk theburningmonk.com https://theburningmonk.com/2019/09/how-to-include-sns-and-kinesis-in-your-e2e-tests How to include SNS and Kinesis in your e2e tests

140. Step 8. Resilience as a service

141. @theburningmonk theburningmonk.com observability, observability, observability

143. @theburningmonk theburningmonk.com use queues to amortize trafﬁc spikes between services

144. @theburningmonk theburningmonk.com use sagas to manage distributed transactions

145. @theburningmonk theburningmonk.com use circuit breakers to prevent cascade failures

146. @theburningmonk theburningmonk.com use bulkheads to isolate blast radius

148. @theburningmonk theburningmonk.com go multi-region, active-active

150. @theburningmonk theburningmonk.com #1 apply Reverse Conway’s Maneuver #2 identify service boundaries #3 organize your codebase #4 pick your tools #5 keep functions simple #6 migrate to new service (gracefully) #7 rethink testing #8 resilience as a service

151. https://theburningmonk.com/hire-me AdviseTraining Delivery “Fundamentally, Yan has improved our team by increasing our ability to derive value from AWS and Lambda in particular.” Nick Blair Tech Lead

152. senzo.io

153. @theburningmonk theburningmonk.com github.com/theburningmonk