Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accident Forgiveness

fly.io

Post reply on HN
Print view View original

101–110 of 310 posts

Re: Accident Forgiveness

#101

Post by alpinisme »

aidos wrote: post #50
tptacek wrote: post #43

Earlier quoted context omitted.

I promise, you are not the first person to have thought of this, and, believe it or not, there are reasons other than malice and avarice that cloud providers don't terminate service based on billing caps. Terminating service is a big deal. We agree completely about surprise billing.

Having flashbacks to the time where we had paid for a server and were paying for rack space for a customer and they were refusing to pay their bill. Our lawyers told us in no uncertain terms that turning off the server would be a terrible idea. “Obstruction of service” is the term that comes to mind.

While the parent point about cloud providers having arrived at their policies thoughtfully, this particular issue is likely not part of the equation. There are plenty of services that run on a quota system (chat gpt, sentry, etc). There is a difference between shutting off a service the customer reasonably expected to be always on and shutting off a service when it reaches a threshold set by the customer as part of their purchase. The former is more like repossessing a physical good willy-nilly if the customer misses a payment or you find a check bounces…you can’t do that.

Re: Accident Forgiveness

#102

Post by mappu »

tomjen3 wrote: post #11

I really, really wish there was just a way to put a hard limit on how much a cloud could charge me. I am never going to want to spend 200k of my personal money on some project on a cloud. Never. I don't even want my ant-based basket viewing project simulator to cost me 1 thousand dollars because it went viral and all clouds overcharge for bandwith. Just let me put in a limit.

You might be happier with a fixed-size VPS, instead of a cloud provider,

Re: Accident Forgiveness

#103

Post by dlisboa »

belthesar wrote: post #95
tptacek wrote: post #74

Earlier quoted context omitted.

I've said it over and over again: if you have a serious app, and someone somehow steals a credential from you and uses it to light up a bunch of crypto miners, you don't want us shutting down your main app in response. We perceive it mostly as a feature that will blow people up. We agree about the underlying problem! You don't want to spend $5000 in a month for services you never wanted. We don't want you spending th…

I'll be honest, I think you've got an uphill battle to convince so many of us that are concerned about accidental pricing that this is exactly the thing we actually want, vs. what we feel we want. This position parrots what Vercel's leadership said when someone had a massive surprise bill, and the story made the rounds both here and elsewhere. To be super honest, you might be right too. You might go down a huge engin…

> You might go down a huge engineering effort to build this

This is an overlooked issue: billing caps are hard to implement and will likely incur losses for the cloud company that does.

Take an object storage service as an example. Imagine Company X has a hard cap at US$ 1000 but some bug makes their software upload millions of files to a bucket and rack up their bill. Since objects are charged in GB/month they will not reach the cap until some time later that month. Then, when they do, what does termination of service mean? Does the cloud provider destroy every last resource associated with the account the second the hard cap is reached? If they don't, and they still have to store those files somewhere in their infra, then they'll start taking a loss while Company X just says "oops, sorry".

That's what tptacek is talking about: you want to NOT destroy the customers' resources because they can quickly figure out that something went wrong and then adjust while still maintaining service. But the longer you keep the resources the more you're paying out of pocket as a cloud provider. If you can't bill the overages to the customer, which a hard cap would imply, then you're at a loss. Reclaiming every resource associated to an account the moment a cap is reached is an extreme measure no one wants.

A hard cap then becomes only a "soft" cap, a mere suggestion, and cloud providers would then say "you hit the cap, but we had to keep your resources on the books for 12 hours, so here's the supplemental overages charges". Which would lead to probably just as many charges disputes we have today.

Re: Accident Forgiveness

#104

Post by jameshart »

moring wrote: post #59
karmajunkie wrote: post #45

Earlier quoted context omitted.

The only thing in cloud that's worse than a surprise bill is a surprise outage.

This made me think. There is usually some "hard" cost limit X that you cannot / don't want to afford, so terminating the service is preferable. There is also usually some "soft" limit Y Y than face an outage. But a hard limit would have to be set to X to avoid that outage, and if it gets exceeded, you'll face a bill of X and an outage. So what a customer would actually need is to specify both X and Y, with the rule:…

It would, of course, be just mean and unscrupulous for a cloud vendor to look at the number you have set as being ‘the absolute most I am willing to pay for this service’ and then optimize their pricing offer to you specifically to make sure they go right up to that line and no further.

Re: Accident Forgiveness

#105

Post by DAlperin »

joshfraser wrote: post #98
trjordan wrote: post #83

Earlier quoted context omitted.

