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.
Looking in from the outside, serverless seems so simple! And yet, many companies are struggling on their journey to serverless. In this talk, I highlight a number of mistakes companies are making when they adopt serverless.
Looking in from the outside, serverless seems so simple! And yet, many companies are struggling on their journey to serverless. In this talk, I highlight a number of mistakes companies are making when they adopt serverless.
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
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
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!!!
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