I applaud your efforts but it's disingenuous to title this how you "made a geolocation service" when you are just reading a field in someone else's geolocation service.
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.
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.
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.
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.
[1] https://www.troyhunt.com/serverless-to-the-max-doing-big-thi...
32 million requests can be easily served with $50/month heroku node.
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?
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.
I think I’ve heard enough to say you have no idea what you’re talking about and this conversation has become pointless.
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.
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.
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
It's a nice solution. Why log into your alt account to crap on it?
I'm trying to learn to take it as the highest form of compliment - when hackers care enough to hack on one of my ideas, that means it has to be cool.