4 ms·

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

I just did some math on their calculator: https://cloud.google.com/products/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.

starptech 7y ago
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.
- unexaminedlife 7y ago
  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.
franciscop 7y ago
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 :)
- unexaminedlife 7y ago
  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.
chewz 7y ago
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.
Aeolun 7y ago
Just loading the Javascript for a basic React app is way over 100kb though.
- zebnyc 7y ago
  Wouldn't it be better to do that over S3 / cloud storage? And would be much smaller once minified and compressed
- onion2k 7y ago
  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.

starptech 7y ago

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.

unexaminedlife 7y ago
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.

franciscop 7y ago

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 :)

unexaminedlife 7y ago
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.

chewz 7y ago

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.

Aeolun 7y ago

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

zebnyc 7y ago
Wouldn't it be better to do that over S3 / cloud storage? And would be much smaller once minified and compressed
onion2k 7y ago
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.