The servers are already bought; the electricity cost is negligible for actual accidents. As mentioned in the post: the hosting providers don't actually pay marginal costs for transient mistakes, so neither should honest customers.

And what about the extra costs fighting fraud now that they've advertised this policy?

We have to invest in fighting fraud and abuse anyway, such is the public cloud business. We don't intend to diminish user experience in service of fighting it.

Re: Accident Forgiveness

#106

Post by csours »

> " You probably can’t tell me how much electricity your home is using right now, and may only come within tens of dollars of accurately predicting your water bill. But neither of those bills are all that scary, because you assume there’s a limit to how much you could run them up in a single billing interval. "

I had a $600 surprise water bill. It was (partially) forgiven because the water department could drive to my house and see evidence of the leak next to my water meter. It did turn out to be on my side of the meter, so it is my responsibility.

If the water department had driven to my house and seen evidence of commercial agriculture (so to speak), then it would not have been forgiven.

---

The parallel here is that the water department can't come into my house uninvited - the cloud provider SHOULD NOT have intimate access to the running code, but they are able to observe some patterns without 'breaking in'.

---

Side note: the size of the bill and the amount of forgiveness was largely driven by waiving an 'excess usage' surcharge - similar to how you can get a discount for cloud service reservations.

Re: Accident Forgiveness

#107

Post by amirhirsch »

tptacek wrote: post #71

Y'all really, really want caps. We think that's a crazy feature. We don't want to do it. But I just had this conversation on a Slack with a bunch of friends at other companies and they were just as yell-y about this. There's a threshold of feedback at which I think you could get us to do some kind of cap thingo. I'm just saying. Yeesh.

Sounds like I should just DM Kurt until it happens?

Re: Accident Forgiveness

#108

Post by lilyball »

tptacek wrote: post #74
ustad wrote: post #73

Earlier quoted context omitted.

In your article or in the posts here you have not said why you think its a crazy idea.

I've said it over and over again: if you have a serious app, and someone somehow steals a credential from you and uses it to light up a bunch of crypto miners, you don't want us shutting down your main app in response. We perceive it mostly as a feature that will blow people up. We agree about the underlying problem! You don't want to spend $5000 in a month for services you never wanted. We don't want you spending th…

I'm pretty sure I'm fairly far from your target customer, given that I'm not building products, and right now my only usage of fly.io is to host a tiny app that expects to be used a few times per year by my spouse and me.

Having said that, the reason why I personally would be happier with the ability to set a hard cap is that if I'm going to put a project on fly.io, I'm spending my own personal money on it. If I'm spending my own personal money on it, I want a guarantee that it cannot possibly cost more than a given amount. When it's my own money on the line, I absolutely want the service to shut down rather than have even 0.01% chance of costing me a lot of money.

The moment I'm actually building something for a business, the moment it's company money instead of personal money, then priorities change and everything you're saying makes sense. But as long as I'm just a single developer playing with stuff and billing it to my personal credit card, I want that guarantee that I won't accidentally make myself go broke.

Re: Accident Forgiveness

#109

Post by pocketarc »

mappu wrote: post #102
tomjen3 wrote: post #11

I really, really wish there was just a way to put a hard limit on how much a cloud could charge me. I am never going to want to spend 200k of my personal money on some project on a cloud. Never. I don't even want my ant-based basket viewing project simulator to cost me 1 thousand dollars because it went viral and all clouds overcharge for bandwith. Just let me put in a limit.

You might be happier with a fixed-size VPS, instead of a cloud provider,

I started writing this comment by saying:

Exactly - the whole point of a cloud provider is scalability. If you're doing a personal hobby project, get off big scalable clouds and get yourself one (or multiple!) fixed-price VPS or dedicated servers.

But as I think of it, I think what people really want, for hobby projects, is not so much the scalability, but the managed offerings. They want zero-ops, zero-maintenance, zero-server-updates hosting, with a fixed price and hard limits. It won't be infinitely scalable, but it doesn't need to be - it's a hobby project.

They just don't wanna sysadmin a server of their own. Which is completely understandable.

There's room in the market for something like this.

Re: Accident Forgiveness

#110

Post by tptacek »

amirhirsch wrote: post #107
tptacek wrote: post #71

Y'all really, really want caps. We think that's a crazy feature. We don't want to do it. But I just had this conversation on a Slack with a bunch of friends at other companies and they were just as yell-y about this. There's a threshold of feedback at which I think you could get us to do some kind of cap thingo. I'm just saying. Yeesh.

Sounds like I should just DM Kurt until it happens?

Absolutely you should. I'm intractable, he isn't.
Post reply on HN