Live data from Hacker News

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

aws.amazon.com

81–90 of 140 posts

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

#81

Wherein "serverless" basically means more computers in more places just doing different tasks.

Yep. It's good old fashioned webhosting. Drop your files in the amazon equivalent of ~/public-html/ . If it serves your needs, it's not a bad thing, but it's hardly revolutionary.

Webhosting usually have a flat monthly fee so maybe Lambda it's more like old fashioned mainframe timesharing, billed per resource usage. Not that I was there in its heydays but the two concepts seem very similar.

A consequence is that you really want to terminate quickly and use little RAM. If your JS function terminates in 110 ms and get billed for two 100 ms units you might be tempted to switch to a faster language (or ASM what you can) to save half the bill. Webhosting doesn't have that dynamic.

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

#82
post #70

Earlier quoted context omitted.

Call it whatever you want, but I like to use the language of those who hold the purse-strings. If they call it "serverless", then I call it "serverless". If delivering a lecture about why it's not really serverless improves your product, then go ahead and deliver that lecture, but I doubt it will.

Involves a server listening on a port, running on infrastructure that you indirectly pay. Not in the air, on a server. It is a very misleading term. Especially for non-tech savvy. Sounds like a scam. It's like calling being passenger on a car "wheel-less transport", because I as passenger don't have wheels.

It's more like driverless cars. Something clearly is driving the car, but it isn't you.

Moreover the fact it's even a car is now an implementation detail. It could just as well be a motorised shipping container that slots into a hyperloop when it reaches the station. The assumption that the AWS Lambda infrastructure is server hardware is just that - it may not be true now, and you could build a function-as-a-service platform out of a massive array of Raspberry Pis and it'd still have solid at-least-once invocation semantics.

And I'm repeating this, but you're flat wrong about the listening server-on-a-port. AWS Lambda functions are bound to queues and receive events. The closest you'll get to having a socket-on-a-port is that the provisioning API has a REST endpoint.

So if it isn't necessarily server hardware, and there's no server endpoint to connect to, that "hate" you started this thread with looks rather misplaced.

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

#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've improved p99 variability in API Gateway-related latency over the last few months, and will be addressing some of the Lambda-related latency that occurs when we refresh containers in the coming months. Additional latency optimizations coming at all levels of the stack, including networking.

A clarification on the discussions about "managed hosting": Lambda is not classic web hosting; in fact, we block Lambda functions from calling socket.listen. In the Lambda model (whatever you prefer to call the broader category), the cloud service sees every request in order to perform scaling and load balancing on the function's behalf.

Happy to chat offline with anyone who has additional questions or feedback: DM me on twitter @timallenwagner

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

#84

Wherein "serverless" basically means more computers in more places just doing different tasks.

Yep. It's good old fashioned webhosting. Drop your files in the amazon equivalent of ~/public-html/ . If it serves your needs, it's not a bad thing, but it's hardly revolutionary.

How do I setup "old fashioned webhosting" to respond at-least-once to events posted to a message queue?

How do I get "old fashioned webhosting" to automatically scale-out and scale-in?

How do I do all that and get per-100ms CPU-time billing?

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

#85
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.

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

#86
post #26
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 -…

Have you seen https://github.com/silvermine/serverless-plugin-write-env-va...?

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

#87
post #48
post #44

Earlier quoted context omitted.

How exactly have you been doing that? It would be a cool blog post if you had the time. I've been thinking about really high volume applications that connect to haproxy instances that do DB load balancing but even that has it's own set of initial latency issues. I haven't fully figured out that architecture. In python in particular I'd really love to know how to setup the connection reuse.

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…

You've got a problem with the naked domain redirects http://zappa.io https://zappa.io/

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

#88

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…

I think Lambda was never designed for building entire apps/APIs - It was designed for handling mid-sized processing tasks.

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

#89
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.

Piggybacking above comment with "Wheres da Ruby?" :D Using shims or jruby (with slow startup wasting milliseconds) hurts.

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

#90

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.

Post reply on HN