Hacker News Reader

Comment by voidwtf | Hacker News Reader

That's my favorite thing about all these services. None of them have an equivalent of a stop-loss. They'll notify you IF you setup an alert, but that's it. Often times the alerts are way after the damage is done, with some billable metrics often lagging in reporting/alerting by hours. The default should be safe with easy options to increase the limits.

View on HN

I remember trying AWS Glacier as a broke university student, thinking it was a cheap way to back up my data. I was wrong.

A decade later I played around with AWS, set up a free 1-core VPS. It was fine for a year or so (I ended up not using it at all), and suddenly I got a bill. It wasn't much, but it reminded me how these services make it very hard to be aware of your bills until you get them.

I was trying out Azure recently, and I found it too confusing to make any sort of quick risk assessment.

It's clearly just for people for whom "What's the worst that could happen?" is always a rethorical question.

Glacier IS a cheap way to backup data, in fact the cheapest of you ignore the scam "$200 for life" type things. It's about $1 per TB per month.

It's not cheap to restore though, at about $90 minimum per TB.

So it's best as part of a 3-2-1 system, not for frequent restores.

Lambda and GCP Cloud Functions do have cost controls. You can specify the maximum number of instances that can be spun up at any given point.

I think the UX can make it more friendly to specify the types of traffic and cost you’re expecting but most erroneous spikes are the result of a customer misconfiguration or a legitimate spike in traffic.

It’s the former which are problematic for customers. They can request a credit and we (GCP) try and accommodate.

It’s not a feature designed for profit. But it also tends to fall below the cut line for prioritization to fix. But it’s in the backlog and doesn’t go unnoticed.

(Former PM on GCP Cloud Functions)

Do users setup cost controls before activating the service? Or is this something they need to know how to do and do on their own?

Separate from billing, the product-native cost controls which prevent over-consumption is configured at the resource level.

gcloud run deploy ..... --max-instances=N

You can totally build a GCP function that will tear down your site if a billing alert hits the pubsub bus, but you can also set billing caps for a bunch of the APIs.

Why not add it directly into the interface where you configure the site to begin with? It's a pretty reasonable ask.

I don't really know although I can make up an answer but it contradicts

> None of them have an equivalent of a stop-loss.

Cynically, it's because they want to take your money. Practically, it's because a company that breaks your thing because you didn't pay, even if you asked it to, just isn't going to be a popular move.

It takes real leadership to back a product feature like this. That's why.

It's probably quite difficult to boil it down to something as simple as an "off" switch that'll limit costs for them, meaningfully work for all services, not be abused, not be confusing, and not result in the customers that actually make you money accidentally getting important things shut off unexpectedly under predictable circumstances.

It's probably easier to make it so they can set up alerts and have a human on their end evaluate what steps are worth taking to cut costs while maintaining important availability.

From what I can tell Azure has more robust stop-loss options. But business considerations for the provider aside, there are absolutely tradeoffs between reliably limiting your spend and avoiding taking a business down because of a legitimate spike.

Absolutely but that tradeoff should be for the customer to make.

What you're saying is that I can build a cost control function, not that GCP has one.

Yes. GP's claim is there is no stop procedure. just because it's not a simple toggle switch doesn't mean it's not there.

oooh i really like that stop loss example. having a netlify serverless website is basically selling a put option without receiving any premium.

The premium is the website itself ;D Still, potentially unlimited costs is wayy too much risk.

Selling a put has a fixed downside, so perhaps selling a naked call would be more appropriate? Unlimited loss potential! :^)

What you really want is prepaid instead of post-paid billing. Charge up the account with $100, and stop working and delete my data if that gets hit, with an auto renew option to recharge some amount every month.

That seems a little reductive. I don’t think it’s unreasonable to say, my current spend is ~13k a month. I should be able to set a 20k cap, such that non fixed billable like bandwidth or map tiles get paused while someone determines whether we’d like to proceed at that rate. There is a not so fine line between scaling for a rush/event and a resume generating event.

Okay, fine, that's what I want. :)

Reply on news.ycombinator.com