Live data from Hacker News

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

aws.amazon.com

111–120 of 140 posts

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

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

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.

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

#114

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?

Just curious, what would be the major drawbacks of not using relational here? My understanding is that AWS is pushing Dynamo quite a bit and it seems cheaper, so if they're only needing to query off of session id and maybe user id, shouldn't that be sufficient?

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

#115

How does this work, if at all, for local development? Is there a pseudo-Lambda server that runs locally? If not, this introduces yet another environment variable or it requires changes to be pushed constantly to Lamba for test.

Check out our example on github https://github.com/awslabs/aws-serverless-express/tree/maste.... The lambda wrapper is very thin (4 LOC). So you have two options: run/test your express app locally as you always would, or use the provided `npm run local` command which simulates the API Gateway+Lambda part (you can modify the `api-gateway-event.json` to change the "request" from API Gateway). This is primarily an example and starting point, and there is much more you could do to improve this process.

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

#116
post #67

I am currently using AWS API Gateway + Lambda for the serverless backend of a social traveling startup. It is absolutely awesome: we are few people in IT and it is amazingly simple to manage the whole stuff. Moreover imho they are mature services at this time, they are flexible enough with enough configuration properties to fulfill a nearly full control of the development experience.

How much does it end up costing you? Any ideas how much a 'traditional' setup would be in comparison?

We reduced our service server costs to 1/6th by moving from Heroku to Lambda. And that's not even considering the main benefit of a big computational request not blocking other requests (which is why we moved to it in the first place).

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

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

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.

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

#118

Earlier quoted context omitted.

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…

How much data are you going to have, and of what format? Do you actually need NoSQL here?

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

#119

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 files beyond your memory limits, but even that can be mitigated by divide and conquer approaches.

That said, the API Gateway is annoying in that it makes complex things impossible and simple things more configuration than they need. Yet, I'd still take it over actually standing up a server.

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

#120

Earlier quoted context omitted.

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

Just curious, what would be the major drawbacks of not using relational here? My understanding is that AWS is pushing Dynamo quite a bit and it seems cheaper, so if they're only needing to query off of session id and maybe user id, shouldn't that be sufficient?

Relational is super handy. Very easy to report on and do various things down the road.

If all he needed was session id, sure, NoSQL is more or less the same. But what about when he adds other fields that are related? Say customer address or reports or .... His life may very well be easier with relational.

You should generally start relational. Then branch out if you are hitting the brick walls of relational. People using NoSQL for a 100MB database are making their life SERIOUSLY more difficult than it needs to be. (I have done it before, not fun).

Post reply on HN