Hacker News Reader

Comment by steren | Hacker News Reader

(Cloud Run PM here) I am sorry for the experience described in the blog post, we could definitely be better at bill management. I am glad that it worked out in the end and the customer was not required to pay for the bill.

Based on this experience, we decided to lower the default value of "max instances" to 100 for future deployments. We believe 100 is a better trade off between allowing customers to scale out and preventing big billing surprises. Of course, customers can always decrease it or increase it up to 1,000, or even above with a simple quota increase request.

View on HN

Well, the real question for all cloud providers, for which I expect crickets as an answer, is:

Why don't cloud providers allow setting a budget which cannot be exceeded? A simple, 1-click way to say: this account should never go over $500 a month. Just stop creating resources or responding to requests if it does.

AWS recently released AWS Budget Actions which should allow you to do that.

https://aws.amazon.com/blogs/aws-cost-management/get-started...

It still looks rather complex but if it can actually enforce a budget, that would be great.

My guess is that the billing logic is separate from the application logic. There's probably a delay between the two and mostly one-way communication.

1) But they supported this before on GAE. GAE had 'spending limits'.

2) Also if they are able to figure out when you've hit your daily free quota and cut you off almost immediately, how are they not able to figure this out?

If I recall correctly, GAE is an example of something they made specifically to be a cloud product. Products like Compute Engine, GCS, Bigtable, and Pub/Sub are things developed internally and then sold publicly once they realized others might find them useful. Perhaps the products developed first for internal use weren't developed with features like measuring billing usage in real time in mind.

This is a outage waiting to happen for every customer:

- Early dev sets a limit.

- Product launches.

- Slowly grows.

- One day suddenly the entire business grinds to a halt. Globally. Across the carefully isolated shards. Everyone scrambles to figure out why! Tens of thousands of dollars are lost because of going $10 over a budget. End-users are lost. Trust is burned. If it's providing a critical system, maybe even people are hurt.

- Google then has to explain why they built in instant, global failure mode.

They can put it behind a clear warning, do stuff like AWS does for bucket deletion (the bucket has to be empty, you have to check a box and manually type the full name of the bucket).

There are ways to design this, they can send notifications at 60% of the threshold, 80%, 90%, 95%. They can give you a grace period, put up prominent warnings in the console and for command line tools, etc. There are ways to do it, it's far from an intractable problem.

I'm not saying that it can't happen but do you want to bet that a certain percentage of their business, for all cloud providers, is from carelessness and resources still running when they shouldn't or using more than they expected? Especially for bigger companies where it's easy to miss something. Just like gym subscriptions or other kinds of subscriptions where they're banking on you not noticing for a long time ;-)

So ?

This is would be one more checklist that you need to regularly review, just like domain name registration and certificates, ...

Any of those expiring will cause outage also.

Outages happen. Will happen. This just one more way that they can happen. It happens you learn and move on.

Hell even the biggest providers with the beset admin teams on the planets have outages.

And Google doesn't need to explain anything just like your name register doesn't have to explain anything if you cc was declined/not current ...

> Based on this experience, we decided to lower the default value of "max instances" to 100 for future deployments. We believe 100 is a better trade off between allowing customers to scale out and preventing big billing surprises.

This is good to hear. I use Cloud Run a lot for personal projects and I always set concurrency to 80, max instances to 1, memory to 128Mi (unless it's something beefy that needs the memory), and CPU to 1. If I need to scale it up, or I decide to open it up to actual usage, I'll do it when I recognize the need.

Why don't you just allow customers to set a limit if they would like to?

Reply on news.ycombinator.com