Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How was your experience with AWS Lambda in production?

news.ycombinator.com

Post reply on HN
Print view View original

131–140 of 165 posts

Re: Ask HN: How was your experience with AWS Lambda in production?

#131

Post by str3tch76 »

scrollaway wrote: post #45

We use AWS Lambda to process Hearthstone replay files. My #1 concern with it went away a while back when Amazon finally added support for Python 3 (3.6). It behaved as advertised: Allowed us to scale without worrying about scaling. After a year of using it however I'm really not a big fan of the technology. It's opaque. Pulling logs, crashes and metrics out of it is like pulling teeth. There's a lot of bells and whis…

have you tried the Serverless Framework? For us it makes the dev experience a pleasant one.

This will allow you to easily deploy / integrate into a CI/CD system etc.

You can also easily add tags etc within it.

Re: Ask HN: How was your experience with AWS Lambda in production?

#132

Post by simalexan »

htormey wrote: post #103
thom_nic wrote: post #91

I deployed a couple AWS lambda endpoints for very low-volume tasks using claudia.js - Claudia greatly reduces the setup overhead for sane REST endpoints. It creates the correct IAM permissions, gateway API and mappings. Claudia.js also has an API layer that makes it look very similar to express.js versus the weird API that Amazon provides. I would not use lambda + JS without claudia. For usage scenarios, one endpoint…

Oh claudia sounds interesting. I'm a mobile developer who's used express/node before. The hardest thing for me when I was cobbling a backend together with lambda/dynamodb was unterstanding the permission system and debugging it when I configured it wrong. Lots of the examples and articles around this process are out of date and AWS's web front end can be painful to deal with. That said, when everything was setup, it…

Hey, one of the guys from Claudia here.

You can have tutorials and examples on the : - Claudia.js website - https://claudiajs.com - Claudia Github examples - https://github.com/claudiajs/example-projects

The purpose of Claudia.js is just to make it super easy to develop and deploy your applications on AWS Lambdas, API Gateway, also ease up the work with DynamoDb, AWS IoT, Alexa and so on.

There are two additional libraries: Claudia API Builder and Claudia Bot Builder, to ease up API and chat bot development and deployment.

Regarding the contract form - the best is to create a single service that will handle all the contract form requests. At that point, you can either connect it to DynamoDb, or even call some other data storage / service.

Both Serverless and Claudia have their points where they shine. For a better understanding of their comparison, you can read about it in the Claudia FAQ - https://github.com/claudiajs/claudia/blob/master/FAQ.md#how-...

Re: Ask HN: How was your experience with AWS Lambda in production?

#133

Post by Jdam »

manishsharan wrote: post #78
Jdam wrote: post #19

For running Java in Lambda, I had to optimize it for Lambda. To decrease processing time (and in the end the bill), I got rid of all reflection for example and though twice when to initialize what and what to make static. Also, Java Cold Start is an issue. I fixed this with creating a Cloudwatch Trigger that executes the Lambda function every minute to keep it hot. Otherwise, after some minutes of no-one calling the…

If you are triggering it every minute, may I ask how much you are paying for it per month . I have though about it as well as I have a java + spring + Hibernate which takes much too long to start up ; in fact the task execution time is less than the cold start time in my case.

Execution takes less than 100ms and I never exhausted my monthly free quota on Lambda, so I can't say.

Re: Ask HN: How was your experience with AWS Lambda in production?

#134

Post by rebolyte »

marcfowler wrote: post #48

We use it with node for a bunch of things like PDF generation, asynchronous calls to various HTTP services etc. I think it's excellent. The worst part about it by far is CloudWatch, which is truly useless. Check out https://github.com/motdotla/node-lambda for running it locally for testing btw - saved us hours!

+1 for node-lambda. It's a lot simpler than Serverless when you just want a little help with testing/deploying.

Re: Ask HN: How was your experience with AWS Lambda in production?

#135

Post by rebolyte »

bflesch wrote: post #20
eknkc wrote: post #10

We use Node.JS lambda functions for real time image thumbnail generation and scraping needs. As well as mirroring our S3 buckets to another blob storage provider and a couple of periodic background jobs. It works beautifully. It's a little hard to debug at first but when it's set up, both pricing and reliability is really good for our use cases. I think a lot of people try to use the "serverless" stuff for unsuitable…

Can you share your image resizing code on github? We're using thumbor on AWS but it is a huge PITA.

Setting up your own resizer using sharp[1] is pretty simple. Just make sure you install the module in a Lambda-compatible environment, so it can build its copy of libvips (native C library) correctly. I built and deployed my image thumbnailer on a CentOS VM.

[1]: https://github.com/lovell/sharp

Re: Ask HN: How was your experience with AWS Lambda in production?

#136

Post by munns »

runamok wrote: post #109
munns wrote: post #72

