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

4.
@theburningmonk theburningmonk.com

5.
@theburningmonk theburningmonk.com

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 first 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?”

20.
@theburningmonk theburningmonk.com

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
find your Pioneers and Settlers
create a success story first
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

38.
@theburningmonk theburningmonk.com

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

41.
@theburningmonk theburningmonk.com

42.
@theburningmonk theburningmonk.com

43.
@theburningmonk theburningmonk.com

44.
@theburningmonk theburningmonk.com

45.
@theburningmonk theburningmonk.com

46.
@theburningmonk theburningmonk.com

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

52.
@theburningmonk theburningmonk.com

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

58.
@theburningmonk theburningmonk.com

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

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

61.
@theburningmonk theburningmonk.com

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

63.
@theburningmonk theburningmonk.com

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

66.
@theburningmonk theburningmonk.com

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

76.
@theburningmonk theburningmonk.com

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
find related
functions by prefix

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)

92.
@theburningmonk theburningmonk.com

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

100.
@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

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

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

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

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

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

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
configured correctly?
are we assuming the
correct schema?
LambdaAPI Gateway DynamoDB
is Lambda proxy
configured 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
misconfigured 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

142.
@theburningmonk theburningmonk.com

143.
@theburningmonk theburningmonk.com
use queues to amortize traffic 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

147.
@theburningmonk theburningmonk.com

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

149.
@theburningmonk theburningmonk.com

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