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

A shared file system for lambda functions

aws.amazon.com

Post reply on HN
Print view View original

91–100 of 113 posts

Re: A shared file system for lambda functions

#91

Post by zelphirkalt »

arcturus17 wrote: post #65
zelphirkalt wrote: post #63

"lambda functions" not "lambda expressions" - It is funny (or not) how Amazon redefines how a term is used by naming a product. The words actually make no sense, but people do not care and say It anyway "lambda function".

I just glanced over the Wikipedia article for lambda calculus and there is at least one mention to “lambda functions”, right in the intro. What’s wrong with “lambda functions”?

To me it sounds like you say twice, that you have a procedure or lambda.

A lambda ("expression" is often not even said, instead simply "this lambda here ...") in many programming languages is already an anonymous procedure and often an anonymous function. So saying "lambda function" makes it sound like "procedure function" or "function function" or "lambda lambda".

Re: A shared file system for lambda functions

#93

Post by jdub »

Konohamaru wrote: post #69
garethmcc wrote: post #67

Earlier quoted context omitted.

If anyone is initially fooled by the naming that illusion is broken very quickly after just a few seconds of looking into it so I doubt that this was an intentional act to trick people

Lots of companies do what Amazon does. See University of Phoenix vs. ASU Phoenix campus. Is it stupid? Yes, but advertising is generally geared toward human stupidity. More specifically, it's geared toward pointy-haired bosses who are being presented AWS Lambda™ who are thinking to themselves "well I heard a lot about lambdas, are these what my team meant?"

We can't design everything for people who couldn't figure out how to operate a toothbrush.

Re: A shared file system for lambda functions

#95

Post by shoo »

I worked with EFS but not lambda in 2017-2018 when migrating an app to AWS - an app which included a bunch of random application code that assumed it could read or write into a network file system. Having EFS as a migration target to replace on prem CIFS was relatively pleasant, which removed the need to rewrite a bunch of the application code. S3 would have been a reasonable replacement but that would have required weeks or months of rewrites to hunt down filesystem calls and rework them to use simpler object store API.

One thing that tripped us up at the time was EFS not supporting encryption in transit: but this was fixed in early 2018 when EFS began supporting using stunnel to wrap the underlying NFS connection in TLS. https://docs.aws.amazon.com/efs/latest/ug/encryption-in-tran...

It reads as if this lambda integrated EFS works out of the box with encryption in transit

Re: A shared file system for lambda functions

#96

Post by still_grokking »

garethmcc wrote: post #72
abrookewood wrote: post #52

Earlier quoted context omitted.

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…

Not entirely true. The largest use case we see for Lambda is as the compute service for an API backend provisioned with API Gateway (so a full application backend) with synchronous responses over HTTP (so rapid response provided within milliseconds) and for mundane tasks that store data in a database just like a regular web application. The perfect use case we see repeatedly is for high volume HTTP requests to API Ga…

Reads as the thing AWS wants people to use Lambda for.

Running Lambda as a back-end is one of the most expensive options (especially when high load comes in, as a parent pointed out). So no question, that's what they want to sell.

Re: A shared file system for lambda functions

#97

Post by twoodfin »

shoo wrote: post #95

I worked with EFS but not lambda in 2017-2018 when migrating an app to AWS - an app which included a bunch of random application code that assumed it could read or write into a network file system. Having EFS as a migration target to replace on prem CIFS was relatively pleasant, which removed the need to rewrite a bunch of the application code. S3 would have been a reasonable replacement but that would have required…

I’m genuinely curious about the factors that made it OK to have an unencrypted protocol into 2018. Is the AWS infrastructure already encrypting at another layer? Nobody worries about attacks on data that’s only transiting AWS?

Re: A shared file system for lambda functions

#98

Post by WatchDog »

philliphaydon wrote: post #62
redis_mlc wrote: post #49

Earlier quoted context omitted.

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. Huh, how is it any different building and deploying to anything else. I store the code in git, build it in team city, and deploy it to S3 using octopus deploy which updates the lambda to point to the new versioned off zip.

It's different because they put that code editor in the lambda console, and some people actually use it.

I've built a lot of lambda apps and never used it, pretty much everything I do requires dependencies.

Re: A shared file system for lambda functions

#99

Post by philliphaydon »

WatchDog wrote: post #98
philliphaydon wrote: post #62

Earlier quoted context omitted.

> Also, I haven't seen anybody version control lambda code, even in compliance environments, so something to investigate. Huh, how is it any different building and deploying to anything else. I store the code in git, build it in team city, and deploy it to S3 using octopus deploy which updates the lambda to point to the new versioned off zip.

It's different because they put that code editor in the lambda console, and some people actually use it. I've built a lot of lambda apps and never used it, pretty much everything I do requires dependencies.

> and some people actually use it

Sure, I used a lambda to turn on/off a build server during particular hours. I wrote it directly into the console.

For actual applications tho, I don't use the console.

Just because the console exists doesn't mean people are flat out not versioning their code.

Re: A shared file system for lambda functions

#100

Post by cldellow »

twoodfin wrote: post #97
shoo wrote: post #95

I worked with EFS but not lambda in 2017-2018 when migrating an app to AWS - an app which included a bunch of random application code that assumed it could read or write into a network file system. Having EFS as a migration target to replace on prem CIFS was relatively pleasant, which removed the need to rewrite a bunch of the application code. S3 would have been a reasonable replacement but that would have required…

I’m genuinely curious about the factors that made it OK to have an unencrypted protocol into 2018. Is the AWS infrastructure already encrypting at another layer? Nobody worries about attacks on data that’s only transiting AWS?

I think Google's internal network was unencrypted in 2013 [1], allowing the NSA to tap it. After the Snowden leaks showed that they were being tapped, Google moved to encrypting data on their internal links. I wouldn't be surprised if Amazon made a similar decision.

[1]: https://blog.encrypt.me/2013/11/05/ssl-added-and-removed-her...

Post reply on HN