Professional Documents
Culture Documents
Yan Cui
@theburningmonk
http://theburningmonk.com
S3
AppSync
Lambda DynamoDB
S3 API Gateway
AppSync
Lambda DynamoDB
S3 API Gateway
Cognito
AppSync
Lambda DynamoDB
S3 API Gateway
Cognito
EventBridge SNS
SQS
AppSync
Lambda DynamoDB
S3 API Gateway
Cognito
EventBridge SNS
SQS
Step Functions
AppSync
Lambda DynamoDB
S3 API Gateway
Cognito
EventBridge SNS
Kinesis
SQS
Step Functions
AppSync
Lambda DynamoDB
S3 API Gateway
You can build pretty much everything with serverless.
Cognito
EventBridge SNS
Kinesis
SQS
Step Functions
SCALABLE
Lambda
https://www.vladionescu.me/posts/scaling-containers-on-aws-in-2022
Lambda
OUT-DAT E D !
https://www.vladionescu.me/posts/scaling-containers-on-aws-in-2022
Every function can scale by 1,000 concurrent executions every 10 seconds,
independently of each other.
RESILIENT
DynamoDB replicates data to 3 AZs
S3 has 99.999999999% (11 9s) durability
Lambda, API Gateway, AppSync, etc. all provide built-
in multi-AZ redundancy out-of-the-box
Lambda
The OS
EC2 instance
Networking
Physical infrastructure
COST-EFFICIENT
Serverless
Cost tracks
usage closely Cost per
transaction is
highly predictable
WASTE
Cost tracks
usage closely Cost per
transaction is
highly predictable
Donald Knuth
Yet we should not pass up our opportunities in
that critical 3%.
fi
input output
Focus on
To get there!
getting there!
Navigate
Fuel
Ownership
Physical
Servers
Code
OS
HW Ownership
Physical Virtual
Servers Machines
Code
OS
HW Ownership
Physical Virtual
Containers
Servers Machines
Code
OS
HW Ownership
Physical Virtual
Containers Serverless
Servers Machines
Focus on
Code
getting there!
OS
HW Ownership
leverage: do more with less
“Unless you’re an infrastructure company,
infrastructure is basically overhead.”
https://bit.ly/2Im61VK
Matt Klein
https://theburningmonk.com/2020/11/how-i-built-a-social-network-in-4-weeks-with-graphql-and-serverless
leverage: do more with less
“Is serverless right for { insert industry }?”
Streaming live sporting events
Algolia
CloudFront S3 DynamoDB Lambda Algolia
Algolia
CloudFront S3 DynamoDB Lambda Algolia
Algolia
CloudFront S3 DynamoDB Lambda Algolia
Algolia Athena
CloudFront S3 DynamoDB Lambda Algolia
Algolia Athena
AWS Organization root
OU OU OU OU
shared dev staging production
AWS Organization root
OU OU OU OU
shared dev staging production
OU OU OU OU
shared dev staging production
centralised team
Team A Team B Team C Team D …
bottleneck
centralised team
trust, but verify
align teams with problems, not solutions
Step 2. Identify service boundaries
be a toe-dipper
start with low-risk, non-critical business processes
Strangler Pattern
github github
repo repo
relationship-api
github
timeline-api repo
github
repo
one CI/CD pipeline per service
shared infrastructure (VPCs, etc.) in separate repo
ref shared infra via CFN exports, 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/
Step 4. Migrate to new service
Monolith
Feature A Feature B
Feature C Feature D
Feature E Feature F
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
Feature E Feature F
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
Service
Feature F Feature E DB
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
Service
Feature F Feature E DB
Monolith DB
Monolith
Feature C Feature D
Service
Feature F Feature E DB
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
Service
Feature F Feature E
Monolith DB
Monolith
Feature C Feature D
Service
Feature F Feature E
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
Service
Feature F Feature E
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
Service
Feature F Feature E
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
Service
Feature F Feature E DB
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
if your system can tolerate a small downtime,
Service
then do the data migration with a downtime!
Feature F Feature E DB
Monolith DB
Monolith
Feature A Feature B
Feature C Feature D
Service
if not… consider this approach
Feature F Feature E DB
Monolith DB
Monolith
Feature A Feature B
treat new DB as a read-through/
write-through cache
Feature C Feature D
Service
Feature F Feature E DB
re ad
Monolith DB
i t e
wr
Monolith
Feature A Feature B
also run one-off migration job
in the background
Feature C Feature D
Service
Feature F Feature E DB
re ad
Monolith DB
i t e
wr io n
rat
ig
m
Monolith
Feature A Feature B
Feature C Feature D
Service
Feature F Feature E DB
Monolith DB
context is king
start up
STABILITY
prefer synchronising data over synchronous API calls
User System A
System B
User System D
structural weakness
System C
User System E
User System A cascade failures
System B
cascade failures
User System D
User System E
User System D
rt
se
up
System C
be mindful of GDPR!
avoid synchronising PII data
Day in the life of a serverless developer
main
main
feature-a
Dev
feature-a
Dev
temporary environment
feature-a
handler
handler
main
feature-a
Dev
feature-a
Dev
main
Dev
staging main
Staging Dev
staging main
Staging Dev
staging main
Prod Staging Dev
prod main
https://productionreadyserverless.com
@theburningmonk
theburningmonk.com
github.com/theburningmonk