1.
MIND
THE
POTHOLES
MIND
THE
POTHOLES

2.
@theburningmonk theburningmonk.com
Jan 24th, 2007

3.
we’re getting a new server
in 3 months time

4.
yay!
about time!
hooray!!
finally!

5.
but we have to decide
what dependencies to
install on it now..

6.
…

7.
@theburningmonk theburningmonk.com
on premise VMs in the cloud

8.
@theburningmonk theburningmonk.com
on premise VMs in the cloud
abstraction level

9.
@theburningmonk theburningmonk.com
on premise VMs in the cloud
abstraction levelproductivity

10.
@theburningmonk theburningmonk.com
on premise VMs in the cloud
abstraction levelproductivity

11.
@theburningmonk theburningmonk.com
less is more

12.
@theburningmonk theburningmonk.com

13.
@theburningmonk theburningmonk.com

14.
@theburningmonk theburningmonk.com
right?

15.
@theburningmonk theburningmonk.com

16.
@theburningmonk theburningmonk.com
“why are we failing at this?”

17.
@theburningmonk theburningmonk.com
hidden dangers

18.
@theburningmonk theburningmonk.com
monolith microservices serverless

19.
@theburningmonk theburningmonk.com
monolith microservices serverless
observability
distributed
systems
bounded
context

20.
@theburningmonk theburningmonk.com
monolith microservices serverless
observability
distributed
systems
bounded
context

21.
@theburningmonk theburningmonk.com
monolith microservices serverless
observability
distributed
systems
bounded
context
event driven

22.
@theburningmonk theburningmonk.com
monolith serverless
missing learnings
from microservices

23.
@theburningmonk theburningmonk.com
monolith serverless
missing learnings
from microservices
poor decisions

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

25.
http://bit.ly/yubl-serverless

26.
Yan Cui
http://theburningmonk.com
@theburningmonk
Developer Advocate @

27.
enter the code “belfast60”
for 60 days free access to Lumigo

28.
Yan Cui
http://theburningmonk.com
@theburningmonk
Independent Consultant
advisetraining delivery

29.
https://theburningmonk.com/courses

30.
#1
not letting go of legacy
thinking

31.
@theburningmonk theburningmonk.com
“we’re doing serverless,
but why aren’t thing
going faster?”

32.
@theburningmonk theburningmonk.com
Socio Technical

33.
@theburningmonk theburningmonk.com
there are no silver bullets

34.
@theburningmonk theburningmonk.com

35.
@theburningmonk theburningmonk.com
centralised team
Team A Team B Team C Team D …

36.
@theburningmonk theburningmonk.com
“but the developers don’t understand AWS and how
our infrastructure is set up”

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

38.
@theburningmonk theburningmonk.com
what got you here won’t get you there

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

40.
@theburningmonk theburningmonk.com
GET /user
POST /user
DELETE /user
Single-Purposed Functions

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

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

43.
@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)

44.
@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?

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

46.
@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…

47.
@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)

48.
@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)

49.
@theburningmonk theburningmonk.com

50.
@theburningmonk theburningmonk.com
more dependecies equals
slower cold start

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

52.
@theburningmonk theburningmonk.com
keep functions simple, and single-purposed

53.
#2
one account that rules
them all

54.
@theburningmonk theburningmonk.com
mind the shared limits

55.
@theburningmonk theburningmonk.com
no. of DynamoDB tables
no. of API Gateway regional APIs
no. of API Gateway edge-optimized APIs
no. of Kinesis shards
no. of IAM roles
no. of S3 buckets
no. of CloudFormation stacks
no. of SNS subscription filters
no. of SSM parameters
…
Resource Limits

56.
@theburningmonk theburningmonk.com
DynamoDB read & write
API Gateway requests/second
Lambda concurrent executions
SSM parameter ops/second
…
Throughput Limits

57.
@theburningmonk theburningmonk.com

58.
@theburningmonk theburningmonk.com
compartmentalise security breaches

59.
@theburningmonk theburningmonk.com
One account per Team per Environment

60.
@theburningmonk theburningmonk.com

61.
@theburningmonk theburningmonk.com
https://github.com/OlafConijn/AwsOrganizationFormation

62.
@theburningmonk theburningmonk.com
https://github.com/OlafConijn/AwsOrganizationFormation

63.
@theburningmonk theburningmonk.com
https://github.com/OlafConijn/AwsOrganizationFormation
Accounts
Org Units
SCPs
Pwd Policies
Multi-Region
Pseudo-Funs
Init & Validate
CI/CD

64.
#3
do first, research later

65.
@theburningmonk theburningmonk.com
https://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/

66.
@theburningmonk theburningmonk.com

67.
@theburningmonk theburningmonk.com

68.
@theburningmonk theburningmonk.com

69.
@theburningmonk theburningmonk.com
the platforms need to do better at educating users on
how to choose between different services

70.
@theburningmonk theburningmonk.com
SNS vs SQS vs Kinesis vs MKS?
the platforms need to do better at educating users on
how to choose between different services

71.
ordering
replay events
Kinesis SQS SNS
by shard
none (standard)
global (FIFO)
none
up to 7 days none none
mode
retry
batched batched (up to 10) singular
retried until
success
(customizable)
retry + DLQ retry + DLQ
concurrency 1 per shard auto-scaled fan-out!!!
subscribers many one-to-one many
EventBridge
many
none
none
singular
retry + DLQ
fan-out!!!

