4 ms·

> If you deploy this app with 128MB RAM and 1 vCPU today, it will cost (0.00002400 + (0.00000250/8)) * 60 * 60 = $0.0875 per hour per instance. 1 This means if

by syspec 6y ago

> If you deploy this app with 128MB RAM and 1 vCPU today, it will cost (0.00002400 + (0.00000250/8)) * 60 * 60 = $0.0875 per hour per instance. 1 This means if you have 1,000 instances actively running and serving 250K clients, it will cost $87/hour, which is $62.6K/month. > Any Cloud Run service, by default, can scale up to 1,000 instances. (However, by opening a support ticket, you can get this number elevated.) This means we can support 250,000 clients simultaneously without having to worry about infrastructure and scaling! Aren't these statements at odds with one another?

monsieurbanana 6y ago
I don't see why, maybe you can elaborate?
- neolog 6y ago
  Because that's a lot of money.
  - monsieurbanana 6y ago
    Is it the "without having to worry about infrastructure and scaling" that you disagree? I don't personally find the two statements at odds. If you have 250k connections 24/24 7/7 for a whole month, that should mean your business is generating more than enough money to cover the cost. Or, at the very least, that the losses by not being able to scale are higher than the cost of the infrastructure. If this is false and you'll be bankrupt by those 250k connections, you should obviously not let your instances to scale that much.
    - neolog 6y ago
      It's still a lot of money even if it won't bankrupt the business.
- reilly3000 6y ago
  Scaling limits put in place by cloud providers are there in part to make sure their customers don’t accidentally incur runaway costs due to a configuration mistake. It’s not uncommon that a cloud provider would cover the costs if a customer make such an error (first time, ask nicely, etc). They are covering their own bases from having to do that on a massive scale.
jijji 6y ago
or you can pay $80/month at a co-lo facility and host your own big box and do millions of simultaneous connections...
reilly3000 6y ago
This estimate misses the entire benefit of Cloud Run which is metered compute billing. Nobody in their right mind would run a serverless stack if they had 250K connections 24/7. It’s specifically documented that it isn’t for long-running processes, just for event-based apps. More realistically you’d get 250k requests, serve them with a total of ~5 container instances, and then the billing stops 5 seconds later. It’s cheap. It’s not for websocket apps. It’s perfect for MVPs and spiky traffic. It’s an easy path to move the hosting to K8s, App Engine, or normal VMs (GCP VMs can just run containers with minimal config), which are all far better choices if traffic is predictable. I think this is a far more valuable model than Function-as-a-service, where the runtime environment is strictly defined. Since “it’s just containers” you could write a web server in brainfvck if you felt like it, write a tiny dockerfile, then ‘git push origin/main’ and Cloud Run gives you a running endpoint. Okay, there is some devops work to set up that pipeline, but that is mostly boilerplate. It’s Heroku but it scales down to zero (ie free) and up to 1000+ instances of your server in ms.
nawgz 6y ago
1000 instances with 250 concurrent connections each is 250k, but I fear I may be missing your point
- ALittleLight 6y ago
  I think the point is that one sentence says you don't have to worry about scaling and the next sentence shows scaling is very costly implying you do have to worry about it.

by syspec 6y ago

monsieurbanana 6y ago

I don't see why, maybe you can elaborate?

neolog 6y ago
Because that's a lot of money.
- monsieurbanana 6y ago
  Is it the "without having to worry about infrastructure and scaling" that you disagree? I don't personally find the two statements at odds. If you have 250k connections 24/24 7/7 for a whole month, that should mean your business is generating more than enough money to cover the cost. Or, at the very least, that the losses by not being able to scale are higher than the cost of the infrastructure. If this is false and you'll be bankrupt by those 250k connections, you should obviously not let your instances to scale that much.
  - neolog 6y ago
    It's still a lot of money even if it won't bankrupt the business.
reilly3000 6y ago
Scaling limits put in place by cloud providers are there in part to make sure their customers don’t accidentally incur runaway costs due to a configuration mistake. It’s not uncommon that a cloud provider would cover the costs if a customer make such an error (first time, ask nicely, etc). They are covering their own bases from having to do that on a massive scale.

jijji 6y ago

or you can pay $80/month at a co-lo facility and host your own big box and do millions of simultaneous connections...

reilly3000 6y ago

This estimate misses the entire benefit of Cloud Run which is metered compute billing. Nobody in their right mind would run a serverless stack if they had 250K connections 24/7. It’s specifically documented that it isn’t for long-running processes, just for event-based apps. More realistically you’d get 250k requests, serve them with a total of ~5 container instances, and then the billing stops 5 seconds later. It’s cheap. It’s not for websocket apps. It’s perfect for MVPs and spiky traffic. It’s an easy path to move the hosting to K8s, App Engine, or normal VMs (GCP VMs can just run containers with minimal config), which are all far better choices if traffic is predictable. I think this is a far more valuable model than Function-as-a-service, where the runtime environment is strictly defined. Since “it’s just containers” you could write a web server in brainfvck if you felt like it, write a tiny dockerfile, then ‘git push origin/main’ and Cloud Run gives you a running endpoint. Okay, there is some devops work to set up that pipeline, but that is mostly boilerplate. It’s Heroku but it scales down to zero (ie free) and up to 1000+ instances of your server in ms.

nawgz 6y ago

1000 instances with 250 concurrent connections each is 250k, but I fear I may be missing your point

ALittleLight 6y ago
I think the point is that one sentence says you don't have to worry about scaling and the next sentence shows scaling is very costly implying you do have to worry about it.