SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
Migrating existing monolith to serverless in 8 steps
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
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
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
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
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
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
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