Live data from Hacker News

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

news.ycombinator.com

151–160 of 165 posts

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

#151
post #62

After multiple side projects with Lambda (e.g. image processing services), we finally implemented it on larger scale. Initially we started out without any framework or tool to help, because there we pretty much non-existent at that time. We created our own tool, and used Swagger a lot for working with API gateway (because it is really bad to work with). Over time everything smoothened out and really worked nicely (ex…

why is API gateway so bad?

Well, using it manually is just cumbersome. API Gateway is not specifically designed for Lambda, so it has lots of settings which you would think are just default for building your API. Using it through Cloudformation or Serverless is way easier.

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

#152

Earlier quoted context omitted.

The node_modules one is rubbish IMO, I think their doco is absurd. You can just compile things down using webpack or such, this makes the package smaller and can be optimized for faster execution as well. The retry one is new to me, need to read more about it. Thanks for the info.

Does webpack work for node.js code? I was under the impression that webpack was specifically for front end code.

Node.js code works for frontend code.

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

#153
post #124

For a serverless system that uses Lambda together with eg CloudFormation, Dynamo, and S3, Cognito etc - it's pretty low level and you spend a lot of time understanding, refining & debugging basic things. The end-to-end logging and instrumentation throughout the services used by your app weren't great. Doesn't like big app binaries/JARs and Amazon's API client libs are bloated - Clojure + Amazonica goes easily over th…

I uploaded with Clojure 50kbyte compiled java, which have multi handler in one function. Execute times avg 15ms.

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

#154

Earlier quoted context omitted.

I used Azure Functions (when I was a MSFT employee, in fact), and found it to be unusable. A list of complaints: * setup is 100% completely clicky-clicky UI driven, which was a huge pain to scale. instantiation of a Function on behalf of a developer for production use was a huge time sink * it's clearly a thin veneer on Azure Web Services, and the abstractions leak badly in the portal (deployment credentials, for exa…

Thanks for the detailed feedback! I think you probably used Functions when it was much newer, and I think we’ve actually addressed all of your issues. - You can create a Function App via ARM/CLI/etc., you can write functions without ever touching the portal. See https://docs.microsoft.com/en-us/azure/azure-functions/funct... . You can also now use Visual Studio to author C# functions: https://docs.microsoft.com/en-us…

Update: the portal does work if Auth is enabled--the bug was fixed a couple of months ago and we didn't close the issue. See https://github.com/Azure/azure-functions-ux/issues/499

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

#155

Earlier quoted context omitted.

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

I'm curious why you have a NAT gateway between your Lambda and Elasticsearch?

Lambda is inside the VPC which means it can’t connect to the outside world without a NAT Gateway.

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

#156
Developing Lambda is an absolutely terrible experience. Tightening the integration between CloudFormation, API-Gateway, and Lambda would really improve the situation. For example, a built-in way to map requests/responses between API-Gateway and Lambda which didn't involve a janky parsing DSL would be pretty nice.

The strategy Lambda seems to suggest you implement for testing/development is pretty laborious. There's no real clear way for you to mock operations on your local system and that's a real bummer.

A lot of things you run into in Python lambda functions are also fairly unclear. Python often will compile C-extensions... I could never figure out if there was really a stable ABI or what I could do to pre-compile things for Lambda.

All of those complaints aside - once you deploy your app, it will probably keep running until the day you die. So that's a huge upside. Once you rake through the muck of terrible developer experience (which I admit, could be unique to me), the service simply works.

So, if you have a relatively trivial application which does not need to be upgraded often and needs very good up-time.. it's a very nice service.

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

#157
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…

I know we're discussing AWS here, but I find Azure handles this nicely. It has a 'slots' concept, so you can have a slot for production, another for QA, and any more you need. The really great thing is the ability to swap slots - so once you've finished testing a new QA build, you swap the QA and production slots, so what was running in QA is now running in production.

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

#158
post #114
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/

FYI: except on very wide screens that landing page copy is barely readable over the background image, and with a narrow window it's also obscured by the header and navigation.

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

#159

Earlier quoted context omitted.

Thanks for the detailed feedback! I think you probably used Functions when it was much newer, and I think we’ve actually addressed all of your issues. - You can create a Function App via ARM/CLI/etc., you can write functions without ever touching the portal. See https://docs.microsoft.com/en-us/azure/azure-functions/funct... . You can also now use Visual Studio to author C# functions: https://docs.microsoft.com/en-us…

Update: the portal does work if Auth is enabled--the bug was fixed a couple of months ago and we didn't close the issue. See https://github.com/Azure/azure-functions-ux/issues/499

Thanks for such a comprehensive follow-up. It's true that it has been a while, and it really does sound like you've addressed nearly all of the issues I had. (btw, the undocumented file was host.json, which it appears may be better documented now)

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

#160
post #102
post #93

Lots of great comments here. I'd like to add that being limited to 512mb of working disk space at /tmp has been a stumbling block for us. Would be really great to have this configurable along with CPU/memory. Additionally being able to mount and EFS volume would be very useful!

Is there any reason why you can't use S3?

Sure, and that's what I do most of the time.

However, if the S3 keys are larger than ~500mb, then it's not possible to process them in any way with Lambda since there isn't enough "scratch space" available in /tmp.

I was suggesting EFS support merely because it would allow access to arbitrarily large amounts of "local" disk to work with...

Post reply on HN