Going Serverless: Migrating an Express App to AWS API Gateway and AWS Lambda • Hacker News Board

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

#101

Post by brianwawok » Tue, Oct 11, 2016, 1:01 PM UTC

pmontra wrote: post #79

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…

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

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

#102

Post by gjolund » Tue, Oct 11, 2016, 1:02 PM UTC

jotto wrote: post #26

gjolund wrote: post #11

I love lambda's, but api gateway was far from mature the last time I used it (6 months ago). Unless they have made serious updates to the deployment workflow, feature set, and documentation I would not recommend building your products on it.

The "0 to 1" workflow right out of AWS could not be easier, they have an in-browser code editor with a hello world already written for you. But that workflow doesn't make sense for real dev teams. So there's https://github.com/serverless/serverless . It's driven by a yaml file and is intuitive. The only thing I'm bothered by is lack of environment variables (have to hard code them) and terrible API Gateway latency -…

Serverless was nowhere near ready the last time I looked.

Are they still requiring sn unrestricted iam profile? That is a non starter for most orgs.

Also, I found working with serverless to be pretty unintuitive. You are relying entirely on large config files and it was very difficult and time consuming for me to test and rollback several different configs.

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

#103

Post by brianwawok » Tue, Oct 11, 2016, 1:02 PM UTC

bni wrote: post #90

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…

Is application side connection pooling always necessary to have good response time? MySQL has a really fast server side connection pool.

Usually 15 or 20 ms hit to make a new connection even in MySQL.

Also adds a fairly big server load. I suspect if a given MySQL instance supports 1000 long lived connections.. it would only support 100-200 connections that are closing every request. (Have not benchmarked this side, would be curious to see )

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

#104

Post by brianwawok » Tue, Oct 11, 2016, 1:05 PM UTC

jomamaxx wrote: post #18

jotto wrote: post #13

Earlier quoted context omitted.

I measured the actual latency over the weekend [0] [1] Bare ec2: 15ms Lambda via API Gateway: 276ms [0]: http://prerender.cloud/lambda-latency [1]: https://news.ycombinator.com/item?id=12678011

Thanks for the data points. I understand that Lambdas are 'relatively quick' when they are 'hot' - which is my crude metaphor for 'up and running'. The issue is, if the Lambda has not been in use for some time (seconds, minutes?), then the 'first call' can have quite a bit of latency - often up to 5 seconds - which killed it for us. There is no way we could reasonably deploy a service wherein customer would have to w…

The 5 second cold request thing is what GAE had 5 years ago. Eventually they gave up trying to make startup faster and allowed a paid plan to stay always hot. Which was good, but then also moving you much closer to a managed server (vs a pure pay as you use thing)

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

#105

Post by cerebrum » Tue, Oct 11, 2016, 1:05 PM UTC

brianwawok wrote: post #100

cerebrum wrote: post #96

Earlier quoted context omitted.

I would want to know, how do I manage user credentials in AWS lambda. Lambdas are stateless, there is no session, so how do I keep track of which user is executing the current lambda?

How do you do it with a load balanced stateless web server? People have been doing this 10 years, most language should have some frameworks or plugins around it.... Common is to give the client a cookie with a session id (KJASDJKASDASDS) in a cookie. Then in a RDBMS you store this (session KJASDJKASDASDS = User 1234)... and the first part of each web (or lambda call), you go look up the user by session and know who i…

Thanks for the reply. In which DB should I store this data, considering the option of either DynamoDB or ElastiCache?

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

#106

Post by brianwawok » Tue, Oct 11, 2016, 1:06 PM UTC

cerebrum wrote: post #105

brianwawok wrote: post #100

Earlier quoted context omitted.

How do you do it with a load balanced stateless web server? People have been doing this 10 years, most language should have some frameworks or plugins around it.... Common is to give the client a cookie with a session id (KJASDJKASDASDS) in a cookie. Then in a RDBMS you store this (session KJASDJKASDASDS = User 1234)... and the first part of each web (or lambda call), you go look up the user by session and know who i…

Thanks for the reply. In which DB should I store this data, considering the option of either DynamoDB or ElastiCache?

Why not MySQL or PostgreSQL? Any reason you can't be relational?

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

#107

Post by cerebrum » Tue, Oct 11, 2016, 1:10 PM UTC

brianwawok wrote: post #106

cerebrum wrote: post #105

Earlier quoted context omitted.

Thanks for the reply. In which DB should I store this data, considering the option of either DynamoDB or ElastiCache?

Why not MySQL or PostgreSQL? Any reason you can't be relational?

Because I don't want to manage my own DB, so I would rather stick with the options that Amazon offers as a service.

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

#108

Post by brianwawok » Tue, Oct 11, 2016, 1:21 PM UTC

cerebrum wrote: post #107

brianwawok wrote: post #106

Earlier quoted context omitted.

Why not MySQL or PostgreSQL? Any reason you can't be relational?

Because I don't want to manage my own DB, so I would rather stick with the options that Amazon offers as a service.

You realized Amazon offers hosted MySQL and PostgreSQL, right? One click, and it's up.

https://aws.amazon.com/rds/

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

#109

Post by cerebrum » Tue, Oct 11, 2016, 1:36 PM UTC

brianwawok wrote: post #108

cerebrum wrote: post #107

Earlier quoted context omitted.

Because I don't want to manage my own DB, so I would rather stick with the options that Amazon offers as a service.

You realized Amazon offers hosted MySQL and PostgreSQL, right? One click, and it's up. https://aws.amazon.com/rds/

Ok, I want a 2 pronged approach:

1) A NoSQL DB for the main data providing replication and scalability(e.g. Cassandra or DynamoDB).

2) Another DB for quick access and transient Data where replication is not so important, e.g. storing the session cookie. Relational vs Non-relational would not be an issue since I'm only storing very little data here and want fast access and minimize costs(in DynamoDB you still have to pay per operation). Therefore I'm looking for some simple solution like ElastiCache.

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

#110

Post by falcolas » Tue, Oct 11, 2016, 1:40 PM UTC

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 through cold starts, fight against arcane packaging issues with site directories and .pth files (though this is probably just be a Python thing), fight concurrency throttling, external timeouts, manage out-of-band database connections, logging which requires even more IAM permissions...

This doesn't even consider how many times I've had to tear down and re-create an API Gateway setup because it got "stuck" and would stop working.

Finally, WTF is up with not being able to test API Gateway -> S3 integrations if the S3 bucket is in the same region as the gateway instance? It's a two plus year old bug by now, and a real pain (especially when coupled with other AWS services which require the bucket to be in the same region as the rest of a service - such as CodePipeline).

Perhaps it's just because I'm familiar with setting up and provisioning servers, but for basic web services and periodic tasks, Lambda is much harder to work with most of the time. Its biggest benefit so far has been the low cost.