Hacker News Reader

Comment by unexaminedlife | Hacker News Reader

I just did some math on their calculator: https://cloud.google.com/products/calculator/

I think some folks may be overestimating their ability to put a dent in Google's infrastructure.

  1 CPU
  2GB memory
  80 concurrent requests per container instance
  1000ms execution time per request
  5kb outbound network bandwidth per request
  100 million requests per month

$120.19 per month

What if we bump it up to 100kb per request? In my experience only initial requests end up being enormous, especially in single page apps. But to be fair some folks may not have time to optimize. That still only brings the monthly bill to $1,071.48

Then again that second estimate probably isn't relevant since I typically host my static data on a CDN.

View on HN

I'm not from the US, and the thought of "only" paying $1071/m for a side project which is most likely not generating revenue is mindblowing.

If you give me $1071-$120 = $951/month forever for optimizing an app once I'll optimize it for you :)

I can't say it's "only" $1071/month. I definitely wouldn't go broke because of it though. Especially if it's only a side project I probably would look for ways to reduce cost for subsequent months.

I don't know how optimizing comes into the equation. The app you build and deploy to Google Run leverages their infrastructure. A fiber optic cross (with just one telecommunications company) connect would cost probably close to $1000/month alone, but Google is probably peered with every telecommunications company in the entire world, and they don't have just one fiber optic line connecting to each of them. So, it's not really a one-time optimization when you put your work on Google. It's like I would be paying Google $1071 to rent the infrastructure of their entire network to receive and distribute data in my name.

Silly me I have last week made an infinite loop on Firestore - update to document triggered CloudFunction which updated document and Firestore is fast..

In just minutes I had passed free quota and here I have been lucky because I have checked console.

If I have left that version (and I have been sure it is just innocent commit) for a few hours running I would be up for a surprise.

Your setup is unrealistic. 100 million requests per month with 80 concurrent requests?. 1000 $ is cheap if you try to run wikipedia.com fully managed.

A lot of web stacks optimize for concurrency. Based on 2GB memory, which ends up being ~25MB per request (which for me is extremely high), I don't see it as being unrealistic. Especially for the use case I'm considering. Typically the only reason these boxes exist is to allow a web browser to gain access to data in a database, so most of the 1000ms per request wouldn't be spent in CPU, it will be spent waiting for the database to return a response.

Just loading the Javascript for a basic React app is way over 100kb though.

It's 6kb for React and 25kb for React-DOM if you do a production build. Still a lot in terms of JS, but not quite as much as you're saying.

Wouldn't it be better to do that over S3 / cloud storage? And would be much smaller once minified and compressed

Reply on news.ycombinator.com