Background Processing, Serverless Style
summary
Serverless claims reduce ops overhead and boost developer productivity by replacing Sidekiq/Resque workers with functions triggered by HTTP gateways, Pub/Sub/SQS queues, or storage events, but it trades opacity and limits for convenience. Examples use S3/Google Cloud Storage, Elasticsearch, ActiveStorage, Pub/Sub and Cloud Functions; Ruby runs on AWS Lambda only. An experiment processes 100M Pub/Sub messages at about 5,000 messages per second with roughly ~0.1% duplicate rate, exposing rate and execution limits and at-least-once semantics.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 0:47About me
- 1:56Disclaimers
- 3:32Background Processing
- 5:17Serverless
- 11:50Functions as a Service
- 13:07Webhook Handler
- 15:45Why would you do this
- 16:44Text processing
- 19:03Message queue
- 20:07Why do this
- 24:10New YouTube
- 25:57Spirit of Style
- 29:08Why Serverless
- 31:27Things to Know
- 35:31Additional Resources
related talks
01h 00mServerless Architecture - Tales from a world without servers
51mServerless architectural patterns
47mServerless in production, an experience report
54mServerless beyond Functions
31mServerless Rails: Understanding the pros and cons
29mGoing Serverless
42mNo Server Is Better Than No Server: Building Blocks for Serverless Architectures
01h 00mServerless - reality or BS - notes from the trenches
