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?