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

51–60 of 310 posts

Re: Accident Forgiveness

#51

Post by gwbas1c »

tptacek wrote: post #46
osbulbul wrote: post #42

Earlier quoted context omitted.

yeah I am pretty sure no cloud provider thinks people who can willing to spend small money. but guess what? if one of my projects start earning money, then I will continue to what I know best :) I think that's why every cloud provider still has configs for couple of $

We think all the time about people starting small projects here. I think a really good line to draw, if you want to understand how we think about this stuff, is between people who would be OK with us terminating their service because they mispredicted what their cap should be, and people who need their stuff to stay up and running and will just talk to support if they're concerned about billing. A shorter way to say…

One thing I'm really curious about is why caps are so hard? (Perhaps this would result in a more technical blog post?)

IE, you clearly don't want to terminate or shut down an account if they get too close to a cap. But what about things like a warning email, service slowdown, ect?

Likewise, the old "slashdotted" or "hug of death" might be an appropriate result when something goes beyond a reasonable safety buffer?

Anyway, just curious. It's clear that it's a complicated topic, and the real constraints and challenges are interesting.

Re: Accident Forgiveness

#52

Post by bitbasher »

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.

Cloud squatting?

Re: Accident Forgiveness

#53

Post by tptacek »

lkbm wrote: post #49
karmajunkie wrote: post #45

Earlier quoted context omitted.

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

Depends. For my hobby project that hasn't been monetized, being charged $100k is way worse than it going down. If it were critical infrastructure, or monetized in a way that brought in revenue to cover the charge, then maybe I don't want it to shut down despite skyrocketing costs, but that's hardly the only situation you could be in.

Nobody is going to charge you $100k.

Re: Accident Forgiveness

#54

Post by tptacek »

gwbas1c wrote: post #51
tptacek wrote: post #46

Earlier quoted context omitted.

We think all the time about people starting small projects here. I think a really good line to draw, if you want to understand how we think about this stuff, is between people who would be OK with us terminating their service because they mispredicted what their cap should be, and people who need their stuff to stay up and running and will just talk to support if they're concerned about billing. A shorter way to say…

One thing I'm really curious about is why caps are so hard? (Perhaps this would result in a more technical blog post?) IE, you clearly don't want to terminate or shut down an account if they get too close to a cap. But what about things like a warning email, service slowdown, ect? Likewise, the old "slashdotted" or "hug of death" might be an appropriate result when something goes beyond a reasonable safety buffer? An…

We talk about warnings in the post. We'll do that at some point. The hard part about caps is what to do when someone hits them.

If there was a way to make caps work for our core customers, we'd do it. We're open to ideas. A theme of our work this past month and these next several months is extracting maximal value from ANFWWAONW, our new billing system. The thing you have to remember though is that our belief about our core customer is that they are averse to nothing more fiercely than service disruption.

We're not in principle opposed to caps. We just don't have a product story for them that we're comfortable with. Keeping you from spending more money than you wanted to is an explicit product goal of ours (again: see post); we're just very wary of trading availability off against that goal.

Re: Accident Forgiveness

#56

Post by immibis »

tptacek wrote: post #44
candiddevmike wrote: post #21

Earlier quoted context omitted.

You'll pay exactly the amount they think you can afford to pay and not a penny less.

That would be what you would pay in the absence of competition. This is an incredibly competitive space.

Then how do AWS, Azure and GCP charge 100 times the amount for bandwidth as other hosting providers and the IP transit quote sitting in my email inbox?

Re: Accident Forgiveness

#57

Post by brundolf »

I've never understood why providers don't just give you the option of setting a cost cap: "If this piece of infra exceeds [5x expected usage cost], shut it down and send me an email"

Re: Accident Forgiveness

#58

Post by immibis »

tptacek wrote: post #53
lkbm wrote: post #49

Earlier quoted context omitted.

Depends. For my hobby project that hasn't been monetized, being charged $100k is way worse than it going down. If it were critical infrastructure, or monetized in a way that brought in revenue to cover the charge, then maybe I don't want it to shut down despite skyrocketing costs, but that's hardly the only situation you could be in.

Nobody is going to charge you $100k.

(ignores the multiple hobbyists who accidentally got charged $100k)

Re: Accident Forgiveness

#59

Post by moring »

karmajunkie wrote: post #45
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.

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: If the cost would exceed X, then terminate it early so the cost doesn't actually exceed Y.

Sounds complicated to implement, but then, the current practice of waiving the bill is complicated too if you tried to formalize it.

(For the sake of this discussion, I'm ignoring all the technical difficulties of terminating a high-availability service at all.)

Re: Accident Forgiveness

#60

Post by brundolf »

lkbm wrote: post #49
karmajunkie wrote: post #45

Earlier quoted context omitted.

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

Depends. For my hobby project that hasn't been monetized, being charged $100k is way worse than it going down. If it were critical infrastructure, or monetized in a way that brought in revenue to cover the charge, then maybe I don't want it to shut down despite skyrocketing costs, but that's hardly the only situation you could be in.

But more importantly: just let the customer decide! Let them decide whether there's a threshold where an outage is less costly than the hosting, and what that threshold is
Post reply on HN