Live data from Hacker News

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

news.ycombinator.com

101–110 of 165 posts

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

#101
post #68

I'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…

Zappa author here, thank you for your kind recommendation! Lots more features in the pipeline, too!

I usually default to using Flask for Python when building APIs and using Zappa to deploy it has been a wonderful experience. Easy to develop locally with a Flask web server and then you just deploy with Zappa.

I haven't used it in a huge production environment, but it's definitely my go to way of handling APIs in side projects and other related things.

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

#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?

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

#103

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 was pretty straight forward to maintain.

Do you have any links to good tutorials on Claudia? I'd love to setup a contact me form using lambda for a project I'm working on.

Also, do you know how dos Claudia compare to stuff like serverless.js?

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

#104
post #90

Pros: - works as advertised, we haven't had any reliability issues with it - responding to Cloudwatch Events including cron-like schedules and other resource lifecycle hooks in your AWS account (and also DynamoDB/Kinesis streams, though I haven't used these) is awesome. Cons: - 5 minute timeout. There have been a couple times when I thought this would be fine, but then I hit it and it was a huge pain. If the task is…

If you're already using the Node runtime, https://serverless.com/ fixes all of your "cons" perfectly. Terraform isn't a great fit, in my experience.

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

#105
post #89

Can anyone speak to continuous deployments with Lambda, where downtime is not an option? Is it possible to run blue green deployments?

Deploying code doesn't take a lambda function down. It just spins up the next instance with it.

You do have a cold start issue as mentioned above but if that isn't an issue, then you shouldn't see any down time.

We run a beta / prod system to do testing and then for blue / green, we deploy a second function and switch the API Gateway over when we are good to go. Pretty straight forward

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

#106
post #68

I'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…

Zappa author here, thank you for your kind recommendation! Lots more features in the pipeline, too!

Thanks for a great tool! The API Gateway console is inscrutable, so I'm glad Zappa just takes care of all that for you.

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

#107

I worked on a project where the architect wanted to use Lambdas for the entire solution. This was a bad choice. Lambdas have a lot of benefits - for occasional tasks they are essentially free, the simple programming model makes them easy to understand in teams, you get Amazon's scaling and there's decent integration with caching and logging. However, especially since I had to use them for whole solution, I ran into a…

1. Use a framework for deploying your lambda functions. There are a few that will manage the API Gateway for you.

2. Don't put the Lambda inside a VPC if you want lower response times

3. Step Functions don't seem ready for prime time that I can tell. (This might have changed in the last couple of months)

4. Lambda Functions should be microservices. Small and lean.

5. There is a limit on resources for CloudFormation so at about 20-30 functions with API Gateway on the serverless framework, you will hit a limit and can't add anymore (other deployment tools which don't use CloudFormation shouldn't have an issue)

6. Want more CPU, add more RAM

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

#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, months or even years to see an ROI?

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

#109
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) on all environments I can't marry the code and configuration to limit access to say RDS or elasticache or an S3 bucket per lambda.

I feel like I need a higher order primitive (a lambda group that is role + configuration can live in that includes the lambdas) to achieve this. I realize api gateway has the concepts of stages but currently the idea is for some lambdas to be invoked directly by the monolithic app or via SNS/SQS async.

Otherwise I could namespace my lambda functions which is hacky and make DevFooBar, StageFooBar, etc.

Currently we plan to split off our environments into separate AWS accounts.

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

#110

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…

I think it's very dependent on the task. I do agree with you, building a large/high load system on lambda is bad for the reasons you're suggesting. I think a lot of the hoop jumping is due to experimentation (you won't know how much of a pain in the ass a piece of technology is until you need to deal with it).

We've mostly used it for small tasks that will get run once a day. It's been fantastic for that, as putting up a box to handle a sparsely (one or a couple of times a day) run task is a lot of work and is expensive.

Post reply on HN