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

Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

aws.amazon.com

Post reply on HN
Print view View original

121–130 of 140 posts

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#121

Post by noobiemcfoob »

scrollaway wrote: post #85
twagner wrote: post #83

@hobofan, take a look at our recent API Gateway features and see if the greedy paths and pass-through settings provide what you're looking for (they're also supported by CloudFormation). We tried to simplify the "configure every route" problem, but always looking for additional suggestions to make API config easier. @jomamaxx (& others): Reducing latency (and latency variability) is a critical goal for our team. We'v…

Tim, when are we getting Python 3 support on Lambda? Being stuck on 2.7 has been the greatest source of issues and the #1 problem we have with Lambda. If Google/Microsoft came out today with Python 3 support in their Lambda competitor, we'd move in an instant.

I'm in the same boat. We're developing a new product with no real reason to stay on Python 2, besides Lambda. Python 3 support would make my life so much easier.

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#122

Post by falcolas »

vamur wrote: post #117
falcolas wrote: post #113

Earlier quoted context omitted.

The cost is stupidly low. You would really have to work hard to go bankrupt. That said, there is a concurrency limit, which would help prevent your server time going to exponential limits.

Article doesn't mention any numbers. OVH VPS is $3.50 for a 2GB RAM and 100mbs (about 14TB a month assuming 50% utilization). That is about 14mln pages with 1MB size vs 1mln requests for API Gateway at $3.50, not including Lambda costs or bandwidth costs.

I don't have exact numbers, but we have dozens of lambda functions written in Python which are parsing and acting on Kinesis log streams (at volumes that cause problems for the Splunk ingest), and regularly hit the 100 process concurrency limit... but our bill is well under $10 a year (yes, year, not month. Hence my use of the adjectives "ridiculously" and "stupidly").

Luck? Hidden discounts? Don't know. Just know that our bill is ridiculously low for everything we're doing.

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#123

Post by falcolas »

noobiemcfoob wrote: post #119
falcolas wrote: post #110

Serverless via Lambda has been, frankly, a disappointment so far. The benefit is that I'm supposed to not have to manage servers anymore, yet I find myself, well, managing servers. I have to build and assign IAM roles, subnets, set up application configuration files in fixed external services (since you can't do things like set environment variables), configure the endpoints in nginx^h^h^h^h^h API Gateway, suffer thr…

> Perhaps it's just because I'm familiar with setting up and provisioning servers I'd be inclined to say that may be the case. Our codebase leans heavily on Lambda, primarily as a wide stage in our data pipeline. And I love it. Using a configuration file in S3 - or any other means of dropping a text file on AWS - is barely more complicated than open("file.txt"). The true frustration is when you need to work with file…

> is barely more complicated than open("file.txt")

Well, that depends. First, you have to set up the IAM roles to access the bucket which owns file.txt. Then you have to ensure that "file.txt" is properly shared between accounts if you separate production from staging from development. Then there's three lines of code to set up a client, pull the file, and read the contents. If it's an encrypted file, you also get to do a bit more setup work to ensure that you're using the v4 signature in the library, since it defaults to v3 signatures. There's also the additional error handling and points of failure to account for.

The requests are far from instantaneous as well, so you need to set up an out-of-band cache for the contents of the file if you plan to use it with every call of the lambda function.

Is it obtusely hard? Of course not. Is it as simple as `open("file.txt")` (or more appropriately `os.environ["FOO"]`)? Not by a long shot.

I have a feeling that our differences in opinion have more to do with the environment in which we run our lambda functions than what the lambda functions are doing. Once you move beyond a single region on a single account, things get a lot harder.

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#124

Post by noobiemcfoob »

falcolas wrote: post #123
noobiemcfoob wrote: post #119

Earlier quoted context omitted.

> Perhaps it's just because I'm familiar with setting up and provisioning servers I'd be inclined to say that may be the case. Our codebase leans heavily on Lambda, primarily as a wide stage in our data pipeline. And I love it. Using a configuration file in S3 - or any other means of dropping a text file on AWS - is barely more complicated than open("file.txt"). The true frustration is when you need to work with file…

> is barely more complicated than open("file.txt") Well, that depends. First, you have to set up the IAM roles to access the bucket which owns file.txt. Then you have to ensure that "file.txt" is properly shared between accounts if you separate production from staging from development. Then there's three lines of code to set up a client, pull the file, and read the contents. If it's an encrypted file, you also get to…

