10 comments

[ 3.3 ms ] story [ 36.2 ms ] thread
If only we could downvote links so this doesn’t get shared.
Did no one ever do a performance benchmark to compare prior to this Amazon study?
I actually designed the original serverless system (a few years back when I was still at Prime Video), and yes we did and it did sort of look like it could work until it didn't. Obviously wasn't the right solution for the scale we had in mind (or rather the type of problem we were working on) but it's sad to see the mistake of one team be used to justify shitting on serverless as a general solution.
I thought the article was phrased bit oddly.

Do you mind saying where it did seem like a sensible solution?

Not OP, but as someone that's now rebuilt 4 serverless systems into monoliths (across 4 orgs) and achieved some pretty stunning results, serverless would be useful if all of these things are true:

1) Your workload is fairly simple 2) Your workload is unpredictably spiky from low lows to high highs 3) Latency is not a concern

If any of these aren't true, you're probably better off using a monolith (but you should think logically about your individual use case).

A rational and pragmatic response to an issue like this? You must be new here ...
These conditions seem to limit serverless systems to a very niche set of circumstances.
If your monolith is already containerized, why not just deploy it on Kubernetes anyway. That way you can use standardized tooling and run it anywhere.

   kubeadm init && kubectl apply