From my perspective (working at a large SaaS provider built on AWS), we don't use Lambda for serving client requests. Rather, we use it for internal glue betwee

From my perspective (working at a large SaaS provider built on AWS), we don't use Lambda for serving client requests. Rather, we use it for internal glue between AWS services. If what you actually want to do is relatively simple, eg, read a JSON message from an AWS service, like a Cloudwatch Alert, an autoscaling action, or an API call logged in Cloudtrail, you can easily wire those events up to Lambda functions for which you only need to code the bit that parses the JSON and does something in response. So then if the event happens once a day, once a month, or 50 times a second, you don't have to actually worry about calculating scale, except for cost purposes. But if it's a rare event, then Lambda comes in way cheaper than a $20/month server you have to maintain somehow. Of course, you can build apps directly on Lambda, but there's a lot of tools you'll miss when you get around to going full scale production. But for simple glue to wire up actions to events, it's actually a pretty slick service.