72.
https://medium.com/theburningmonk-com/all-my-posts-on-serverless-aws-lambda-43c17a147f91

73.
https://www.jeremydaly.com/newsletter/

74.
#4
not using a deployment
toolkit

75.
@theburningmonk theburningmonk.com

76.
@theburningmonk theburningmonk.com
https://lumigo.io/blog/comparison-of-lambda-deployment-frameworks

77.
@theburningmonk theburningmonk.com
don’t write your own deployment framework

78.
#5
one repo per function

79.
@theburningmonk theburningmonk.com
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo

80.
@theburningmonk theburningmonk.com
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo
github
repo

81.
@theburningmonk theburningmonk.com
monorepo?

82.
@theburningmonk theburningmonk.com
github
repo

83.
@theburningmonk theburningmonk.com
one repo per service?

84.
@theburningmonk theburningmonk.com
github
repo
github
repo
github
repo
github
repo
user-api
timeline-api
relationship-api
search-api

85.
@theburningmonk theburningmonk.com
https://lumigo.io/blog/mono-repo-vs-one-per-service/

86.
@theburningmonk theburningmonk.com

87.
@theburningmonk theburningmonk.com

88.
@theburningmonk theburningmonk.com

89.
@theburningmonk theburningmonk.com

90.
@theburningmonk theburningmonk.com

91.
@theburningmonk theburningmonk.com

92.
@theburningmonk theburningmonk.com

93.
@theburningmonk theburningmonk.com
github
repo
github
repo
github
repo
github
repo
user-api
timeline-api
relationship-api
search-api

94.
@theburningmonk theburningmonk.com
one CI/CD pipeline per service

95.
@theburningmonk theburningmonk.com
functions are deployed together, as a stack

96.
unencrypted secrets
in env vars
#6

97.
@theburningmonk theburningmonk.com
secrets should NEVER be in plain text in env variables

98.
@theburningmonk theburningmonk.com
SSM Parameter Store
Secret 1
Secret 2
IAM
Environment:
SECRET_1: …
SECRET_2: …
Environment:
SECRET_1: …
SECRET_2: …

99.
@theburningmonk theburningmonk.com
SSM Parameter Store
Secret 1
Secret 2
IAM
Environment:
SECRET_1: …
SECRET_2: …
Environment:
SECRET_1: …
SECRET_2: …
yay!

100.
@theburningmonk theburningmonk.com

101.
@theburningmonk theburningmonk.com

102.
@theburningmonk theburningmonk.com
SSM Parameter Store
Secret 1
Secret 2
IAM
fetch at cold start,
cache,
invalidate every x mins

103.
@theburningmonk theburningmonk.com
https://github.com/middyjs/middy

104.
@theburningmonk theburningmonk.com

105.
@theburningmonk theburningmonk.com
SSM Parameter Store
Secret 1
Secret 2
IAM
switch to Higher
Throughput if you need
more than 40 ops/s

106.
not following least
privilege principle
#7

107.
too much/too little
concurrency
#8

108.
@theburningmonk theburningmonk.com
“Lambda generates too much load for the downstream system”

109.
@theburningmonk theburningmonk.com
one invocation
per message
SNS
Lambda

110.
@theburningmonk theburningmonk.com
Downstream
System
SNS
Lambda

111.
@theburningmonk theburningmonk.com
ordering
replay events
Kinesis SQS SNS
by shard
none (standard)
global (FIFO)
none
up to 7 days none none
mode
retry
batched batched (up to 10) singular
retried until
success
(customizable)
retry + DLQ retry + DLQ
concurrency 1 per shard auto-scaled fan-out!!!
subscribers many one-to-one many
EventBridge
many
none
none
singular
retry + DLQ
fan-out!!!

112.
@theburningmonk theburningmonk.com
if you want…
maximum
throughput
SNS
precise control
over throughput
Kinesis

113.
@theburningmonk theburningmonk.com
if you want…
maximum
throughput
SNS
precise control
over throughput
Kinesis
how quickly it scales out

114.
@theburningmonk theburningmonk.com
if you want…
maximum
throughput
SNS
precise control
over throughput
Kinesis
how quickly it scales out
SQS DynamoDB
Streams

115.
@theburningmonk theburningmonk.com
ordering
replay events
Kinesis SQS SNS
by shard
none (standard)
global (FIFO)
none
up to 7 days none none
mode
retry
batched batched (up to 10) singular
retried until
success
(customizable)
retry + DLQ retry + DLQ
concurrency 1 per shard auto-scaled fan-out!!!
subscribers many one-to-one many
EventBridge
many
none
none
singular
retry + DLQ
fan-out!!!

116.
@theburningmonk theburningmonk.com
#1 not letting go of legacy thinking
#2 one account that rules them all
#3 do first, research later
#4 not using a deployment framework
#5 one repo per function
#6 unencrypted secrets in env vars
#7 not following least privilege principle
#8 too much/too little concurrency

117.
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

118.
@theburningmonk theburningmonk.com
https://theburningmonk.com/workshops
Amsterdam, March 19-20 Helsinki, May 4-5 Stockholm, May 14-15
Dublin, June 16-17 London, September 24-25 Berlin, October 8-9

119.
@theburningmonk theburningmonk.com
Production-Ready Serverless

120.
@theburningmonk theburningmonk.com
bit.ly/prod-ready-sls-dublin-2020
20% off with
sls-belfast-0124

121.
@theburningmonk
theburningmonk.com
github.com/theburningmonk