I'm running Rust on Lambda at the moment for a PBE board gaming service I run. I can't say it runs at huge scale though, but using Lambda has provided me with some really good architectural benefits: * Games are developed as command line tools which use JSON for input and output. They're pure so the game state is passed in as part of the request. An example is my implementation of Lost Cities[1] * Games are automatic…
I'm not sure if you care, but it's possible to use Neon to write native Node modules in Rust. No need for JS glue code and better performance than spawning a process.
Ask HN: How was your experience with AWS Lambda in production?
51–60 of 165 posts
Re: Ask HN: How was your experience with AWS Lambda in production?
#52API Gateway is a little rougher, but slowly getting there.
Re: Ask HN: How was your experience with AWS Lambda in production?
#53I've been using it for heavy background job for http://thefeed.press and overall, I think it's pretty ok (I use NodeJs). That said here are few things: - No straight way to prevent retries. (Retries can crazily increase your bill if something goes wrong) - API gateway to Lambda can be better. (For one, Multipart form-data support for API gateway is a mess) - (For NodeJs) I don't see why the node_modules folder should…
> I don't see why the node_modules folder should be uploaded. Exactly! Especially if you're using modules that include some sort of binary and build your function on macOS it's a pain -- I ended up using a Docker-based workflow to get the correct binaries into the node_modules.
Re: Ask HN: How was your experience with AWS Lambda in production?
#54Earlier quoted context omitted.
What do you mean by retries? Also, why would you upload node_modules? Why don't you build it first and only upload what is required...
> What do you mean by retries If there is an error, the function will be retried: http://docs.aws.amazon.com/lambda/latest/dg/retries-on-error... > Why would you upload node_modules It is required to: http://docs.aws.amazon.com/lambda/latest/dg/nodejs-create-de...
Re: Ask HN: How was your experience with AWS Lambda in production?
#55I was initially attracted to it as a low-cost tool to run a database (RDS) powered service side project.
Some thoughts:
- Zappa is a great tool. They added async task support [1] which replaced the need for celery or rq. Setting up https with let's encrypt takes less than 15 minutes. They added Python 3 support quickly after it was announced. Setting up a test environment is pretty trivial. I set up a separate staging site which helps to debug a bunch of the orchestration settings. I also built a small CLI [2] to help set environment variables (heroku-esque) via S3 which works well. Overall, the tooling feels solid. I can't imagine using raw Lambda without a tool like Zappa.
- While Lambda itself is not too expensive, AWS can sneak in some additional costs. For example, allowing Lambda to reach out to other services in the VPC (RDS) or to the Internet, requires a bunch of route tables, subnets and a nat gateway. For this side project, this currently costs way more running and invoking Lambda.
- Debugging can be a pain. Things like Sentry [3] make it better for runtime issues, but orchestration issues are still very trail and error.
- There can be overhead if your function goes "cold" (i.e. infrequent usage). Zappa lets you keep sites warm (additional cost), but a cold start adds a couple of seconds to the first-page load for that user. This applies more to low volume traffic sites.
Overall: It's definitely overkilled for a side project like this, but I could see the economics of scale kicking in for multiple or high volume apps.
[1]: https://blog.zappa.io/posts/zappa-introduces-seamless-asynch...
Re: Ask HN: How was your experience with AWS Lambda in production?
#56- There is a surprisingly high amount of API gateway latency - The CPU power available seems to be really weak. Simple loops running in NodeJS run way way slower on Lambda compared to a 1.1 GHz Macbook by a significant magnitude. This is despite scaling the memory up to near 512mb. - Certain elements, such as DNS lookups, take a very long time. - The CloudWatch logging is a bit frustrating. If you have a cron job it…
Re: Ask HN: How was your experience with AWS Lambda in production?
#57Re: Ask HN: How was your experience with AWS Lambda in production?
#58One thing to note. API Gateway is super picky about your response. When you first get started you may have a Lambda that runs your test just fine but fails on deployment. Make sure you troubleshoot your response rather than diving into your code.
I saw some people complaining about using an archaic version of Node. This is no longer true. Lambdas support Node V6 which, while not bang up to date, is an excellent version.
Anyway, I can attest it is production ready and at least in our usage an order of magnitude cheaper.
Re: Ask HN: How was your experience with AWS Lambda in production?
#59I'm not allowed to give you any numbers; here's an old blogpost about Sketch Cloud: https://awkward.co/blog/building-sketch-cloud-without-server... (however, this isn't accurate anymore). For this use-case, concurrent executions for image uploads is a big deal (a regular Sketch document can easily exist out of 100 images). But basically the complete API runs on Lambda.
Running other languages on Lambda can be easily done and can be pretty fast, because you simply use node to spawn a process (Serverless has lots of examples of that).
Let me know if you have any specific questions :-)
Hope this helps.
Re: Ask HN: How was your experience with AWS Lambda in production?
#60I've been using AWS Lambda on a side project (octodocs.com) that is powered by Django and uses Zappa to manage deployments. I was initially attracted to it as a low-cost tool to run a database (RDS) powered service side project. Some thoughts: - Zappa is a great tool. They added async task support [1] which replaced the need for celery or rq. Setting up https with let's encrypt takes less than 15 minutes. They added…