Ask HN: How big should an AWS Lambda be?
By big, I'm not referring to the size in bytes of the deployed archive. I'm asking how much functionality should it encompass. How long, on average, should it run? How man external systems should it communicate with? Is it a good idea for a Lambda to spawn multiple threads to communicate with external systems? Should a single Lambda encompass enough scope to essentially serve as web service API in FaaS environment?
3 comments
[ 3.0 ms ] story [ 18.0 ms ] threadLambda's can interact with databases and most external systems, but you want to keep them short and sweet. They take time to spin up on first run (100ms or so), and can run a maximum of 15 minutes.
Yes you can use threads/processes in Lambda's but usually to me it is a sign you are trying to do too much in a single piece of code, but there are exceptions of course. You can use step functions to coordinate multiple lambda's which is usually the better answer but not always.
And I'd say no, lambda's should not try to serve as a web service API, they can be components of the API but the API should be hosted elsewhere, like AWS API Gateway or your own EC2 instance etc.
Since you can expose them through the API Gateway, it is natural to write "web services" as Lambda functions. It is also good for the occasional "web form" such as to subscribe or unsubscribe to a mailing list -- the kind of thing that people used cgi-bin for back in the day.
Memory is the limited commodity in a system like lambda, because lambda can only give you low latency if your function is already in RAM or if it can get it into RAM quickly.
Lambda functions are not good for a database server or an inference server that works against a 20 GB model.
In the case of the "email newsletter" system above, I send the mail with Amazon's SES, I maintain the mailing list in DynamoDB, Lambda provides the user interface and also answers callbacks to remove bouncing email addresses. The toolset is almost ideal for this case because it is cheap to run for anywhere from hundreds of subscriptions an hour to one a week and I never have to worry that it went down.
I also have built Lambda functions that take callbacks from Samsung SmartThings that then filter the events and queue them in Amazon SQS where another server picks off events when it is ready.
By now we are having unconditional triggers; but I think lambdas plus some kind of status/context/finite_state_machine could make some interesting piece of software not just for web services.
Also transaction isolation would be great. I mean, enter a lambda make some calls to whatever service and if everything is OK, commit all those changes.
If something goes wrong, do an automatic rollback.
That would have a huge impact on lambda usage since you are not leaving half-done stuff.