https://twitter.com/JamiesonBecker/status/802185522139582464
https://twitter.com/JamiesonBecker/status/802185522139582464
Throttling.
Concurrent executions are throttles at a (account) regional level, which means if you have 10 different lamdas and 1 of them eats your entire concurrency limit by executing constantly it effectively DoSes the other lambdas such that they are unable to execute.
This may be fine if you are small, but many companies run shared infrastructure and all it takes is 1 misbehaving lambda to paralyse your entire region.
Edit: I'm guessing 86,400 seconds in a day and ~30.5 days in a month. If so you're using lambda wrong. You should not keep a lambda running forever rather treat each lambda as a short living function that responds to an API request and avoid calling async operations during the execution of it.
30.5 is the average number of days in a month. (365/12)
86,400 is the number of seconds in a day.
So, in other words, based on the very example shown on the Lambda pricing page, 3 million requests in a month is only 1.14 per second.
A single bare-bones t2.nano instance can easily handle that, but let's pretend that it's very, very spikey... so you need 10 nano's. (Of course, let's also pretend that you're constantly using them all, and autoscaling doesn't exist.) A nano can probably easily handle 100 req/s in even the slowest API framework (and certainly the languages supported by lambda), so that's where the rest of the numbers came from.
So, in other words, a cluster that easily handles 1,000 req/s would cost around $67/month, vs $1,600 and change for Lambda. Their very own example proves that it's far from cheap.
The worst part is that as scale increases, the cost disparity increases linearly. Recipe for disaster.
But, again, it's very useful for small things. (AWS certified Solutions Architect and I don't really touch lambda except for things that aren't worth running a whole server for.)
For scaling a lambda it might make sense to run your lambdas on EC2 using this: https://github.com/lambci/docker-lambda. (But at that point you loose the 'NoOps' benefit of lambda and I can't imagine you'd get similar performance to just running a Node Server or the like.)
http://www.businessinsider.com/london-based-social-network-y...
Lambda is perfect for one-off or seldom-run jobs. Although no one wants to run servers anymore, with any significant volume, lambda is a very poor choice due to costs that quickly grow literally exponentially over the servers used to run the actual tasks. At scale, autoscaling groups are a much better choice for the money.