Hacker News Reader

Hacker News

Comment by throwaway2016a | Hacker News Reader

Full thread

throwaway2016a

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 about choosing the right timeout (which is not necessarily helpful since the default timeout is 3 seconds so the best practice could be... "Leave the default alone unless you have a really good reason to raise it")

As far as the logging piece goes, if you are to use ElasticSearch I would strongly recommend putting the logs in CloudWatch logs first then using something like Logstash with a CloudWatch logs source to populate it into Elasticsearch as to not add another network dependency to your Lambda function.

View on HN

I like in https://serverless.com/ 's serverless.yml how it provisions the CloudFormation stuff and gives you a way to manage IAM permissions.

AWS has its own Serverless Application Model (SAM) https://github.com/awslabs/serverless-application-model released last Oct. Rather than learning another framework, you'd use the same CloudFormation yaml syntax to define your stack and apps. It simplifies calling Lambda functions by providing a higher level abstraction triggers called Events. This makes it simpler to create Lambda functions for Rest API, Cron schedule, IoT devices, create Alexa skills, response to S3 events etc. Then its just "aws cloudformation package" and "aws cloudformation deploy" to create and update your app. It appears AWS team is learning the best from Serverless Framework. If you not mind the vendor lockin, SAM is the way to go. Serverless Framework has the promise of using the same tool against AWS Lambda, Google/Azure Functions and IBM OpenWhisk.

Serverless supports other providers besides AWS, so it's better if your aren't centered around AWS.

Personally I use the Serverless framework which supports other cloud providers and is generally more on the cutting edge than SAM (and pre-dates SAM).

But SAM is certainly a valid option if you are OK with vendor lock in. (which many people are)

I tried to use serverless, but I don't have full admin permissions and the site is unable to say what permissions it actually requires to work. I'll swing back round to it later in the year and see how it's progressing.

Agreed, at first I was skeptical because the marketing message on the site seemed a bit over-hyped, but it turns out it is a really valuable tool for streamlining both testing (invoke local) and deployment when working with Lambda. New users also benefit for the basic scaffolding (severless create) and the documentation is pretty decent.

I have tried kappa (Python) and node-lambda (Node.js), and serverless works better than both of them, is more frequently updated (Lambda and API Gateway themselves change frequently), supports more languages (I have used it with Java, Python and Node.js) and has a much larger, more active community.

The API gateway support is pretty simple and solid, and they also allow you to use cloud formation rules directly so it is very flexible.

We started with Serverless as well, but as soon as we started to do more complex stuff it showed its limitations and we ended up writing lots of CloudFormation resources in serverless.yml. That was no benefit over pure CloudFormation anymore, especially as Serverless uses YAML, but relies on some notations from JSON-CloudFormation templates, I assume because it pre-dates the introduction of YAML for CloudFormation templates. In the end we switched over to CloudFormation with SAM (Serverless Application Model) and while that also still has some rough edges, we have been pretty happy since.

So if you don't rely on the cross-provider features Serverless offers I suggest to take a look at CloudFormation + SAM instead.

I agree. This is less a description of best practices and more of a stream of consciousness about Lambda.

Sounds like you have some good tips for using Lambda, got any links or posts on them?

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 :(

Your throwaway has 1500 karma?

Yeah. I guess anonymous is a better word than "throw away" at this point.

Or even pseudonymous. You've posted enough to have established a reputation and personality. It's a name, just not your real one.

Off-topic question: Why do people use throwaway accounts here on HN? Why is it so important that nobody knows who the real person behind posts is?

Because the information people give away is more important than their identity.

Can't speak for parent. For me, I don't care if people know the real person behind the post. But I don't want someone to be able to see a list of everything I have ever said. And unfortunately there is no way to do one without the other.

Just like everyday conversation. I can speak without anonymity. But I would hate for someone to go look at some of the things I said 20 years ago.

Same here.

I understand that. I don't really mind though, because

a) most people will never put in that effort to search my history and

b) I trust that I will be able to find a proper excuse/response to anyone who would "attack me with my written history"

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-Architectures-C...

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

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.

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.

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?

Think of Lambdas like autoscaling containers. If you're operating with decent load, there's a good chance your container will stay up and be reused for multiple requests. But if load drops, your containers might be shut down so they aren't taking up resources while they're not being used. When load increases again, more instances will be spun up.

It's the same approach as autoscaling VMs, but at a function level.

If the pool is still there, it gets reused. If not, a new one is created.

It should help with overhead, but not always. There's benefits to partial solutions sometimes, if you can avoid the side effects.

Yes, but there's no guarantee that lambda will reuse a connection / won't continue to request new connections against your database :( Currently, it seems like there's no "concurrency limit" or "per-function throttling". It would be amazing if requests are just magically queued up in SQS and lambda just processes them... like a traditional queue-worker system except now we don't have to manage the infra.

That's essentially how asynchronously invoked (e.g., triggered by an event in S3 or DynamoDB) lambda tasks work. They're retried if the original invocation doesn't execute successfully, and if the third try fails, the triggering event is sent to a dead letter queue in SQS.

Lambda on Cloudformation is just sad. Unless you don't care about versioning, then by all means jump on that ship. I personally don't want to spin up a new stack to deploy a new version safely.

There are ways to handle versioning of Lambda and CloudFormation. Serverless framework does it.

With creative use of deletion policy you can do pretty well.

CloudFormation is pretty terrible about managing changes on DynamoDb databases, though.

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.

Reply on news.ycombinator.com