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

AWS Lambda – Best practices

cloudncode.blog

Post reply on HN
Print view View original

31–40 of 68 posts

Re: AWS Lambda – Best practices

#31

Post by throwaway2016a »

StreamBright wrote: post #7
throwaway2016a wrote: post #3

As someone who uses Lambda heavily I find this post somewhat disappointing from a "best practices" standpoint. No mention of Lambda best practices like: - Using CloudFormation - IAM policies - Managing config - How to handle databases and connection pools Instead we get a logging suggestion that while interesting (I too prefer ElasticSearch to CloudWatch logs) is definitely not Lambda best practice. And suggestion ab…

I actually use Lambda too but I never thought using CloudFormation instead of Ansible. Last time I checked CloudFormation was really difficult to deal with. Might have changed since.

The Serverless framework does a good job at abstracting some of CLoudFormation's complexity.

Re: AWS Lambda – Best practices

#32

Post by scarhill »

gamache wrote: post #19
pastaking wrote: post #18

Earlier quoted context omitted.

How do you use database connection pools with lambda? I thought it wasn't possible.

AWS will sometimes reuse the container in which your Lambda runs, so if you set up e.g., database pools during load time, they're often still there the next time. Related: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

Right, but only one request can be in progress against a container at a time, correct? So there's no reason for your pool to allow more than one connection. Of course, that might still be useful for retry, etc. if the connection went away while the container was frozen.

Re: AWS Lambda – Best practices

#33

Post by wyldfire »

Is there any easy way to tell what kind of things are infeasible/inappropriate for Lambda? I went looking for limitations and found code size/fd counts/etc [1] but I want to know more general things like "can I include native code? (a DSO to be used by python code, e.g.) -- if so, what arch?", "what AWS services can I/should I access?", etc.

[1] http://docs.aws.amazon.com/lambda/latest/dg/limits.html

Re: AWS Lambda – Best practices

#34

Post by schuyler2d »

We've had a lot of success deploying python web apps with Zappa: https://github.com/Miserlou/Zappa

The value is that it does deploy, the route-mapping, config management, and also allows you to 'keep-warm' if you want to keep the backend responsive even after zero/low traffic.

My hope is that best practices are going to continue being distilled into these deployment/wrapper frameworks.

Re: AWS Lambda – Best practices

#35

Post by wiredfool »

Every time I look at Lambda+API Gateway for a web api, there's always been one little thing that makes things way harder than they should be.

A while ago (pre proxy), it was nearly impossible to send back 302 redirects cleanly.

With LAMBDA_PROXY, it's not clear that you can actually return binary data through the Api Gateway. There's the undocumented isBase64Encoded parameter, but as far as I can tell, it's ignored. It doesn't trigger an error, but it doesn't decode base64 either.

Just this week I'm working on moving a static html site + a couple of dynamic urls over. I can work around the binary issue, but serving images is a solved problem in the rest of the world.

Re: AWS Lambda – Best practices

#36

Post by throwaway2016a »

scarhill wrote: post #32
gamache wrote: post #19

Earlier quoted context omitted.

AWS will sometimes reuse the container in which your Lambda runs, so if you set up e.g., database pools during load time, they're often still there the next time. Related: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

Right, but only one request can be in progress against a container at a time, correct? So there's no reason for your pool to allow more than one connection. Of course, that might still be useful for retry, etc. if the connection went away while the container was frozen.

It would be a pool of just one connection per database endpoint. So pool in the sense that once a stateless function is done with it it becomes available again for another function to take it. But you don't need multiple connections of the same type in the pool.

Re: AWS Lambda – Best practices

#37

Post by throwaway2016a »

wiredfool wrote: post #35

Every time I look at Lambda+API Gateway for a web api, there's always been one little thing that makes things way harder than they should be. A while ago (pre proxy), it was nearly impossible to send back 302 redirects cleanly. With LAMBDA_PROXY, it's not clear that you can actually return binary data through the Api Gateway. There's the undocumented isBase64Encoded parameter, but as far as I can tell, it's ignored.…

Binary data is tricky with Lambda proxy (and by tricky I mean... I haven't gotten it to work). But I also haven't tried much. Typically best practice for me has been:

- When dealing with uploads have an API call to get a pre-signed S3 upload URL

- When dealing with downloads using HATEOAS and/or the Location header to send the client to S3 to grab the actual file.

It requires some client-side designing around eventual consistency but it works well and is very scalable.

Re: AWS Lambda – Best practices

#38

Post by throwaway2016a »

cagataygurturk wrote: post #9
throwaway2016a wrote: post #5

Earlier quoted context omitted.

I've been using Lambda since the beginning (was an early private beta user). I am actually considering writing a book or perhaps some courseware. I don't blog. Unfortunately, if I do I cannot post it here as it would defeat the purpose of using a throw-away account :(

I am publishing a book in the following months that covers all the items you mention, IAM, fully Cloudformation, deployment with Gradle etc. The language I picked is Java because we thought with the publisher that Java at Lambda has very little written resources. If you are interested here is the link and if you pre-order it you can access to finished chapters already: https://www.amazon.co.uk/Building-Serverless-Arc…

Awesome. I'm not a Java guy but I'll take a look.

Re: AWS Lambda – Best practices

#39

Post by bpicolo »

joecot wrote: post #25
ahallock wrote: post #24

> My opinion, when going serverless, I wouldn’t think of using RDBMS’s (although you can) and instead use databases like Elasticsearch, DynamoDB, Mongo etc. This is a vague statement that's not really based on evidence, and I'm not sure why using Postgres, for example, is going to be so much worse for most use cases than these NoSQL solutions.

As I explain over here ( https://news.ycombinator.com/item?id=13774041 ), trying to use Lambdas with your existing servers, like Postgres, can cause some serious complications.

If that's the case, seems like a great argument against using lambda ;)

Side note, is that just startup time for a single lambda `node`? Won't you be running >>1 node and not really care about startup time for any single node?

Re: AWS Lambda – Best practices

#40

Post by alexvy86 »

gamache wrote: post #19
pastaking wrote: post #18

Earlier quoted context omitted.

How do you use database connection pools with lambda? I thought it wasn't possible.

AWS will sometimes reuse the container in which your Lambda runs, so if you set up e.g., database pools during load time, they're often still there the next time. Related: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

I'm not familiar at all with Amazon's cloud, so I might be misinterpreting... but when you say "sometimes reuse..." and "they're often still there..." it sounds to me like they might as well not be? How would that be a good foundation for an app deployed in Lambda?
Post reply on HN