|
|
|
|
|
by rubenfonseca
3907 days ago
|
|
I'm struggling to find a good balanced framework approach to AWS Lambda. I have a dozen of small lambda functions running, but I manage each one individually using just plain CLI commands or a simple Makefile. Sharing code is a pain.
I can only find simple Makefile-like (grunt?) approaches which seems to be too simple, or "monster"-like approach like JAWS that do a gazillion things at the same time (seriously, have you tried the hello world of JAWS? The amount of things it creates on your AWS account is scary to say the least). What I need is something where I can have a bigger project, export some services/api via handlers, and then some text file where I can "draw" my framework, connecting handlers to API gateway, input sources, etc. |
|
I need to get Lambda Complex into real apps for a while in order to understand what is really, actually needed around the transition of the interface with other AWS resources on update of version. Currently I'm sure it's going to be a major pain to have to write some code to redirect the flow of events to a different queue, but that's still better in my mind than to try to manage versioning with a single queue or other source of events that is not included in the CloudFormation template or has to be managed as a special case during updates.
The other pain point is monitoring of the application state and clearing up after it. Lambda functions spawn infinite log groups in CloudWatch, and they don't get deleted without some sort of automation to go do that. It isn't clear to me what the best approach is at this point in time to attach monitoring and alerting to CloudWatch Logs. I'd almost rather leave them alone and primarily monitor via SQS queue attributes, leaving the CloudWatch logs for manual inspection.