why the fuzz about serverless?

1. What is serverless and why you should care

2. Who’s using serverless?
3. Can you build a whole app with serverless?
4. How to migrate a monolith to serverless?
5. Day in the life of a serverless developer
6. Q&A
 Yan Cui
@theburningmonk
http://theburningmonk.com
AWS user since 2010
 Yan Cui
@theburningmonk running serverless in
http://theburningmonk.com production since 2016
 Independent Consultant

Yan Cui
@theburningmonk
http://theburningmonk.com

training advise delivery

“Serverless”
 It is serverless the same way WiFi
is wireless.
Gojko Adzic
http://bit.ly/2yQgwwb
Serverless means…
don’t need to worry about scaling
don’t need to provision and manage servers
Serverless means…
don’t need to worry about scaling
don’t need to provision and manage servers
don’t pay for it if no-one uses it
Lambda
Lambda DynamoDB

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

Workers (microVMs) don’t share memory

Lambda

Failures are isolated, no more system crash!

Lambda

Workers are garbage collected every x hours

Lambda

No more memory leaks and memory

fragmentation issues
SECURE
 Your code
Lambda
Your dependencies

The OS

EC2 instance

Networking

Physical infrastructure
COST-EFFICIENT
 Serverless

Cost tracks
usage closely Cost per
transaction is
highly predictable

User Tra c Cost

ffi
 Serverless Serverful
Cost can be predictable,
but you overpay

WASTE
Cost tracks
usage closely Cost per
transaction is
highly predictable

User Tra c Cost

ffi
aws.amazon.com/solutions/case-studies/finra-data-validation
pages.awscloud.com/Gated_IDC_Generating_Value_Through_IT_Agility.html
“FinDev”
cost per transaction: $0.0000051583

$0.0000035 $0.0000004083 $0.00000125

API Gateway Lambda DynamoDB

 We should forget about small ef ciencies, say
about 97% of the time: premature optimization
is the root of all evil.

Donald Knuth
Yet we should not pass up our opportunities in
that critical 3%.
fi
 input output

lower operational cost to

engineering time
run the feature

this is pretty $$$

cost of the conversation:
~$50 per dev per hour x 8 = $400
potential saving:
$10/month
cost of the conversation:
~$50 per dev per hour x 8 = $400
potential saving:
$10/month
break-even time for conversation:
$400 ÷ $10/month = 40 months!!!
 input output

lower operational cost to

engineering time
run the feature

this is pretty $$$

“I just want to get from A to B
I don’t care how”
 uber

Focus on
To get there!
getting there!

Navigate

Fuel

Ownership
 Physical
Servers

Code

Runtime & Scale

OS

HW Ownership
 Physical Virtual
Servers Machines

Code

Runtime & Scale

OS

HW Ownership
 Physical Virtual
Containers
Servers Machines

Code

Runtime & Scale

OS

HW Ownership
 Physical Virtual
Containers Serverless
Servers Machines
Focus on
Code
getting there!

Runtime & Scale

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

2 million+ concurrent users at peak

Streaming live sporting events

2 million+ concurrent users at peak

Mix of containers and serverless

Serverless for APIs, event processing, etc.

www.youtube.com/watch?v=C0pA5eZkmFk
aws.amazon.com/solutions/case-studies/bustle
twitter.com/ben11kehoe/status/1187027628152115200
https://www.infoq.com/news/2021/01/bbc-serverless-scale
Workloads transcend industry boundaries
Serverless is a cheat code for getting stuff done ;-)
www.novasport.be
1 fulltime FE developer (mobile app) ~7 weeks
1 fulltime FE developer (CMS) ~3 weeks
1 part-time BE developer (me) ~4 weeks
CloudFront S3
 CloudFront S3

Cognito User Pool

 CloudFront S3 DynamoDB

Cognito User Pool AppSync Lambda

 CloudFront S3 DynamoDB

Cognito User Pool AppSync Lambda

 CloudFront S3 DynamoDB

Cognito User Pool AppSync Lambda

Algolia
 CloudFront S3 DynamoDB Lambda Algolia

Cognito User Pool AppSync Lambda

Algolia
 CloudFront S3 DynamoDB Lambda Algolia

Cognito User Pool AppSync Lambda Firehose S3

Algolia
 CloudFront S3 DynamoDB Lambda Algolia

Cognito User Pool AppSync Lambda Firehose S3

Algolia Athena
 CloudFront S3 DynamoDB Lambda Algolia

Cognito User Pool AppSync Lambda Firehose S3

Algolia Athena
AWS Organization root

OU OU OU OU
shared dev staging production
AWS Organization root

OU OU OU OU
shared dev staging production

Users Dev Staging Production

Audit
 SCPs
AWS Organization root

OU OU OU OU
shared dev staging production

Users Dev Staging Production

Audit
Migrating from monolith to serverless
 170 Lambda functions in prod

95% cost saving vs EC2

15x no. of production releases per month

outages down to almost zero

 170 Lambda functions in prod

95% cost saving vs EC2

15x no. of production releases per month

outages down to almost zero

Step 1. Reverse Conway’s Manoeuvre
 Conway’s Law
“organizations which design systems ... are constrained to
produce designs which are copies of the communication
structures of these organizations”
 Reverse Conway’s Manoeuvre
“structure 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 independently, and can fail
independently affecting each other”
small, autonomous teams that can innovate
and move quickly, and fail in isolation
“we’re doing serverless,
but why aren’t thing
going faster?”
Team A Team B Team C Team D …

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

incrementally migrate the legacy system by gradually

replacing pieces of functionalities to the new system
 Services…
are autonomous
 Services…
are autonomous
have clear boundaries
 Services…
are autonomous
have clear boundaries
own their data
 Services…
are autonomous
have clear boundaries
own their data
are loosely coupled through shared contracts
beware the “entity service” anti-pattern
Step 3. Organise your codebase
github github github
repo repo repo

github github github

repo repo repo

github github github

repo repo repo
github github github
repo repo repo

github github github

repo repo repo

github github github

repo repo repo
monorepo
github
repo
share code through symlinks + webpack
good for small teams/startups
one repo per service
 user-api search-api

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

requires challenging &

Feature A Feature B
risky coordinated update!

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

migrate the least

Feature A Feature B critical component first

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

cascade failures System C

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

npx sls deploy

main
-s feature-a

feature-a
 Dev

npx sls deploy

main
-s feature-a

temporary environment
feature-a
handler
 handler

test by invoking the

handler
 Dev

main

feature-a
 Dev

npx sls remove

-s feature-a

main remove temporary

environment

feature-a
 Dev

npx sls deploy -s dev

main
 Dev

runs end-to-end tests

main
 Dev

staging main
 Staging Dev

npx sls deploy -s staging

staging main
 Staging Dev

runs end-to-end tests

staging main
Prod Staging Dev

npx sls deploy -s prod

prod main
https://productionreadyserverless.com
@theburningmonk
theburningmonk.com
github.com/theburningmonk