Bottlenecks in Serverless Applications
summary
Shows concrete failure modes and fixes: managed APIs and services (Lambda, Kinesis, DynamoDB, CloudWatch, SNS/SQS, RDS) create capacity and latency bottlenecks that inflate cost and queue depth, exemplified by a $30,000 cost spike from aggressive CloudWatch polling. Presents tooling and numbers: benchmarking memory vs duration shows 128MB vs 512MB tradeoffs and CPU/network effects, explains shard/partition key limits in Kinesis, and describes the successful CloudWatch→Kinesis streaming fix that replaces polling and eliminates the queue backlog.
AI-written summary · about
chapters (14)
- 0:00Start
- 0:35Topics to discuss
- 2:20What is Serverless?
- 4:02Why Serverless?
- 5:16The limitations of Faas
- 7:59The properties of Serverless applications
- 9:40A real example - HSBC Solution Overview
- 13:14Non-Serverless Example
- 21:35Benchmark your Lambda
- 29:50More Serverless bottlenecks
- 30:57A real life example
- 33:17Scaling
- 35:28The correct approach
- 36:28Conclusions
related talks
51mServerless architectural patterns
39mBuilding Resilient Serverless Applications
36mObserving all the Serverless Things
43mThe Art of Embracing Failures with Serverless Architectures
25mWhere Did All My Servers Go?
40mSh... Fail Happens: Fail-aware Events Processing on AWS
01h 00mServerless Architecture - Tales from a world without servers
51mConfusion In The Land Of The Serverless