I may be overly simplifying working with a file, but I'd still argue you're over-complicating it :P You're hitting on a good point with Lambda though, namely the stateless aspect. To get the most out of Lambda, you have to adopt a more Functional-based programming model.

> Once you move beyond a single region on a single account, things get a lot harder.

I could see that.

I'm working in IoT, primarily connecting lots of dumb devices to small translation layers with minute data massaging along the way. In this type of low-intensity environment, the flexibility Lambda (AWS in general) gives you is tremendous.

The second performance(/latency) becomes a primary concern, it's easy to see that trade-off become untenable.

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#125

Post by Mizza »

avyfain wrote: post #58
Mizza wrote: post #48

Earlier quoted context omitted.

Check out the handler source code in Zappa for an example of a pattern like that. Similarly, if you use Zappa to deploy your application, if you create your database connection when the application loads, it'll just work. Stop by the Zappa slack if you want to explore this in more detail! https://slack.zappa.io It could always use more investigation, but there are quite a few Zappa users at extremely high loads now w…

This project looks super interesting. Thanks for sharing it! Now I want to come up with a use case to test it out over the next few days, maybe something for the Echo? I joined your Slack, we'll see where this takes us :)

That's a great use case, many people are using flask-ask and Zappa together to great success: https://github.com/johnwheeler/flask-ask

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#126

Post by breandr »

Everhusk wrote: post #41

I'm always surprised at the lack of discussion around database connection reuse with AWS Lambda. It's a pretty big deal that every single API call requires a new database connection. The only solutions I've seen so far are to run a separate app to interface with the database, or moving the connection outside of the handler (which still has issues). Am I missing something or is everyone just really happy to use Dynamo…

Hi Everhusk, I don't specifically call it out in the article, but the code is actually reusing database connections. As mentioned in other comments, the trick is to establish the connection outside of the handler so that the connection only happens once per container.

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#127

Post by hehheh »

vamur wrote: post #112

What is the benefit of AWS Lambda vs getting a cheap VPS or a dedicated server with much better specs and bandwidth, setting it up and adding auto-update? And how does one prevent going bankrupt if a Lambda app is DDOSed?

Auto updates can break shit; you need to monitor and understand the output of the auto update script. That understanding doesn't come cheap.

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#128

Post by toomuchtodo »

imtringued wrote: post #57
toomuchtodo wrote: post #5

Earlier quoted context omitted.

You break the entire model of an oversubscribed multi-tenant container system if you want every lambda hot all the time. If that's what you need...you need a server.

Keeping a Lambda container in memory is probably not going to take more than 500MB of RAM. Paying a monthly minimum fee per lambda per machine per month to keep it in RAM should be an option. It would still be far cheaper than a real server.

Would you be able to explain why it'd be far cheaper than a real virtual machine? Because the ram is the most expensive part in both cases.

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#129

Post by pmontra »

brianwawok wrote: post #101
pmontra wrote: post #79

Earlier quoted context omitted.

DynamoDB is not immune from that problem. There is no way out: if the container is terminated the connection goes down. The key is not making Lambda stop and rm the container (in docker terms). If there are enough requests the container is reused and the connection stays up, but you must initialize it outside the function. An example with DynamoDB const AWS = require("aws-sdk"); const docClient = new AWS.DynamoDB.Doc…

If there are enough requests to keep your container up all the time, why are you using lambda??

Exactly what I was asking but I didn't do the math.

Maybe it's OK for burst shaped traffic. The first request pays a toll, the others are quick.

Re: Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda

#130

Post by [deleted] »

andrew_k wrote: post #53
Everhusk wrote: post #41

I'm always surprised at the lack of discussion around database connection reuse with AWS Lambda. It's a pretty big deal that every single API call requires a new database connection. The only solutions I've seen so far are to run a separate app to interface with the database, or moving the connection outside of the handler (which still has issues). Am I missing something or is everyone just really happy to use Dynamo…

If you are creating connections outside of handler, it gets cached by Lambda between invocations. However you'll need to tune your database settings or you'll run out of connections on traffic spikes. Depends on your pattern of usage. Also cold start of lambda in VPC could take around 15 seconds https://www.reddit.com/r/aws/comments/49l91l/lambda_function... https://forums.aws.amazon.com/thread.jspa?messageID=735318&…

[deleted]
Post reply on HN