241–250 of 291 posts
Necessary change. Now writing stuff in fast languages suddenly matter in cost, changing the landscape of when these solutions might become viable for a chase.
thats ok they will slow down some random dependency to compensate for their loss
Oh, that absolutely changes the price calculation for Lambda. Historically the 100ms minimum billing interval made Lambda significantly more expensive than EC2 for large numbers of work loads.
This won’t save me a ton of money; but at least I won’t have to guess on if bumping up to the next CPU+MEM tier will get me from 101ms to 99ms
Does Lambda still lag from awake?
Earlier quoted context omitted.
And it costs even more if you need that Lambda function to have access to the internet. A possibly useful comparison: A Raspberry Pi 3 (~6.5 watts) costs $6.83 per year to run full-time (at 12 cents per kWh). You get a full computer with much more I/O. However, there are a lot of other factors to consider: - Initial cost of the hardware - Time and energy spent maintaining/configuring the device - Physical maintenance…
A RPi 3 has an upfront cost of over 10 dollars. With lambda you can start with pennies.
Earlier quoted context omitted.
> No to be clear I'm saying you are comparing things that are way more different than our friends at Cloudflare would like you to think. Care to expand on that? What exactly do you mean by "things are way more different"?
This is pretty standard AWS marketing spiel. They make vague assertions of "ah but you're not considering the big picture...." with no details
Does Lambda still lag from awake?
There are warm and cold runs. If it’s really important you can pre-heat by calling the lambda every so often. It would be nice if they had some option for this.
Earlier quoted context omitted.
My lambdas run for 15 minutes. I feel that they're still a great choice :)
Huh... that's the limit of lambda functions, are you doing some sort of work in 15 minute chunks?
Earlier quoted context omitted.
> In the real world you don't import 5 seconds worth of dependencies into a lamdba Laughs in data science . > a 5 second boot time for a longer-lived service is acceptable. Not every application can tolerate the occasional 5-second-long request. Just because Python can cold boot "hello world" 3 seconds faster than Go doesn't mean that's going to hold in the real world.
You're mixing arguments here. It's not the occasional 5-second long request, it's "the app doesn't start serving requests for 5 seconds". Using data science tooling in a lambda seems iffy, especially ones that are not production ready. And good luck getting such libraries in go. Python cold booting an interpreter 3 seconds faster than Go is a big deal, especially if your target execution time is <50ms and you've got…
Lambdas cold-start during requests. So the unlucky request that triggers a cold start eats that cold start.
> Using data science tooling in a lambda seems iffy, especially ones that are not production ready.
Nonsense, there are a lot of lambdas that just load, transform, and shovel data between services using pandas or whathaveyou. Anyway, don't get hung up on data science; it was just an example, but there are packages across the ecosystem that behave poorly at startup (usually it's not any individual package taking 1-2s but rather a whole bunch of them scattered across your dependency tree that take 100+ms).
> And good luck getting such libraries in go.
Go doesn't have all of the specialty libraries that Python has, but it has enough for the use case I described above.
> Python cold booting an interpreter 3 seconds faster than Go is a big deal, especially if your target execution time is According to https://mikhail.io/serverless/coldstarts/aws/languages/, Go takes ~450ms on average to cold start which is still up a bit from Python's ~250ms. To your point, if you're just slinging boto calls (and a lot of lambdas do just this!) and you care a lot about latency, then Python is the right tool for the job.
> not being silly and importing ridiculously heavy dependencies into a lambda for no reason other than to make a strange point about Python being unsuitable for something nobody should be doing.
Not every lambda is just slinging API requests--some of them actually have to do things with data. Maybe someone is transforming a bit of audio as part of a pipeline or doing some analysis on a CSV or something else. Latency probably matters to them, but they still have to import things to get their work done. And according to https://mikhail.io/serverless/coldstarts/aws/#does-package-s... (at least for JavaScript) just 35mb of dependencies (which will buy you half of a numpy iirc) causes cold start performance to go from ~250ms to 4000ms.
My rule of thumb (based on some profiling) is that for every 30mb of Python dependency, the equivalent Go binary grows by 1mb, moreover, it all gets loaded at once (as opposed to resolving each unique import to a location on disk, then parsing, compiling, and finally loading it). Lastly, Go programs are more likely to be "lazy"--that is, they only run the things they need in the main() part of the program whereas Python packages are much more likely to do file or network I/O to initialize clients that may or may not be used by the program.
Does Lambda still lag from awake?
There are warm and cold runs. If it’s really important you can pre-heat by calling the lambda every so often. It would be nice if they had some option for this.
Earlier quoted context omitted.
It's not necessarily the same in outcome. Undercutting competitors can be a temporary thing. As soon as the competitors are eliminated you jack the prices up. Doing it to be nice to customers can potentially last even after competitors go belly up. Then again, Google's motto used to be "do no evil" (basically be nice to customers). That obviously went the way of the dodo bird.
>>As soon as the competitors are eliminated you jack the prices up And then you provide a competitor or startup another opportunity.