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

AWS Lambda pricing now per ms

aws.amazon.com

Post reply on HN
Print view View original

201–210 of 291 posts

Re: AWS Lambda pricing now per ms

#201

Post by throwaway894345 »

thetrooper wrote: post #130
throwaway894345 wrote: post #91

Earlier quoted context omitted.

Wow, I haven’t read yet, but I’m very curious if this affects the size limits on the lambdas. I’ve tried to build lambdas for a small Python use case, but by the time I imported pandas and a few other libraries I exceeded the 250 mb limit and migrated to ECS/Fargate, but the startup times were much longer.

yeah thats the issue. aws will make sure your fast language takes as much time as everything else - how will they make money if everyone makes use of fast languages?

I don’t know how this is related to my comment. In my case we used a slow language (although Python’s poor performance and its large bundle sizes are only indirectly related at best) and we had to spend a lot more by moving to ECS/Fargate. If we were using Go, our bundle sizes would’ve been 30x smaller (I checked) and would’ve fit in a lambda easily. Not only would it have fit easily, it would have made a lot of progress before the Python version even finished importing its dependencies. And in top of all of that, it would have out-performed the Python version by a good order of magnitude. If anything, my anecdote supports the idea that Amazon wants you to use fast languages, especially now that they offer per-ms pricing for lambdas.

Re: AWS Lambda pricing now per ms

#202

Post by holler »

throwaway894345 wrote: post #97
valbaca wrote: post #48

Earlier quoted context omitted.

From the research I did, here's how languages stack up in Lambda runtime (lowest first): 1. Python & JS 2. Go 3. C# & Java I couldn't find any data on Rust. The understanding at the time was that Python & JS runtimes are built-in, so the interpreter is "already running" Go is the fastest of compiled languages, but just can't beat the built-in runtimes. C# and Java were poorest as they're spinning up a larger runtime…

I’m not sure I’m interested in a hello world benchmark if it takes Python 5 seconds to import its dependencies in the real world.

Curious why it would take 5 seconds?

The way I'm using lambda, I compile the lambda build image beforehand which contains the python packages already installed, and the only "time" restraint is that of the lambda spinning up itself.

If you ran e.g. "pip install -r requirements.txt" inside the lambda, then yes it would take time to install the packages.

Re: AWS Lambda pricing now per ms

#203

Post by scrollaway »

zild3d wrote: post #187
koluna wrote: post #179

All fine and dandy, until it is not. Lambda = massive vendor lock-in, which means once you start depending on it, it’ll be hard to rip it out of your system and replace with someone else. My startup used to heavily rely on Lambda and frankly I wish we never did - so much AWS-specific complexity that is just not worth the trouble. Their own representative admits it[0]. We moved everything to containerized workflows an…

https://www.serverless.com/ abstracts a bit, so there's less lock in, but agree typical lambda workflows aren't just plain code you can move to a different vendor. A big perk is easy triggers to glue things together like new S3 file -> run lambda

I use Serverless framework even when I only want to deploy on Lambda. It's such a wonderful tool.

Re: AWS Lambda pricing now per ms

#205

Post by throwaway894345 »

holler wrote: post #202
throwaway894345 wrote: post #97

Earlier quoted context omitted.

I’m not sure I’m interested in a hello world benchmark if it takes Python 5 seconds to import its dependencies in the real world.

Curious why it would take 5 seconds? The way I'm using lambda, I compile the lambda build image beforehand which contains the python packages already installed, and the only "time" restraint is that of the lambda spinning up itself. If you ran e.g. "pip install -r requirements.txt" inside the lambda, then yes it would take time to install the packages.

Installing packages onto the system (“pip install”) is different than the interpreter importing them (loading them when the interpreter hits an “import” statement). Not only is it resolving imports into file paths and loading them into memory, but it’s also executing module-level code which tends to be quite common in Python, so it’s not at all uncommon for imports to take 5s or more.

Meanwhile in Go, dependencies are baked into the executable so there is no resolving of dependencies, and the analog to “module level code” (i.e., package init() functions) are discouraged and thus much less common and where they occur they don’t do as much work compared to the average Python package.

Re: AWS Lambda pricing now per ms

#206

Post by orf »

throwaway894345 wrote: post #97
valbaca wrote: post #48

Earlier quoted context omitted.

From the research I did, here's how languages stack up in Lambda runtime (lowest first): 1. Python & JS 2. Go 3. C# & Java I couldn't find any data on Rust. The understanding at the time was that Python & JS runtimes are built-in, so the interpreter is "already running" Go is the fastest of compiled languages, but just can't beat the built-in runtimes. C# and Java were poorest as they're spinning up a larger runtime…

I’m not sure I’m interested in a hello world benchmark if it takes Python 5 seconds to import its dependencies in the real world.

In the real world you don't import 5 seconds worth of dependencies into a lamdba, and a 5 second boot time for a longer-lived service is acceptable.

Re: AWS Lambda pricing now per ms

#208

Post by orf »

koluna wrote: post #200
munns wrote: post #190

Earlier quoted context omitted.

That is not at all what my words say and I won't reply to that thread which was started by a former competitor to troll this convo today. The perceived lock-in is really no different than consuming other technologies. You make a trade-off on what you want to manage vs. handoff to a managed service. For many customers the benefits are well worth it. It's fine that Lambda wasn't for you, but you aren't being clear here…

Cost, lack of debugging capabilities, terrible developer tools, cryptic documentation that misses some key scenarios, I can go on. Now, I get it, you’re at AWS so you would never openly and bluntly come out and say that what you -really- want is to lock in your users, because that brings AWS money. But that’s the reality. See my earlier comment as to why it made sense for our company to move away from Lambda.

What even is your point here and in this thread? Acquiring customers and giving them an incentive to stay is a cornerstone of any enterprise.

Saying lambda is bad because of lock-in is like saying their VPC offering is bad because of lock-in, or IAM is bad because of lock-in. It's not a generic component that you can flip between providers, they usually respond to a specific event from an AWS service and nobody really gives a rats about deploying their specific lambda to a cloud they don't use.

So yeah it seems like a real awesome idea to avoid vendor lock in for a small python function that responds to S3 change events from a SQS queue and updates a DynamoDB table with some values.

If you want "generic" lambdas go check out serverless.com.

Re: AWS Lambda pricing now per ms

#209

Post by austinpena »

munns wrote: post #169
daxfohl wrote: post #148

Earlier quoted context omitted.

How does that even work? Lambda seems like a challenge even with the entirety of the datacenter resources to work with. Running it in constrained edge environments with a VM per function seems like black magic.

The naming is a bit of a misnomer, today L@E doesn't run at the edge (in our PoPs) but when you deploy it copies to every region and then CloudFront routes you to the lowest latency region for your request.

So is L@E multi region then? Like if I have two concurrent requests across the globe are they serviced from two locations?
Post reply on HN