A shared file system for lambda functions • Hacker News Board

Re: A shared file system for lambda functions

#51

Post by deanCommie » Wed, Jun 17, 2020, 4:00 AM UTC

VWWHFSfQ wrote: post #42

I'm curious what people actually use Lambda for? I tried Lambda for a use-case that I had in 2018: We published Polls and Predictions to people watching the 2018 World Cup. We set the vote callback URL to a function on AWS Lambda. It failed spectacularly during our load-testing because the ramp-up period was far too slow. We needed to go from 0 to 100,000 incoming requests/second in about 20 seconds. We had to switch…

Inside Amazon itself, almost every new AWS service's control plane API these days is API Gateway/Lambda/DynamoDB

Re: A shared file system for lambda functions

#52

Post by abrookewood » Wed, Jun 17, 2020, 4:05 AM UTC

VWWHFSfQ wrote: post #42

I'm curious what people actually use Lambda for? I tried Lambda for a use-case that I had in 2018: We published Polls and Predictions to people watching the 2018 World Cup. We set the vote callback URL to a function on AWS Lambda. It failed spectacularly during our load-testing because the ramp-up period was far too slow. We needed to go from 0 to 100,000 incoming requests/second in about 20 seconds. We had to switch…

It works pretty well for tasks that are executed infrequently (no need to have a full application deployed), out of band (no need for a rapid response; we'll email you) and for tasks that can consume excessive resources (threatening other apps running on the server).

For us the perfect use case is the production of PDF reports: they aren't run that often; they can be emailed a few minutes later; and when too many of them are run at the same time, they would steal all the RAM on the server.

Re: A shared file system for lambda functions

#53

Post by boulos » Wed, Jun 17, 2020, 4:06 AM UTC

Disclosure: I work on Google Cloud.

It wasn't obvious to me if this is somehow mounting EFS over !NFS (since never says the words NFS in the post). My main fear when people say "Should I use Lambda / Google Cloud Functions / Cloud Run against my NFS server" my response isn't "How would you set that up" it's "Be careful. Cleaning up NFS locks held by clients that have gone away is fairly painful, and you have none of the mechanisms to make sure it exits properly".

Alternatively, you can mount without locking, and then you get one of the comments downthread about "and now you've given functions shared mutable state but with bad primitives".

tl;dr: Cool! ... But, how does this handle NFS locking?

Re: A shared file system for lambda functions

#54

Post by binaryblitz » Wed, Jun 17, 2020, 4:06 AM UTC

redis_mlc wrote: post #49

VWWHFSfQ wrote: post #42

I'm curious what people actually use Lambda for? I tried Lambda for a use-case that I had in 2018: We published Polls and Predictions to people watching the 2018 World Cup. We set the vote callback URL to a function on AWS Lambda. It failed spectacularly during our load-testing because the ramp-up period was far too slow. We needed to go from 0 to 100,000 incoming requests/second in about 20 seconds. We had to switch…

AWS lambda is used in 2 categories: 1) AWS administration-related actions (required for non-trivial mgmt.) 2) end-user actions (optional). AWS throttles and limits everything, so expecting 100,000 requests in 20 seconds on a default AWS account is unreasonable. The Cloud doesn't mean unlimited capacity. Also, I haven't seen anybody version control lambda code, even in compliance environments, so something to investig…

>Also, I haven't seen anybody version control lambda code, even in compliance environments, so something to investigate.

We have anything that gets deployed to lambda go through a jenkins job. Pulls code from GH and builds/uploads it to lambda. Very few people have the ability to manually edit lambda jobs through AWS. While it isn't a perfect solution, it's worked pretty well for us.

Re: A shared file system for lambda functions

#55

Post by simlevesque » Wed, Jun 17, 2020, 4:08 AM UTC

redis_mlc wrote: post #49

VWWHFSfQ wrote: post #42

I'm curious what people actually use Lambda for? I tried Lambda for a use-case that I had in 2018: We published Polls and Predictions to people watching the 2018 World Cup. We set the vote callback URL to a function on AWS Lambda. It failed spectacularly during our load-testing because the ramp-up period was far too slow. We needed to go from 0 to 100,000 incoming requests/second in about 20 seconds. We had to switch…

AWS lambda is used in 2 categories: 1) AWS administration-related actions (required for non-trivial mgmt.) 2) end-user actions (optional). AWS throttles and limits everything, so expecting 100,000 requests in 20 seconds on a default AWS account is unreasonable. The Cloud doesn't mean unlimited capacity. Also, I haven't seen anybody version control lambda code, even in compliance environments, so something to investig…

