4 ms·

Do NOT use Lambda for production at scale. [pic] https://twitter.com/JamiesonBecker/status/802185522139582464 https://twitter.com/JamiesonBecker/status/8021855

• jamiesonbecker 10y ago
  Unfortunately, the startup in question (yubl) has shut down due to lack of funding. They had a very large staff (about 70) and obviously the infrastructure was not cheap either. http://www.businessinsider.com/london-based-social-network-yubl-has-shut-down-2016-11 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.
• RubenSandwich 10y ago
  I'm having trouble reproducing your math. Can you be more specific on how you got (30.5 * 86,400) in your equation? Using this calculator I can't reproduce your cost: https://s3.amazonaws.com/lambda-tools/pricing-calculator.html# https://s3.amazonaws.com/lambda-tools/pricing-calculator.htm.... What is your execution time and memory on each lambda? 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.
  • jamiesonbecker 10y ago
    Please see Pricing Example 1 on https://aws.amazon.com/lambda/pricing/ https://aws.amazon.com/lambda/pricing/. That's Amazon's own pricing example using typical values. 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.)
    • RubenSandwich 10y ago
      Makes sense. Thanks for explaining. For scaling a lambda it might make sense to run your lambdas on EC2 using this: https://github.com/lambci/docker-lambda 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.)
      • jamiesonbecker 10y ago
        This looks cool! thanks for pointing it out!
  • deleted 10y ago
    [deleted]
• posnet 10y ago
  That ignore the biggest issue that lambda has at the moment. 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.
  • jamiesonbecker 10y ago
    Great point. I was just approaching it from the cost perspective.