Microservices and Serverless
summary
Argues that serverless raises developer productivity but has real limits: AWS Lambda and similar platforms use containers under the hood, enforce short, stateless executions, limited runtimes and cold starts (mitigations exist), and require design choices around data ownership. Recommends concrete mappings such as map an aggregate to a function, hiding many small functions behind a stable service interface, using IAM prefixes to limit table access for NoSQL stores, and practical tooling like use Serverless Framework and Azure Durable Functions for orchestrated flows.
AI-written summary · about
chapters (12)
- 0:00Start
- 2:10Independently deployable services that work together modeled around a business domain
- 4:04Microservices are an architecture that optimizes for autonomy
- 5:17Autonomy through self-service
- 15:38Just better virtualization?
- 16:21#serverless
- 23:05While containerization is a better form of virtualization, serverless is a better form of abstraction
- 27:06Functions as a service = Containers as implementation detail
- 27:54Limited runtime choices
- 46:59On-premise FAAS?
- 52:57Functions map very nicely to microservice boundaries – functions as state transitions
- 53:46URL: sli.do Code: #Y860
related talks
28mServerless - the way microservices should be
41mYou Don’t Want to Build a Serverless Monolith
04mWhat if serverless was real?
42mNo Server Is Better Than No Server: Building Blocks for Serverless Architectures
49mYou Don't Want Serverless
55mConfusion In The Land Of The Serverless
39mBuilding Highly Scalable Microservices with Serverless
53mServerless is the Abstraction We Deserve