Maybe I am too late too this party but I have a question: Is there any framework for handling routing and deployments? What I mean is, is there ane xisting solution where I can make JS files to routes, and have those routes and js files be loaded into Lambda and configure the API end point; so that if I need to make an update to the lambda function i can just update the file (and re run the framework)
AWS Lambda – Best practices
61–68 of 68 posts
Re: AWS Lambda – Best practices
#62[deleted]
Re: AWS Lambda – Best practices
#63I'm amused by the off-hand note about maybe using DynamoDB instead of a relational database, because the biggest issue with connecting your Lambda functions to MySQL is that using Lambdas within a VPC is absolutely terrible right now. Sure, you can make lambda IP subnets in your VPC, assign your lambda to a subnet, give it a security group, and then you can easily setup your security group rules for your lambdas to c…
I am curious about the type of workloads that you do that will require serverless architecture yet are backed by a MySQL database. It was only 5 or so years ago that we were told that relational databases didn't scale so we all needed NoSQL.
Is Lambda only for workloads that require serverless architecture, or is it also for workloads for folks that would like to be running serverless?
I have a variety of web application APIs running on webservers in a VPC, with an RDS MySQL instance for backing. I'm interested in writing our new development using Lambda, but I'm still using MySQL as the database backend for now, and I still need to interact with existing APIs in the VPC. Perhaps someday I will have moved all those other applications to Lambda as well, and perhaps someday I will port all of our database functionality to DynamoDB, but I don't think that should be required in order to just get started with Lambda.
If I was writing everything from scratch, maybe I'd go full serverless. But I'm not in that case, and I'm also not in a case where MySQL won't "scale" for me at all (I wish I had that problem). If Lambda's not for me, any Amazon engineer can feel free to tell me so, but given their marketing, I did not think this was the case. They offered Lambda VPC for a reason, even though it doesn't work very well currently.
Re: AWS Lambda – Best practices
#64Can a given Lambda container process ever be used for multiple concurrent function invocations? If not, then we're dealing with at least 128 MB of RAM per concurrent request. Multithreaded and event-driven servers can do much better than that.
Yes See: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb... http://stackoverflow.com/questions/37523128/how-aws-lambda-c...
Actually, the answer is "no".
Re: AWS Lambda – Best practices
#65Earlier quoted context omitted.
AWS will sometimes reuse the container in which your Lambda runs, so if you set up e.g., database pools during load time, they're often still there the next time. Related: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...
I'm not familiar at all with Amazon's cloud, so I might be misinterpreting... but when you say " sometimes reuse..." and "they're often still there..." it sounds to me like they might as well not be? How would that be a good foundation for an app deployed in Lambda?
If the pool is still there, it gets reused. If not, a new one is created.
It should help with overhead, but not always. There's benefits to partial solutions sometimes, if you can avoid the side effects.
Re: AWS Lambda – Best practices
#66Earlier quoted context omitted.
Off-topic question: Why do people use throwaway accounts here on HN? Why is it so important that nobody knows who the real person behind posts is?
Can't speak for parent. For me, I don't care if people know the real person behind the post. But I don't want someone to be able to see a list of everything I have ever said. And unfortunately there is no way to do one without the other. Just like everyday conversation. I can speak without anonymity. But I would hate for someone to go look at some of the things I said 20 years ago.
I understand that. I don't really mind though, because
a) most people will never put in that effort to search my history and
b) I trust that I will be able to find a proper excuse/response to anyone who would "attack me with my written history"
Re: AWS Lambda – Best practices
#67Earlier quoted context omitted.
I am curious about the type of workloads that you do that will require serverless architecture yet are backed by a MySQL database. It was only 5 or so years ago that we were told that relational databases didn't scale so we all needed NoSQL.
Is Lambda only for workloads that require serverless architecture, or is it also for workloads for folks that would like to be running serverless? I have a variety of web application APIs running on webservers in a VPC, with an RDS MySQL instance for backing. I'm interested in writing our new development using Lambda, but I'm still using MySQL as the database backend for now, and I still need to interact with existin…
OK, but serverless without good reason sounds like resume driven development to me. And more hassle than what its worth. I prefer to have sound decisions behind my architectural choices. Tried and tested is a good reason to go with "normal" architecture for me.
Re: AWS Lambda – Best practices
#68As someone who uses Lambda heavily I find this post somewhat disappointing from a "best practices" standpoint. No mention of Lambda best practices like: - Using CloudFormation - IAM policies - Managing config - How to handle databases and connection pools Instead we get a logging suggestion that while interesting (I too prefer ElasticSearch to CloudWatch logs) is definitely not Lambda best practice. And suggestion ab…
I like in https://serverless.com/ 's serverless.yml how it provisions the CloudFormation stuff and gives you a way to manage IAM permissions.
We started with Serverless as well, but as soon as we started to do more complex stuff it showed its limitations and we ended up writing lots of CloudFormation resources in serverless.yml. That was no benefit over pure CloudFormation anymore, especially as Serverless uses YAML, but relies on some notations from JSON-CloudFormation templates, I assume because it pre-dates the introduction of YAML for CloudFormation templates.
In the end we switched over to CloudFormation with SAM (Serverless Application Model) and while that also still has some rough edges, we have been pretty happy since.
So if you don't rely on the cross-provider features Serverless offers I suggest to take a look at CloudFormation + SAM instead.