3 ms·

The mental model of using SQS and serverless is extremely simple. You put a message in, get a message out, and have your code run. This is something I’ve been

The mental model of using SQS and serverless is extremely simple. You put a message in, get a message out, and have your code run. This is something I’ve been able to teach teams how to do in a few hours. This is the a huge part of the value prop of these services. Performance and latency have a trade off, sure. But you get teams who have complete ownership over their service. You get services that can scale to millions of requests per minute transparently. Some of the highest scale workloads I know use microservices behind SQS.

chriswarbo 3y ago
> You put a message in, get a message out, and have your code run. In my experience it's more like put a message in, get an `AuthenticationException`, copy/paste some IAM stanzas into CloudFormation and redeploy, put a message in, get a configuration error, add dependency-injected config loaders to constructors, add env vars to CloudFormation and rededeploy, put a message in, get a deadlock from the threaded HTTP client due to class loading being single-threaded, refactor config loading to happen after construction but populate a cache, redeploy, put a message in, get a timeout due to a stampede on the cache, get a hefty bill from AWS for spinning up a load of long-lived serverless processes, ...