> Also, I haven't seen anybody version control lambda code, even in compliance environments, so something to investigate.

What ? That does not make any sense to me. I know I do and I think many do too.

Re: A shared file system for lambda functions

#56

Post by lukehoban » Wed, Jun 17, 2020, 4:36 AM UTC

anderspitman wrote: post #17

Very cool functionality, but so much complexity to set up, connect, and manage all the various services.

There is certainly some additional complexity here over the basic Lambda serverless setup. But I think the console-driven configuration as outlined in these posts often makes it harder to see what the core concepts really are.

With infrastructure-as-code tools, this can be a little clearer. At Pulumi we wrote a post earlier today on configuring the infrastructure needed to use EFS with Lambda, and it boils down to just a few concepts and a couple dozen lines of infrastructure code.

https://www.pulumi.com/blog/aws-lambda-efs/

Some of the complexity here also comes from the fact that EFS is a general purpose managed NFS service, instead of a fully-abstracted Lambda-specific feature. That does add a little additional up-front complexity, but means you can use EFS across all sorts of different compute in AWS - not just Lambda.

Re: A shared file system for lambda functions

#57

Post by amake » Wed, Jun 17, 2020, 4:50 AM UTC

VWWHFSfQ wrote: post #42

I'm curious what people actually use Lambda for? I tried Lambda for a use-case that I had in 2018: We published Polls and Predictions to people watching the 2018 World Cup. We set the vote callback URL to a function on AWS Lambda. It failed spectacularly during our load-testing because the ramp-up period was far too slow. We needed to go from 0 to 100,000 incoming requests/second in about 20 seconds. We had to switch…

It's fantastic for running Twitter bots that tweet out generated content at a set interval. I have several and they easily fit within the free limits.

Re: A shared file system for lambda functions

#58

Post by inshadows » Wed, Jun 17, 2020, 4:55 AM UTC

hedora wrote: post #26

mlosapio wrote: post #24

Earlier quoted context omitted.

Sort of. The better analogy would be spinning up compute localized to the s3 object; which would be pretty interesting. This feature they did release deserves little fanfare.

Ummm. Linux’s NFS client includes a kernel page cache. You can just mmap or read the file without doing anything else. That is zero or one memcpy overhead. S3 clients have to copy the data over the network, assemble the tcp packets, decrypt and checksum for ssl, and then memcpy the result. That’s at a minimum. They may be doing other work, like verifying the s3 checksum, or allocating memory to store the object. They…

Ummm, I'm pretty sure that before data from remote NFS server make it into kernel cache they too have to be copied over network, assembled from TCP packets, possibly decrypted (k5p) and verified (k5i) with NFS over Kerberos (otherwise you would have no confidentiality/integrity), and moved into newly allocated memory. Sure, once it is in kernel cache and data are not modified there may be just "Is this handle still up to date?" remote calls but you could achieve the similar cache with object storage.

Re: A shared file system for lambda functions

#59

Post by inshadows » Wed, Jun 17, 2020, 4:58 AM UTC

philsnow wrote: post #25

sharp knife to hand people -- because EFS is just NFS, it uses NFS for security / isolation. Everything that can mount a given volume needs to agree on what unix users are what, and you need to make sure to completely lock down root access, otherwise you can't enforce any kind of data isolation. If your use case can deal with one EFS volume per isolation boundary, you can use IAM to control who can mount what volume,…

Wrong. NFSv4 with Kerberos maps UIDs to Kerberos principals. Kerberos further allows you to apply (authenticated) encryption to transfers.

Re: A shared file system for lambda functions

#60

Post by philliphaydon » Wed, Jun 17, 2020, 5:00 AM UTC

VWWHFSfQ wrote: post #42

I'm curious what people actually use Lambda for? I tried Lambda for a use-case that I had in 2018: We published Polls and Predictions to people watching the 2018 World Cup. We set the vote callback URL to a function on AWS Lambda. It failed spectacularly during our load-testing because the ramp-up period was far too slow. We needed to go from 0 to 100,000 incoming requests/second in about 20 seconds. We had to switch…

I recently built a facade for payment gateway callbacks to put message into SQS to reduce loss of requests from main API. (Costs less than $1 per month to handle all requests and # of lost requests in the last 6 months has gone from ~15 out of ~10k to 0)

Edit 5 months cos it went live in jan.