Is it possible (or efficient) to run a complete backend with AWS Lambda (vs say, Elastic Beanstalk)

Question

I'm relatively new to the server world, so forgive me if some of this is basic (and the first bit of text will be me explaining my logic to make sure that's not flawed). All my questions will be bolded, to make your help easier :).

I've been researching and teaching myself some of the AWS technologies, and I noticed in their Mobile Hub, if you want cloud logic, they only allow "automatic" setup of Lambda functions. After reading and researching, I've found a few resources that point towards "serverless" architecture (which the introduction of Lambda supports). In the past, it's my understanding that Elastic Beanstalk was introduced to help make server management (especially for mobile) significantly simpler.

For mobile dev, there's 2 options (obviously more, but for simplicity sake, we'll agree):

• Set up an Elastic Beanstalk that will have at least 1 instance running 24/7 and has multiple endpoints for each url
• With API Gateway, we can easily route urls to a specific Lambda functions. With this, we can handle any requests (much like setting up an Elastic Beanstalk application).

All of this leads me to believe that a complete Lambda backend would be completely possible and easy to create at a fraction of the cost of having a server running 24/7. Is that correct?

Now, assuming the above is correct, we need to determine if using Lambda really is beneficial over Elastic Beanstalk.

For simple servers, we could setup a few Lambda functions and call it a day (and it's probably much simpler and cheaper (at least for small projects) than using Elastic Beanstalk).

However, for more complex servers with more urls and database connections, things get more interesting.

These are the issues I see with using Lambda in the above situation

• Each url would have it's own API Gateway with it's own Lambda function. If any code or modules is used in multiple functions, we'd have to copy and paste that into each function.
• Managing multiple Lambda functions (and API Gateways) is simply more work than managing a single project/repo/whatever-you-wanna-call-your-code-base.
• Each function that requires a DB connection, has to connect within the function (vs say, having a constant connection within a Node.js app).

The only way (I could think of) to avoid the first 2 issues is to make one robust function that acts as a dispatch (main function takes a param from the API Gateway and determines which file to run within the Lambda function).

Are there any major points that I'm missing to determine if using Lambda over Elastic Beanstalk is worthwhile?

Answer 1

To keep everyone in the loop, I wasn't getting responses so I asked on StackOverflow and got the following response from mbaird. There's a bit of a discussion in the comments, so feel free to check it out and give him credit.

It sounds like you have it figured out already. You are correct that using Lambda instead of having a server running 24/7 can be a significant cost savings. This article makes the claim:

And it's saving some of Amazon's customers big bucks, with at least one happy Lambda customer saving 80% off their cloud bills. You might want to look at the Serverless Framework which manages some of the pain points.

I think in time many of the pain points will go away, as Amazon adds more features to Lambda and more third party tools are built for it. I'm constantly discovering new uses for Lambda, but I'm also constantly discovering uses that seem to be a good fit at first but don't really work on Lambda, at least not yet. For example I really need some way to limit the number of instances of a Lambda function that can be running concurrently to prevent maxing out available database connections or hitting usage limits on third party APIs. I also really need Lambda functions to run inside my VPC, but that is supposed to be coming very soon.