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

251–260 of 310 posts

Re: Accident Forgiveness

#251

Post by rmccue »

morningsam wrote: post #228
JimDabell wrote: post #224

Earlier quoted context omitted.

What are you referring to, exactly? That doesn’t sound like AWS at all. AWS are very well-known for bill forgiveness. It’s not something set in stone, but if your bill explodes accidentally, even due to a mistake you made, they will normally forgive it if you ask them. You don’t need to go running to social media at all.

You're right, I was getting two relatively recent posts mixed up: 1. After a DDoS attack, someone got a $100k bill from Netlify for his static site and after he asked to have it waived, they generously reduced it to $5k. Only after his posts about it blew up did Netlify waive it completely. [1] 2. Someone got a $1k bill from AWS because lots of people made _unauthorized_ requests against his empty S3 bucket. AWS did…

For (2), AWS _also_ has now shipped a change that makes those requests non-billable permanently: https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3...

Re: Accident Forgiveness

#253

Post by felixgallo »

commercialnix wrote: post #131
javcasas wrote: post #69

Earlier quoted context omitted.

They laugh at me for constructing as much as I can from the infra as plain kubernetes objects. Keep laughing, I can switch clouds in less time than you take for figuring out cloud costs.

Keeping everything, including mission critical databases, "inside" Kubernetes is smart. The smart people keep everything "in" Kubernetes. Everyone else can pay up.

Don't be ridiculous. To the nearest 9 decimal points, nobody keeps their mission critical database inside Kubernetes, and the K8s tax is excessive for essentially all cloud users anyway.

Re: Accident Forgiveness

#254

Post by ascorbic »

morningsam wrote: post #3

>If you do something luridly stupid and rack up costs, AWS and GCP will probably cut you a break. [...] Everyone does. If the incidents that made the rounds here in the last few months are any indication, they'll start out insisting you pay no matter what. You'll then have to write a blog post about it, post it to Twitter, HN, and Reddit, get a couple hundred comments expressing anger at the provider, and wait for so…

Well, the ones where they forgive it right away don't write blog posts about it, so you don't know about them. I guarantee that every case which makes the front page is either an example of a mistake made by an individual support engineer following the wrong script, or the person posting it is being dishonest about what actually happened (I recall a particularly suspicious recent one where they hid the name of their site). The cloud providers all have a policy of forgiving these sort of cases. The only speedbump is ascertaining if it was a genuine mistake.

Re: Accident Forgiveness

#255

Post by tgsovlerkhgsel »

solidasparagus wrote: post #232
tgsovlerkhgsel wrote: post #152

Earlier quoted context omitted.

Terminating service is a big deal for commercial customers' production environments. Reversibly (i.e. shut down compute, don't delete anything, allow the customer to review, fix and reinstate quickly) terminating service is a minor annoyance for hobby/experimental setups, and in those, it's much more preferable than having to open a support ticket to deal with a massive bill. Having quotas that the customer can incre…

No one really cares enough about hobby developers as a customer segment to rebuild the billing infrastructure to make this possible. Scalable billing at huge scale is solved at the cost of latency and being "eventually correct" (unless it has changed). To add a price cap feature, eventually correct isn't enough and then you ask yourself who would actually use it and you have to scroll really far down your list of big…

The problem with not caring about hobby developers is that it means developers won't be as familiar with your cloud environment when time comes to pick one for the next "real" project.

I would also expect a price cap feature to be useful for experimental/no-approval-required projects at work. In fact, if I ran a cloud project for work as a small team-internal project, a cost explosion would become an even bigger bureaucratic nightmare than if it happened at home.

Re: Accident Forgiveness

#257

Post by fauigerzigerk »

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.

Surely it depends on the type of contract. Prepaid SIM cards stop working the second you run out of credit.

Re: Accident Forgiveness

#258

Post by jmathai »

rawgabbit wrote: post #216
jmathai wrote: post #205

Earlier quoted context omitted.

I was a PM in GCP and refund requests due to customer misconfigurations would make it to me for approval. Generally, I tried to make exceptions to grant the refund. It sucks to get these bills and they can be quite scary. Unless you have a real chance of bursty traffic I suggest going with compute that has more predictable costs.

So no elastic anything. Just servers?

If you have elasticity then make sure you understand the limits. Even Serverless has these knobs but for various reasons they default to high elasticity.

But many folks don’t need the elasticity at all. So you should factor that into your architectural decisions.

Re: Accident Forgiveness

#259

Post by School-Cotton »

Aeolun wrote: post #160
School-Cotton wrote: post #150

Earlier quoted context omitted.

Giving people the ability to use caps as an optional feature doesn’t force anyone to use it. Also, you could turn things off in the inverse order they were turned on until the cap is satisfied. So all the crypto miner instances would be turned off before database backups being deleted.

When you go over the cap everything turns off, otherwise, what’s the point? Should you turn things off until you reach a certain spend rate? Then you can set your cap high enough for your server +1, but no more.

I was imagining the cap would be a rate, not a total.

Re: Accident Forgiveness

#260

Post by School-Cotton »

tptacek wrote: post #168
School-Cotton wrote: post #148

Earlier quoted context omitted.

Why don’t you want to do caps?

When I was 15 years old, I was walking the mean streets of Chicago after attending an opera with my parents when a billing cap leapt from the alley and snatched my mom's purse. My dad fought it valiantly, but it prevailed, killing both my parents in the process. From that day forward...

I was actually curious what your serious reason is.
Post reply on HN