Comment by cagataygurturk | Hacker News Reader

Comment by cagataygurturk | Hacker News Reader

I believe Amazon added scheduled execution because of high demand from customers who never understood why Lambdas are there. I saw also many people complaining about lacking SQS support of Lambda. It is totally normal that Lambda's are not supporting SQS because SQS is a pull model, while Lambda is designed differently. Very very probably, AWS will also add SQS support but it will mean that they preferred non-sense user complaints over their design.

Lambda functions are there to process a single message and produce output. It is a code piece that should be invoked responding to events (A new file on S3 bucket, a new record on DynamoDB, a HTTP request coming from API Gateway etc.) If you are designing a system where you execute Lambda function on its own without any meaninful event and get it pull data from an external source upon execution, you are designing your system wrong. Let us assume that this "cronjob" works every day at 10 pm and that day there was more than 5000 users whose trials end. Lambda has an execution limit of 5 minutes. In 5 minutes you are likely to fail to process 5000 users and Lambda execution will be interrupted. And what then? You are not designing a scalable system.

The correct approach would be to book a future Lambda execution (per user) when you register the user. A single Lambda function per user would then execute exactly when the trial ends for the user. Also this Lambda function would receive all the data it needs for its operation, so it would not need to connect to MongoDB to fetch user information. This can be probably done by SWF.

Unless you designed Lambda, this is an arrogant tone.

Sure, some of the things you mention are "better" or at least otherwise accomplished using event-triggered Lambdas. But there's plenty of reasons why you might want to run a job that takes under 5 minutes on a schedule.

For instance, daily or weekly "digest" emails. Or a nightly stats job, where expensive-to-calculate yet not-immediately-critical queries are performed and the results stored or exported. These are things where you want them to happen at a certain time. Cron does that.

It's possible that customers didn't understand why AWS thought Lambdas were there, but that's irrelevant. Suddenly, Lambdas were there, and people thought of more use cases (SQS triggering, connection to API Gateway, etc) than AWS had implemented from the start. That's not the customers' fault for being creative.

Yep, I agree. If you rely on Cron/SCheduled Tasks, then you end up needing to run a server to run them. If Lambda did scheduled tasks, I'd have 1-2 boxes less in each environment ...

Not sure based on your wording, but you -can- execute scheduled tasks with Lambda. It's a little tricky, as the actual configuration takes place in Cloudwatch (Cloudwatch Events). You also will be sure to want to set up a dead letter queue, and have that broadcast to an SNS topic that will email you, so that in the event the lambda fails, you'll be alerted.

I've read about external services that will hit a SQS queue for you, but it would be a lot nicer if it was just supported natively in Lambda.

No, like, http://docs.aws.amazon.com/lambda/latest/dg/with-scheduled-e... (and linked from that page, http://docs.aws.amazon.com/lambda/latest/dg/tutorial-schedul... )

You can just set up "here's my cron string, run this function", and it will run that function when applicable. No external services, no SQS. Just a Cloudwatch event, that executes your lambda, at a set schedule.

Perfect! Thanks. I'm going to retire some boxes ;)

You can still have regular boxes but turn on them when you need and turn off when your job is over. Let's say you can turn on an instance everyday at 10pm and tell your job to turn off the instance which it runs on when the job ends. It is possible to do it via AWS API.

Lambda was designed to be functions that run in response to an event. An item being put on an SQS queue is an event. The clock ticking over to the next second is an event. There is no reason why a lambda should not be triggered by these events.

Right but SQS is a pull model so it doesn't generate events. You can use SNS events to trigger a Lambda and tell it that something was added to an SQS queue or S3 or Dynamo or whatever.

Perhaps this is a naming issue? I wonder if they had called Lambda "AWS Triggers", they would have had customers operating that way. Still, this won't be the last time that a system adjusts to meet customer requirements.

*edit for grammar

Reply on news.ycombinator.com