Hey all, My name is Chris Munns and I am currently the lead Developer Advocate for Serverless at AWS (I am part of the Lambda PM team). We really appreciate this feedback and are always looking for ways to hear about these pain points. Can email me directly: munns@amazon.com if you ever get stuck. Thanks, - Chris

I am on a devops team trying to implement lambda by splitting pieces off from a monolithic Java app where applicable. The biggest pain point I have is because we have multiple "environments" (such as dev, da, staging) in the same amazon account and because lambdas are global I can't limit access to resources via IAM easily without hacks. Aka, because the same lambda will be used (but different versions and/or aliases…

Hi Runamok,

Today given that aliases/versions do not have any sort of different permissions you are probably best to either run completely different stacks of resources or the multiple account model. With AWS Organizations these days its not that hard to run multiple environments across accounts.

We did a webinar on some of this a few months back, the slides here might be useful to you: https://www.slideshare.net/AmazonWebServices/building-a-deve...

It heavily leverages AWS's tools, but you could create similar practices using 3rd party frameworks and CI/CD tools as well.

Thanks,

-munns

Re: Ask HN: How was your experience with AWS Lambda in production?

#137

Post by munns »

adjohn wrote: post #114
kesor wrote: post #83

Earlier quoted context omitted.

The problem of logs is actually a problem of CloudWatch Logs being just not a very good service. A great way to solve that is to push all logs from CloudWatch Logs into an ElasticSearch cluster (using a Lambda function). AWS even has the code already done for you if you click the "subscribe" button in CWL. Then with Kibana/ElasticSearch the experience of inspecting and analysing logs is MUCH better.

We built IOpipe[1] to address these issues by offering our own wrapper[2] that sends telemetry to our service. IOpipe aggregates metrics, and errors, and allows the creation of alerts with multiple rules per alert. [1] - https://iopipe.com [2] - https://github.com/iopipe/iopipe/

+1 to the folks at IOpipe. A really cool product that gives you very interesting visibility into your Lambda function executions!

Re: Ask HN: How was your experience with AWS Lambda in production?

#138

Post by Prefinem »

ec109685 wrote: post #127
Prefinem wrote: post #123

Earlier quoted context omitted.

API Gateway adds around 200ms to each call for us based on our testing plus another 100ms if it’s inside a VPC. What region are you in? Our VPC has a NAT Gateway so that our Lambda functions can talk to the internet as well. I am by no means an expert and am reporting what watching the time differences between Lambda reporting and our network calls shows. Edit: this is by no means a deal breaker or anything. Just som…

Are you paying for ssl round trips in your tests? We haven't seen such slow response times with lambda or the gateway.

I don't believe so. I am using Chrome network data and the SSL has already been downloaded / cached.

Re: Ask HN: How was your experience with AWS Lambda in production?

#139

Post by Prefinem »

philliphaydon wrote: post #126
Prefinem wrote: post #123

Earlier quoted context omitted.

API Gateway adds around 200ms to each call for us based on our testing plus another 100ms if it’s inside a VPC. What region are you in? Our VPC has a NAT Gateway so that our Lambda functions can talk to the internet as well. I am by no means an expert and am reporting what watching the time differences between Lambda reporting and our network calls shows. Edit: this is by no means a deal breaker or anything. Just som…

(crap I just typed stuff out and pressed F5...) I haven't tried with a NAT Gateway. This is what I know. If the response is small, the request duration is small. Cloudfront > Gateway > Lambda > RDS (PostgreSQL) Response: 1k | 20ms-60ms 10k | 50ms-90ms 100k | 150ms-200ms 350k | 200ms-450ms That's a rough gauge of what I've experienced. I think the throughput on the gateway is the bottleneck.

Just hit one of our test endpoints

Test #1 Lambda run time (140 ms) Total waiting time (354ms) Total time (358ms)

Test #2 Lambda run time (300 ms) Total waiting time (490ms) Total time (567ms)

Test #3 Lambda run time (139 ms) Total waiting time (479ms) Total time (485ms)

This is for a 20kb payload single request.

Stack: Custom Domain -> Cloudfront -> API Gateway -> VPC -> Lambda -> NAT Gateway -> ElasticSearch

Re: Ask HN: How was your experience with AWS Lambda in production?

#140

Post by jdc0589 »

mgkimsal wrote: post #108

I'm reading here a lot of people jumping through some massive amounts of hoops to deal with a system that lock you down to a single vendor, and makes it hard to read logs or even read your own bill. a few years back, the mantra was "hardware is cheap, developer time isn't". when did this prevailing wisdom change? Why would people spend hours/days/weeks wrestling with a system to save money which may take weeks, month…

> hardware is cheap

yes, 95% of the time this is accurate. Hardware is only a small part of what you are paying for though. You are also paying for: the actual lambda platform and completely transparent hardware support + replacement, security patching, feature updates, reliability guarantees, etc...

If anything that supports your statement. Time and people are expensive.

Post reply on HN