Hacker News Reader

Comment by joshvm | Hacker News Reader

You can set up alerts if you exceed a budget, and you can program a response to turn off billing on a project. Google has a guide for doing exactly what you want. It's not a particularly clean fix, but it is fairly easy (copy paste) and can be done. It also allows for fine grain control eg you could kill an expensive backend process but keep the fronted running.

You can also rate limit some APIs.

https://cloud.google.com/billing/docs/how-to/notify#cap_disa...

> You might cap costs because you have a hard limit on how much money you can spend on Google Cloud. This is typical for students, researchers, or developers working in sandbox environments. In these cases you want to stop the spending and might be willing to shutdown all your Google Cloud services and usage when your budget limit is reached.

View on HN

Is this not typical for...literally every use case? No one has an unlimited budget.

Depends - if your profits increase in line with your expenses, you might be raking in the ad revenue/views/sales/whatever because your product 'went viral' and you might prefer to keep it up.

Or if the rise in costs is something you can mitigate on your end - such as a bad deployment - you might want time to respond yourself, rather than your site going offline.

More generally, few site reliability engineers are looking to add extra ways for the site to be taken offline.

Of course, if you're large enough to be in those situations, your round-the-clock operations staff will be monitoring the billing situation as carefully as they monitor page load times and error rates and database load so an unexpected bill will be very unlikely.

> few site reliability engineers are looking to add extra ways for the site to be taken offline

If your company has anything close to "reliability engineers", then you already have legal and finance teams too that can sort terms out.

The discussion is about companies that do not even have departments to begin with.

> More generally, few site reliability engineers are looking to add extra ways for the site to be taken offline.

SRE 101 is rate limiting everything and protection against DDoS. With cloud and auto scaling risks of DDoS are less about uptime but more about getting a bill that will bankrupt the business.

> few site reliability engineers are looking to add extra ways for the site to be taken offline.

Apart from the cases already mentioned in sibling comments, at some scale you start adding in outage switches in many cases. Basically quick ways to take parts of your service offline if something starts misbehaving.

Sure, but typically a business will have specific resources they’d be willing to shut down rather than the entire billing account.

Google themselves recommend using the limits like max instances to mitigate the risk of out of control costs.

I also don't understand why this is being framed as a uniquely Google problem. Other cloud providers with serverless services have similar hazards and similar methods to manage the risk.

Google doesn't have good enough billing systems to be able to guarantee to be able to limit your spend. Lots of billing things are only done daily for example, meaning you could spend millions of dollars before the billing run at the end of the day.

Google prefers you be on the hook rather than them.

Reply on news.ycombinator.com