[flagged]
Accident Forgiveness
211–220 of 310 posts
Re: Accident Forgiveness
#212There is a very obvious fix for surprise billing. Enforce a billing cap and terminate service if it's met. Even better if you send alerts when the cap is approaching. If I pay $39/month, a default cap should be $39 per-month. Otherwise, let me set a cap I am comfortable with. Surprise billing is never good for customers, only the business.
Yes, and it shouldn't be too hard to implement at the business side. Deno just announced it: https://deno.com/blog/deploy-spend-limits
Re: Accident Forgiveness
#213There is a very obvious fix for surprise billing. Enforce a billing cap and terminate service if it's met. Even better if you send alerts when the cap is approaching. If I pay $39/month, a default cap should be $39 per-month. Otherwise, let me set a cap I am comfortable with. Surprise billing is never good for customers, only the business.
Yes, and it shouldn't be too hard to implement at the business side. Deno just announced it: https://deno.com/blog/deploy-spend-limits
(on their Pro plan)
I'm not talking it down. Maybe people are right about this. We'll see.
Re: Accident Forgiveness
#214If 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.
Hu? For any business having a due to a cap throttled service is better than losing the money straight away due to an accidental cloud bill explosion.
Re: Accident Forgiveness
#215Earlier quoted context omitted.
Anyone else remember we had widely available and completely understandable options to rent everything from baseline web-hosting all the way up to private rack services for actual years before AWS came along and apparently all of that was forgotten, Warhammer 40K style? I've rented a VPS from a vendor for going on 20 years now (Holy fuck I'm old) and I've never once been surprised at the bill.
You know that book "JavaScript: The Good Parts"? There needs to be a similar one "AWS: just the good parts". It would probably talk about EC2 (VPS), S3 (cheap bulk storage), SES (emails), and that's about it. When folks get into the elastic-super-beanstalk-container-swarm-v0.3 products, that's when they really kill themselves on the bills. That said, yes, just using a VPS vendor is the easy way to stick to the good p…
> "AWS: just the good parts"
I can't imagine a zero-page book selling well...
Re: Accident Forgiveness
#216>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…
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?
Re: Accident Forgiveness
#217If 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.
The real solution is to make it simpler to set up billing alerts. If my hobby project is ever projected to cost more than $0.50/hr, let me know. Billing alerts should be part of onboarding for all cloud providers, especially for individuals that don’t want surprises.
Re: Accident Forgiveness
#218Earlier quoted context omitted.
The technical problem is not "we are operationally incapable of, say, getting someone else to underwrite insurance contracts". That's not a technical constraint, It's a business decision. I get that the underlying issue is that your target consumer is whales who eat orders-of-magnitude pricing spreads as normal opex, and that anyone who comes in with a budget is barely a consideration. It's still absurd to pretend th…
I don't think you've thought very carefully about this, because there are real technical problems here. If we did a cap feature, enabling it would involve disabling parts of our platform. We're just going to go back and forth on this, because I'm not going to write you an essay on this, and you're going to keep saying "it's a business decision" and I'm going to keep knowing you're wrong about that. For the nth time o…
> If we did a cap feature, enabling it would involve disabling parts of our platform.
What I'm saying is that capping billing is not the same thing as shutting down parts of the platform. You're redirecting complaints about the latter by focusing on the difficulty of doing the latter in real time, which is granted but gross overkill.
The former is something that is not only doable, but something that already happens regularly in an informal capacity and nobody believes you don't have the data to price it.
Re: Accident Forgiveness
#219To be clear, in the case of those abusing the policy: > We reserve the right to cut you off.
While obvious, doesn’t this make it the same as before?
I trust them to handle even edgy cases more generous after this announcement. Just a gut feeling, as if they would risk losing significant credibility. I've written elsewhere that I'm not a big fan of those over-marketing posts, but they are small and more trustworthy than any of the large providers.
Re: Accident Forgiveness
#220I'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"
Deno recently did: https://deno.com/blog/deploy-spend-limits