Hacker News new | ask | show | jobs
by rjh29 970 days ago
> Edge functions are cost-effective as you only pay for the actual CPU execution.

> We have over 1000 monitors, and the monthly cost to run them would be $150.

> While on fly we only have 6 servers with 2vcpu/512Mb It cost us $23.34 monthly ($3.89*6).

So edge functions are in no way cost-effective right? People using lambda functions are getting ripped off, they could just buy a couple of VPS.

5 comments

> People using lambda functions are getting ripped off, they could just buy a couple of VPS.

A non-zero amount of our CICD pipelines are "perform API call with secret pulled from SSM/Secrets Manager". They happen 1-2 times per day and take less than a 5 seconds to run on each invocation. We currently have a burstable EC2 instance running 24/7 to handle these which costs us ~$5/mo. My napkin math says that this would cost us ~$0.01/month to run these as lambdas. More to the point though, we're limited in concurrency on these. It's pretty common that they all get triggered at the same time, it would be ideal if we could allow for an "unlimited" number of these to run. This sort of workload would be great to run for lambda functions, the engineering cost of implementing it just doesn't ever make sense.

If we paid someone $150/hour to spend half a day on it, right now our break even point is probably 5 years...

Also, if you implement it as lambdas, your solution is now less portable. Your EC2 instance can probably be ported to something else easier than some lambda solution.
This is objectively false. In fact, it's the opposite of true. Lambda forces you to have a single entry point to your code that passes the details of a request to your application in a structured way. Wrap that in the http server of your choice in about fifty lines of code and you're done.

Or, you use something like Express inside Lambda with Serverless and adapting it to a long running server is literally just deleting the fifty lines of code that export your lambda handler. It couldn't be more simple.

Which is to say, you'll almost always have more trouble going from something else to Lambda and not the other way.

> Wrap that in the http server of your choice in about fifty lines of code and you're done. > Or, you use something like Express inside Lambda with Serverless and adapting it to a long running server is literally just deleting the fifty lines of code that export your lambda handler. It couldn't be more simple.

...which is all extra setup that you need to do compared to if you weren't using lambda, in which case you'd already be set up using something like express. To be fair, it doesn't like it'd be too much work to do the conversion. But it would still be extra work compared to say moving something running on express and deployed in a container to another VPS and/or container hosting provider which would likely require no application changes at all.

There are services that offer compatible APIs to Lambda, in which case there's also no effort.

You could be switching from an integrated http server to using WSGI, which is almost identical to the effort I described. Who cares about the twenty minutes of work? It's "less portable" in such a trivial way.

> This is objectively false. In fact, it's the opposite of true.

I apologize for the tangent but in your mind, is false sometimes but not always the opposite of true? Or is this just emphasis? (Genuinely asking, not being snarky.)

ETA: Thanks for clarifying.

Something being wrong does not mean it is the exact opposite of what is the truth.
That's for abstractions to take care of. If my CI platform offers a lambda runner instead of an ec2 integration, I would use it in a heartbeat.

Also, it's a 5 line shell script that already depends on 2 AWS services (SSM and IAM) that makes an API call to a third AWS service (S3). It's already locked to AWS

I'm guessing the original developer was only $50/hr with a cheap, non-scaling setup like that.
I wrote it. It was a 50 line packerfile with a shell script that installs buildkite, docker, and the AWS cli, and hasn't been touched in 2 years other than bumping version numbers.
Edge functions are cost effective, the problem is that they are comparing from Vercel.

Vercel is basically a dev friendly wrapper for tier 1 services: https://news.ycombinator.com/item?id=35774730

Eg. Vercel is 25x more expensive than eg. Cloudflare Workers. Raw guess would be that their 150$ bill would have become 6$.

https://news.ycombinator.com/item?id=37891412

Eg. Image resizing

> Vercel : 5$ / 1000 requests

> Cloudflare : 9$ / 50.000 requests

Edit for comment below:

That's a blog post. I got my info from here:

https://www.cloudflare.com/plans/

See: image resizing

> 50,000 monthly resizing requests included with Pro, Business. $9 per additional 50,000 resizing requests

$5 / 1k requests... wow. That's like, entirely unworkable for almost all use-cases surely?

Even coming from a backend-heavy world where one request does a lot of work, that's got to be an order of magnitude off the mark at least. If you go for a frontend-heavy setup where there are more smaller requests (in my experience, common, when using things like Lambda), this could be another order of magnitude off again!

Sorry about that. The pricing was about Image Resizing requests ( updated my comment).

On http requests itselve.

Vercel is 2 $ per million requests. Cloudflare is 0,15$ per million requests.

So Cloudflare in this case is > 13 x cheaper.

According to this page at Cloudflare, their pricing is 50 cents per 1000, is that correct? Or is it a different product... https://blog.cloudflare.com/merging-images-and-image-resizin...
50,000 monthly resizing requests included with Pro, Business. $9 per additional 50,000 resizing requests

https://www.cloudflare.com/plans/ - section: image resizing

Workers are also free for the first 100k every month I believe.
10 million included per month.

On the free plan, it's 100 k. per day included - https://blog.cloudflare.com/workers-pricing-scale-to-zero/

Oh, even better. Thanks :)
The free tier gets 100k requests per day, not month. And then for $5 you get 10M or 1M free a month depending on your settings and then you get charged for additional usage.
If you're bursty and only run 1000 invocations every few days or weeks and otherwise you run it 0 or 1 times per increment then you can end up spending a lot less than that estimated server cost with fly.io no?
Definitely there will be cases where it makes sense. But intuition would suggest if your servers are say 80% idle then serverless functions would be cheaper, but that isn't actually the case. Cloud companies don't incur much of a cost from a VPS either if it's idle.

My team noticed the same with AWS Aurora Serverless (a database), it was so expensive that it was easier to just run a normal instance of RDS.

In what universe is the difference between $23/mo and some amount less than that incomparable? That's what? Two paid users worth of revenue? $23 per month is a rounding error. It's one T-shirt. It's the cost of a few minutes of your time. If you're running a business and you're worried about saving ones of dollars on hosting, you need to reconsider how you're spending your time and how your business makes money.
unless you remove the need for said server then you save on reduced complexity/maintenance which is money
Both are free for business,