3 ms·

>> as though they were in a single process The problem is, you cannot abstract away a 3 order of magnitude difference in performance and latency. This problem

>> as though they were in a single process The problem is, you cannot abstract away a 3 order of magnitude difference in performance and latency. This problem increases with larger teams as people don't understand what is happening. Abstractions shorten the learning curve but also greatly slow the formation of an accurate mental model of how a system works.

nostrebored 3y ago
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, ...