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

181–190 of 310 posts

Re: Accident Forgiveness

#181

Post by srockets »

Aeolun wrote: post #149
srockets wrote: post #77

Earlier quoted context omitted.

An argument that is often only made by folks who didn't ran anything at scale on a public cloud. If you've ever set in a room when a cloud deal was signed, you'd know it cable: you don't get to pay less by threatening to switch providers (I've seen people try to suggest that and get laughed out of the room), but by buying more from a single one. Hence accident forgiveness is in the same marketing bucket as free credi…

AWS is something like an insurance service. We all pay more so that they can forgive the people that mess up xD

That’s not how it works.

We all pay more [sic] so data centers would be over provisioned, allowing quickly expansion when we need it. I’ve been in a few incident that were root caused to a cloud provider lacking capacity to provision more instances.

As that over capacity would’ve been bought and installed in the cloud provider’s data centers regardless of the errors that are being forgiven, not billing for those errors is a net gain to the provider, at minuscule cost, if at all, to other users.

Re: Accident Forgiveness

#182

Post by jgalt212 »

paxys wrote: post #48
tptacek wrote: post #44

Earlier quoted context omitted.

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

Competition only matters for new contracts. Once you have picked a provider and made a big enough infrastructure investment, there's no realistic path to switch to someone else.

True, margins are very high for existing customers. And customer acquisition costs are very high as well.

Re: Accident Forgiveness

#183

Post by naniwaduni »

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…

Sinclair effect in action: "It is difficult to get a man to understand something, when his salary depends on his not understanding it."

Obviously, cloud providers are capable of billing. It's not unreasonable to expect them to offer, at minimum, "Look, we're not evaluating billing continuously but we might, at our option, try to shut down your services after $X and won't bill you excess of $Y" as a (optional) hard contractual term. Having a larger, well-capitalized party absorb risk on behalf of a smaller party for a fee is a business model humans know how to price. It's just not the desired "product".

Note that this doesn't even per se require any technical artifact to implement, just very primitive metering and lush margins.

Re: Accident Forgiveness

#184

Post by kasey_junk »

If I were fly I’d implement spending caps just to filter out unserious operators.

My implementation of that feature would be when you turned it on fly would just kick you off.

No serious operator wants a provider to turn their system off. So if you want that it’s pretty clear you are hosting a silly system. Which likely costs more to support and drives less margin.

Re: Accident Forgiveness

#185

Post by tptacek »

myaccountonhn wrote: post #137
tptacek wrote: post #100

Earlier quoted context omitted.

Sure, but bear in mind that across the entire industry of public clouds, which has been around for something like 2 decades now, nobody really has this feature. In fact, didn't Google have this feature and then pull it?

I've def. wanted to have spending caps on a lot of my projects. The ones I've tried: AWS and GCP made this ridiculously difficult. It might be that they will waiver the bill, but the general feeling that they get to decide if I go bankrupt or not is nightmare fuel. In the end, I've just set up a 5$ vps where I self-host all my apps. That removes all the stress.

Yeah, so one issue we run into here is that we're not trying to get you to stop using $5 VPS's. That is not good business for us! There is nothing at all wrong with managing your own servers.

Re: Accident Forgiveness

#186

Post by stackghost »

rendall wrote: post #117
tptacek wrote: post #62

Earlier quoted context omitted.

Why isn't one of those providers roflstomping the other 3 (add OCI to the mix) with better pricing?

"roflstomping"¿ What does it mean?

It's from online gaming. To stomp means to defeat soundly/easily. To ROFL is to roll on the floor laughing.

To roflstomp is to defeat someone so easily and completely that it becomes so comical you'll be ROFL.

Re: Accident Forgiveness

#187

Post by naniwaduni »

donavanm wrote: post #165
gwbas1c wrote: post #51

Earlier quoted context omitted.

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…

Metering, pricing, and billing is way more complicated than you might assume. There are historical posts here with more details if you search. In short its all async, theres variable lag, theres multiple “types” or dimensions to metering, the prices vary by SKU + customer + previous metering or billing value + other SKU usage, and billing is not uniform across customers. Imagine needing to accumulate all the metering…

No, this is motivated reasoning brainrot. It's overcomplicating the problem by hyperfocusing on a specific implementation that's already been judged infeasible to justify not doing it.

The actual problem that people want solved is "the customer wants predictable, budgetable upper bound periodic cost". You are not unique in offering a service where this is a desirable property. Realigning this sort of cost structure is the bread and butter of insurance industry, and no, as much as they'd like to, they don't actually do it by making sure to stop the earthquake before it knocks down more of your house than your price cap.

Re: Accident Forgiveness

#188

Post by christina97 »

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.

I totally sympathize with the “no caps” argument. I mean it’s literally just “kill random shit on error”.

Putting both my personal/private as well as work hats on: I’m not sure I would ever want to enable it.

Re: Accident Forgiveness

#189

Post by tptacek »

naniwaduni wrote: post #183
gwbas1c wrote: post #51

Earlier quoted context omitted.

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…

Sinclair effect in action: "It is difficult to get a man to understand something, when his salary depends on his not understanding it." Obviously, cloud providers are capable of billing. It's not unreasonable to expect them to offer, at minimum, "Look, we're not evaluating billing continuously but we might, at our option, try to shut down your services after $X and won't bill you excess of $Y" as a (optional) hard co…

Seriously question: have you thought through what billing for bandwidth, storage, compute, and services actually entails? I'm having a bit of a reaction to the word "obviously" there.

Re: Accident Forgiveness

#190

Post by naniwaduni »

tptacek wrote: post #189
naniwaduni wrote: post #183

Earlier quoted context omitted.

Sinclair effect in action: "It is difficult to get a man to understand something, when his salary depends on his not understanding it." Obviously, cloud providers are capable of billing. It's not unreasonable to expect them to offer, at minimum, "Look, we're not evaluating billing continuously but we might, at our option, try to shut down your services after $X and won't bill you excess of $Y" as a (optional) hard co…

Seriously question: have you thought through what billing for bandwidth, storage, compute, and services actually entails? I'm having a bit of a reaction to the word "obviously" there.

I don't need to, the fact is manifest in your ability to send out the bills for them. This seems very obvious to me, and your incredulity is baffling.
Post reply on HN