How we used serverless to speed up our servers
summary
Honeycomb uses AWS Lambda as a serverless-as-accelerator for Retriever to scale CPU on demand, cutting query latency by roughly an order of magnitude; median lambda startup ~50 ms and observed p90 1.5s, while cost per CPU-second is ~3–4× EC2 but used ~1% of the time so net cheaper. Implementation reads segments from S3, sometimes returns ~200 MB (watch the 6 MB direct-return limit), hits AWS burst concurrency limit (1k–3k) and requires aggressive retries, observability, and S3-backed payloads.
AI-written summary · about
chapters (14)
- 0:00Start
- 8:08Retriever stores all your event data
- 8:32Retriever is a distributed datastore.
- 9:31Retriever is a distributed column store.
- 11:01Retriever indexes segments by timestamp.
- 13:02Bigger customers, more data coming in.
- 14:53Now people can run queries over 60 days
- 21:06Lambda scales... within limits
- 23:45Observability helps: concurrency
- 24:18Lambda scales...within limits
- 26:32Lambda scales up our compute
- 28:38Functions accept... JSON
- 30:33Functions cost.. something
- 32:10Observability helps!
related talks
32mUsing Serverless Functions for Real-time Observability
49mUsing serverless functions for real-time observability
41mUsing Serverless & ARM64 for Real-Time Observability
47mAdvanced Serverless Architectural Patterns on AWS
42mNo Server Is Better Than No Server: Building Blocks for Serverless Architectures
35mEfficiency of Serverless Architectures with AWS Solutions
01h 01mServerless at scale
01h 00mServerless - reality or BS - notes from the trenches