Refactoring a Monolith to Serverless Architecture in 8 Steps

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

@theburningmonk theburningmonk.com

FASTER
CH€AP€R
SCALABLE
RESILIENT
SECURE

**** me, that’s pretty far..

6 months, 6 devs

95% cost saving compared to
existing EC2-based solution

velocity went from months to days

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

Yan Cui
@theburningmonk
Developer Advocate @

Yan Cui
@theburningmonk
Independent Consultant
advisetraining delivery

https://theburningmonk.com/courses

you can do it too, but you have to ﬁrst create the
conditions where success is allowed to happen

Step 1.
Reverse Conway’s Maneuver

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

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

centralised team
Team A Team B Team C Team D …

centralised team
Team A Team B Team C Team D …
bottoleneck

“but the developers don’t understand AWS and how
our infrastructure is set up”

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

the best way to improve system reliability is to put its
developers on the on-call rota

Reverse Conway’s Maneuver
“sturcture your organization to match the software
you intent to produce”

“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”

small, autonomous teams that can innovate
and move quickly, and fail in isolation

trust, but verify

provide guidance and context over
centralized control & gatekeeping

align teams with problems, not solutions

don’t let everyone start all at once!

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

accept that your teams need to skill up

https://www.jeremydaly.com/newsletter

Step 2.
Identify service boundaries

start with low-risk, non-critical business processes

incrementally migrate the legacy system by gradually
replacing pieces of functionalities to the new system
Strangler Pattern

Services…
are autonomous

Services…
are autonomous
have clear boundaries

Services…
are autonomous
own their data

Services…
are autonomous
own their data
are loosely coupled through shared contracts

beware the “entity service” anti-pattern

Step 3.
Organize your codebase

github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo

monorepo

github
repo

share code through symlinks + webpack

one CI/CD that deploys them all (in parallel)

good for small teams/startups

one repo per service

github
repo
github
repo
github
repo
github
repo
user-api
timeline-api
relationship-api
search-api

one CI/CD pipeline per service

shared infrastructure (VPCs, etc.) in separate repo

ref shared infra via CFN output, SSM param, etc.

share code through shared libs (NPM, maven, etc.)

shared code vs shared service

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

deployment framework, CI, monitoring, etc.

there’s NO “best tool” for X
pick the best one for YOU and stick to it

https://lumigo.io/blog/comparison-of-lambda-deployment-frameworks

don’t write your own deployment framework

standardization maximizes instituational
knowledge sharing

what got you here won’t get you there

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

GET /user
POST /user
DELETE /user
Single-Purposed Functions

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

author: yan.cui
feature: user-api
user-api-dev
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
ﬁnd related
functions by preﬁx

author: yan.cui
feature: user-api
user-api-dev
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
discoverability
(without having to dig into the code)

author: yan.cui
feature: user-api
user-api-dev
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
what does it do?

author: yan.cui
feature: user-api
user-api-dev
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
dynamodb:GetItem
dynamodb:PutItem
dynamodb:DeleteItem

author: yan.cui
feature: user-api
user-api-dev
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
dynamodb:GetItem
dynamodb:PutItem
dynamodb:DeleteItem
no least privilege…

author: yan.cui
feature: user-api
user-api-dev
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
require(x)
require(y)
require(z)

more dependecies equals
slower cold start

author: yan.cui
feature: user-api
user-api-dev
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
author: yan.cui
feature: user-api
require(x)
require(y)
require(z)
worse cold start
performance

keep functions simple, and single-purposed

Step 6.
Migrate to new service

Monolith DB
Feature A
Feature C
Feature B
Feature D
Feature E Feature F
Monolith

Monolith DB
Monolith
Feature A
Feature C
Feature B
Feature D
Feature EFeature F
Service
DB

Monolith DB
Monolith
Feature A
Feature C
Feature B
Feature D
Feature EFeature F
Service
DB
requires challenging &
risky coordinated update!

Monolith DB
Monolith
Feature A
Feature C
Feature B
Feature D
Feature EFeature F
Service

Monolith DB
Monolith
Feature A
Feature C
Feature B
Feature D
Feature EFeature F
Service
migrate the least
critical component first

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!

Monolith DB
Monolith
Feature A
Feature C
Feature B
Feature D
Feature EFeature F
Service
DB
if not… consider this approach

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

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

maintain API compatibility
(all versioning schema sucks…)

prefer synchronizing data over synchronous API calls

System A
System B
System C
System D
User
User
System EUser
structural weakness

System A
System B
System C
System D
User
User
System EUser
cascade failures
cascade failures
cascade failures

System C
System DUser
upsert

be mindful of GDPR!
avoid synchronousing PII data

acceptance
integration
unit
no. of tests
in the monolith…

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

acceptance
integration
unit
won’t catch many
integration problems

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

LambdaAPI Gateway DynamoDB
Unit Tests

Unit Tests
Mock/Stub

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

a passing test is not a guarantee that something works

optimize for working software, not your feedback loop
(feedback loop is an important ingredient, but not the goal!)

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

prefer high-level functional tests
pro tip #2

integration tests exercise
system’s Integration with its
external dependencies
my code

acceptance tests exercise
system End-to-End from
the outside
my code

only use mocks for AWS services to simulate
hard-to-create failure cases
pro tip #3

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

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

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

Step 8.
Resilience as a service

observability, observability, observability

use queues to amortize trafﬁc spikes between services

use sagas to manage distributed transactions

use circuit breakers to prevent cascade failures

use bulkheads to isolate blast radius

go multi-region, active-active

#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

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

Production-Ready Serverless

get 10% off any workshop
serverless-london-virtual
theburningmonk.com/workshops

in your
company
ﬂexible dates
theburningmonk.com/workshops

@theburningmonk
theburningmonk.com
github.com/theburningmonk

Refactoring a Monolith to Serverless Architecture in 8 Steps

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Refactoring a Monolith to Serverless Architecture in 8 Steps

Similaire à Refactoring a Monolith to Serverless Architecture in 8 Steps (20)

Plus de Yan Cui

Plus de Yan Cui (20)

Dernier

Dernier (20)

Refactoring a Monolith to Serverless Architecture in 8 Steps