Ask HN: What's been your experience with AWS Lambda?

I tried it writing a trivial python script that called a webservice every 5 minutes and stored the .json response in S3.

Advantages:

- Cheaper than having your own micro.t1 server and setting crontab. - I have information about how much time it takes to actually run the script.

Findings:

- Test & debug: inside lambda only. Didn't like this, but for trivial stuff like mine it worked.

- "Crontab-like" granularity: you cannot trigger a lambda function every X seconds. The minumum is a cloudwatch periodical "cron-like" trigger.

- The script took much more execution time than I thought. It also required less memory, but this is not a problem ;-).

- Every line you print() to stdout goes to a Cloudwatch log. It's both helpful and something to care about because Cwatch is not free.

I've only used Lambda for one thing, a simple website monitoring / alerting setup, but it worked wonderfully. I wrote my Lambda function in Java since I know Java better than the other options, and even in a verbose language like Java the actual code was probably 50-75 lines of meaningful code (not boilerplate). It just reads a file from S3 with a list of URL's, opens a connection to each in turn, and for any entry that experiences an error, it sends an SMS message to my phone using SNS. I probably spent an aggregate 3-4 hours on the whole thing, and it works great. And since I am only checking 4 times a day, it'll take me forever to use enough Lambda to cost anything.

It may not be perfect for all uses, but for this little thing it works out really well.

(Aside: Yes,I could have used an off-the-shelf package like Nagios, or a SaaS monitoring service. I did this in part to learn Lambda anyway, and also because I like the idea of something I control and can customize myself, but which doesn't require maintaining a server, yadda-yadda.)

Currently using it to build a service for image processing/generation from a given HTML template. Relatively simple to do in python and once it's hooked into API Gateway, easy to access and restrict as well.

In addition, I've used it as the backend for an Alexa skill, which works quite nicely[1].

[1] https://github.com/kkoppenhaver/last-episode

I don't recommend building your API with it unless your engineers' ops skills are on point. I'm currently contracting for an org that is transitioning from java & clojure services hosted in a colo backed by postgres to full on lambdas written in node backed by dynamoDB. They've built a very impressive Rube-Goldberg machine for taking some data from an etl process, inserting it in dynamo, and then retrieving when an endpoint is hit. In the meantime code quality and development speed have taken a nose-dive with a very important deadline looming in the near future.

Lambdas are great for event-driven tasks and cronjobs though.

I've been using AWS Lambda for a few weeks now. Mostly for trivial things like tagging and infrastructure automation. I like it as it supports python. For what I'm doing I don't need any external libraries so it's pretty slick. No server to maintain, etc...

I'm struggling a bit to find event patterns that work in cloudwatch to trigger my lambda functions though. For instance when a volume becomes "available" I can't find an event pattern that triggers off of that, etc... If anyone has any tips or documentation you can point me to that would be awesome.

The main thing to keep in mind with Lambda is the number of library dependencies you're pulling in and your development workflows. I believe that you're limited to a certain file size per a lambda job, which includes dependencies. Developer workflows, just means that you'll need to come up with a way to sync lambda jobs with your version control (we currently have a deploy script for our workflow). I do have one ex-colleague who's all in on Lambda. His company just uses lambda to do all their backend processing.

Lifecycle management of functions needs a better story. That said, I use a number of under-the-hood functions to build and power Last Week in AWS, I’ve replaced a number of cron jobs with it, and a lot of AWS billing work (transitioning objects, tag propagation, etc) can be efficiently handled at large scale via Lambda.

I’m just not sure I’d put it inline for anything life-critical just yet.

It truly depends on what you're feeding the lambda with. I wouldn't recommend it for stream processing, ie reading streaming data from kinesis. If you're going to read streaming data from kinesis, write a KCL application. I can say 99% you will need the flexibility you get.

It may seem like nothing, but not knowing when the lambda context is going to recycle can also be a real pain in the ass.

I use it together with DynamoDB and SES to support an email newsletter system that involves verification, unsubscribe, delivery notifications, etc.

Spins like a top and costs very little ro run.

Replaced it with Task Tiger (https://github.com/closeio/tasktiger)