[georgyo]

Indeed. Using another service and being a wrapper around it is not all that impressive. He is also using workers which makes his solution expensive.

I run ifconfig.io which now gets just over a billion hits a day. It is basically an echo service, and it just parrots back what cloudflare tells it. But since I run it on linode, it costs me a whopping $40 dollars a month for 35 billion returns a month. Using workers would cost me several thousand dollars.

http://ifconfig.io/country_code

[johnsoft]

Your service has a response time of 20-30ms (from one of my servers, at least). So on top of everything else it's faster than OP too. Great example!

[mongo-db-hater]

Thanks for sharing. This is a perfect example which proves lambda/serverless/cf worker are snake oils.

[iforgotmyaka]

It's not.

If under 10 million requests per month, serverless will be cheaper and safer

Else if under 1 billion request per month, managed VPS will be cheaper

If over hundred of billions of requests per month, anything else than on premise is probably an error.

Then you have grey areas where you need to process.

But for most small project, you cannot beat the lambda prices. Especially if you expect bursts.

[tslover]

the issue with you calculation is that you are trying to save $40 a month by spending 100-500 person hours and screwing your code base.

[foepys]

But if I expect bursts, Lambda could potentially cost me a few thousand dollars in a day while my own instance could handle it fine for like $50. Even paying $50/mo over a few years would pay off in that case.

[mongo-db-hater]

Exactly. developer time lot more expensive. most people want to look cool & do cool things so they drink these cool aids.

it sounds lot cooler to say that " i made geolocation service using serverless/lamba" than "i made geolocation service using boring monolithic technology". where the former takes 150 hours to get it right and painful to add/manage features. where the later is very easy to maintain and very predictable priced.

[wooly_bully]

There's TONS of use cases for Lambdas where the operational costs (both in terms of time/energy/expertise and to lesser extent monetary) of running something persistent are much higher.

In my last gig, we ran plenty of services that would never need to scale and would likely never hit the point where Lambda became too expensive. Low-utilization services (Example for order submit, because we only ever got a couple hundred orders per day), Cron-type jobs (Admins could use Cloudwatch to monitor), Temporary fan-outs using queues. Anything that won't ever hit the millions-per-day level is a good candidate for something along these lines. Most of those services cost <$5/month.

[dclusin]

I think there's situations where Lambdas make sense in spite of their pricing. I applied for a job on the Warren campaign and their tech stack relied on AWS lambdas. I think that makes sense for them. It's a short-lived endeavor that isn't going to be around next year. Spending a bit more to not have to deal with the headache of maintaining your own infra makes sense in scenarios like that.

[freehunter]

If that’s your opinion I’d like to hear your rebuttal to this [1]. It’s hard to argue against actual numbers for an actual production app running at actual scale.

[1] https://www.troyhunt.com/serverless-to-the-max-doing-big-thi...

[mongo-db-hater]

if you are spending 279 using complicated cloudflare worker/azure function setup, you could have gotten away with $100 month if you have choosen linode/droplets.

32 million requests can be easily served with $50/month heroku node.

[freehunter]

I think you massively mis-read the article. $279/mo is what he would have spent. What he actually spends is under $1/mo. Sure a $50/mo Heroku box would do the trick but why spend $49/mo MORE when serverless is cheaper?

What I want to hear is how you argue serverless is “snake oil” when evidence says it’s massively cheaper even at scale. Less than $1/mo to serve 141m requests. How is that snake oil when even you say an equivalent “serverfull” solution costs 50x more?

[mongo-db-hater]

Well, not exactly

1. You are saving $49 month by spending 250+ hours engineering hours to structure the application which is near impossible to extend/maintain.

2. The $49/month subsidy (free tier) you are getting is temporary and will eventually go away (think about google maps api price change).

3. 50x cost for serverfull solution is not a right number. lets say you have to handle 500M requests per month (around 200 QPS) the 50x becomes .000X.

4. If there is any sudden spike to popularity, you are screwed. you will end up paying several thousand $ per month.

[freehunter]

But see, none of that is true. Everything you just said is misleading at best and completely false at worse. Especially the part about the free tier. This isn’t the 12 month free trial, this is the “free forever”. Sure prices can change but they can change for servers too. That’s no different, and you can’t waste time/effort trying to engineer a solution for a problem that doesn’t yet exist and may never exist.

I think I’ve heard enough to say you have no idea what you’re talking about and this conversation has become pointless.

[vangelis]

There's a cost curve lambda excels at. For services handling under 100 requests a second it's cheaper than a cheap EC2 instances.

[mongo-db-hater]

choosing EC2 was probably mistake, may be linode would have been better choice here.

[mkoryak]

Have you considered not including the entire bootstrap.css on the front page since you only use about 1% of it :)

[georgyo]

I almost never do frontend work. I'll gladly take a PR if you want to make that one page faster and prettier. Though I don't want to make the build require yarn or other js/css compiler framework for a single page.

[mkoryak]

if you give me a github repo, ill see what I can do

[georgyo]

Sure! https://github.com/georgyo/ifconfig.io/blob/master/templates...

[hazelnut]

I would assume the majority (99.9%) of the requests is actually API calls without delivering CSS.

[georgyo]

Indeed. Only ~30k page views that trigger the google analytic script, so 99.9991% of requests have no html at all.

[fr33k3y]

Exactly!. I was about to tell a similar story but yours is MUCH better. I run an internal service that just loads (a filtered version of) the maxmind geolite2 db in memory using it's great C library bindings for perl and on top of that I fork (so memory is shared) a mojo server and it's able to serve millons of reqs per hour on a very small vm. Response time is not much more than a "hello world"...

[fletchowns]

Hey I use ifconfig.io all the time! Thanks for the handy service. Really cool that you are able to handle that much traffic for so little $.

[moneywoes]

Sorry silly question, still learning. Can you talk about how your linode setup is? Do you report back the same fields?

[georgyo]

It's just a normal linode running archlinux. There are very minimal tweaks to handle the new connection load.

I should write a blog post about it. It has steadily gained more traffic over the years and hasn't need much care and feeding.

The go code can be found here if you're interested, though it some of the ugliest code I've written. I made it when ifconfig.me was having load issues many years ago.

https://github.com/georgyo/ifconfig.io

[jjice]

I love the simplicity. I'm sure I could find similar source code for similar services that is way over engineered and doesn't perform nearly as well. Do you serve this with a reverse proxy in front, or just as is? I'm assuming as is since you have the TLS configured right in the code, but I figure I'd ask.

[georgyo]

Having a reverse proxy on the same machine effectively doubles the amount of connections and requires coping the request around. There is no practical benefit to a reverse proxy for this use case. So the go program is listening directly on the internet.

I do have the service behind CloudFlare, which is essentially a reverse proxy. The reason is for CloudFlare is non-obvious; it is deserves a blog post, and that is connection pooling.

If I have all the requests go back to the origin, the bottle neck is not the go code, but Linux opening and closing all those single use TCP sessions. CloudFlare creates around 100k persistent connections to the backend, but then just keeps them open. This makes Linux much happier.

The high connection count actually made the service unstable once: https://github.com/georgyo/ifconfig.io/issues/2

[joeraut]

Great service, thanks for running it!

[tyingq]

He could have used the CF cache API in the worker, which would drop the cost quite a lot.

[georgyo]

How would it reduce the cost? They are only return data from inside the header of the request they received and doing (an unnecessary) lookup to turn the country code into a country name.

What would you cache it cheaper?

No matter what his worker needs the smallest time/memory slot there is. You cannot make it cheaper while still using workers.