3 ms·

I think it's just the trade off between these two scenarios. - Relatively poor amortized scale out time with good guarantees in the worst case. - Good amortiz

I think it's just the trade off between these two scenarios. - Relatively poor amortized scale out time with good guarantees in the worst case. - Good amortized scale out time with dropped requests / timeouts in the worst case. With lambda, it doesn't really matter how spiky the traffic is. Users will see the cold start latency, albeit more often. With Fargate, users won't run into the cold start latencies - until they do, and the whole request may timeout waiting for that new server to spin up. At least that seems to be the case to me. I have personally never ran a docker image in fargate, but I'd be surprised if it could spin up, initialize and serve a request in two seconds.

zokier 5y ago
> With Fargate, users won't run into the cold start latencies - until they do, and the whole request may timeout waiting for that new server to spin up. In practice that sort of setup is not trivial to accomplish with Fargate; normally while you are scaling up the requests get sent to the currently running tasks. There is no built-in ability to queue requests with Fargate(+ELB) so that they would then be routed to a new task. This is especially problematic if your application doesn't handle overloads very gracefully.