4 ms·

That's good, it makes sense it would be for only those sorts of accounts. Imagine building a billing system that could always do that, any time you accept a req

That's good, it makes sense it would be for only those sorts of accounts. Imagine building a billing system that could always do that, any time you accept a request, you need to check against a database if the user has hit their billing limit or if you can charge them for it. It obviously can't work. I imagine the way MS make it work is probably to slow down resource consumption for those accounts dramatically, and then just take the hit on overspend, knowing that it will be almost nothing.

jsheard 2y ago
I understand that a precise billing limit is probably impossible at that scale, but if they have the ability to send you an email some time after you go over a limit then they have the ability to automatically pull the plug at the same time rather than waiting for you to notice the email and do it yourself. They just don't want to. I'm sure people would accept a best-effort system where setting a billing limit for $100 means you may be billed $140 because your spending overshot the limit before the system noticed. It still beats the alternative of waking up to a $20,000 bill out of nowhere.
- danpalmer 2y ago
  So I've stored some data in a bucket, the storage time goes over my budget, what do you do now? Just delete the data? I think most people would think that's a terrible outcome. Let's say the answer is yes, you just delete all the data as I can no longer afford it... delete operations are billable, so do you charge the user for those deletes or not? Let's say the answer is yes, and you bill the deletes. What happens if too many deletes are required and suddenly you're at 2x the bill cap? Now you can't document the bill cap as being able to go over by up to 1.5x. This may be unlikely, but customers use cloud services in weird and wonderful ways. This is just one resource type, there are many different resource types on a typical cloud provider, each with multiple axes of billing, each of which has hard decisions to not just be made, but documented and communicated to customers in such a way that they understand the impact. Oh and also it's the "I just put my credit card in and go" crowd who you have to explain it to, who aren't engaging in sales conversations, not those on business contracts who might actually listen or read the documentation. It's not at all obvious to me that this is preferable to just having someone look at these incidents on a case by case basis and seeing who should be refunded.
  - thot_experiment 2y ago
    This is an insane take, there are many options here. The idea that the reason to structure billing this way is anything OTHER than that it's the most profitable way to do things is ludicrous. It doesn't matter if you can construct some other plausible reason, as long as it's the most profitable way to operate why would I believe the cause to be something other than profit maximization.
    - danpalmer 2y ago
      What alternative do you suggest? I'm not saying providers should delete data when hitting a cap, but rather that this is one example of why you can't cap spend. It is possible to combine all the billing axes for things like this so that, but when you do you get Dropbox, or Google Drive. The explicit value proposition of cloud hosting is paying for what you use, and generally granular services are lower margin and more commoditised than higher level services.
      - thot_experiment 2y ago
        You could just throw an error, freeze services and do whatever "let someone handle this on a case by case basis". It's absurd to suggest that the customer doesn't want to have the option to prevent their spend from growing by multiple orders of magnitude without a human in the loop. Sure maybe deletes are a billable action (also absurd and fake), but having the options to say "hey I can't spend more than X, cut my service if my spend + cleanup would cost more than X" is absolutely doable and something many people would want.
        danpalmer 2y ago
        If you think that deleting all data (blob storage, block storage, VM states, caches, etc) is preferable to a surprise bill, then I don't think there's anything we can debate here.
        thot_experiment 2y ago
- kccqzy 2y ago
  That's clearly not user friendly. Users cannot predict the amount of overshoot. So we are back to square one. The user could wake up to a $1,000 bill or $10,000 bill and all data deleted, and the cloud provider can just say "oh we run our billing limit enforcer job on an hourly cron schedule but your account requested many machines very quickly so you still incurred $10,000 worth of charges." A precise billing limit is impossible, and a fuzzy billing limit with a precise error bound is the same thing and also impossible. Now we are back to a fuzzy billing limit with an unknown error bound.

jsheard 2y ago

I understand that a precise billing limit is probably impossible at that scale, but if they have the ability to send you an email some time after you go over a limit then they have the ability to automatically pull the plug at the same time rather than waiting for you to notice the email and do it yourself. They just don't want to. I'm sure people would accept a best-effort system where setting a billing limit for $100 means you may be billed $140 because your spending overshot the limit before the system noticed. It still beats the alternative of waking up to a $20,000 bill out of nowhere.

danpalmer 2y ago
So I've stored some data in a bucket, the storage time goes over my budget, what do you do now? Just delete the data? I think most people would think that's a terrible outcome. Let's say the answer is yes, you just delete all the data as I can no longer afford it... delete operations are billable, so do you charge the user for those deletes or not? Let's say the answer is yes, and you bill the deletes. What happens if too many deletes are required and suddenly you're at 2x the bill cap? Now you can't document the bill cap as being able to go over by up to 1.5x. This may be unlikely, but customers use cloud services in weird and wonderful ways. This is just one resource type, there are many different resource types on a typical cloud provider, each with multiple axes of billing, each of which has hard decisions to not just be made, but documented and communicated to customers in such a way that they understand the impact. Oh and also it's the "I just put my credit card in and go" crowd who you have to explain it to, who aren't engaging in sales conversations, not those on business contracts who might actually listen or read the documentation. It's not at all obvious to me that this is preferable to just having someone look at these incidents on a case by case basis and seeing who should be refunded.
- thot_experiment 2y ago
  This is an insane take, there are many options here. The idea that the reason to structure billing this way is anything OTHER than that it's the most profitable way to do things is ludicrous. It doesn't matter if you can construct some other plausible reason, as long as it's the most profitable way to operate why would I believe the cause to be something other than profit maximization.
  - danpalmer 2y ago
    What alternative do you suggest? I'm not saying providers should delete data when hitting a cap, but rather that this is one example of why you can't cap spend. It is possible to combine all the billing axes for things like this so that, but when you do you get Dropbox, or Google Drive. The explicit value proposition of cloud hosting is paying for what you use, and generally granular services are lower margin and more commoditised than higher level services.
    - thot_experiment 2y ago
      You could just throw an error, freeze services and do whatever "let someone handle this on a case by case basis". It's absurd to suggest that the customer doesn't want to have the option to prevent their spend from growing by multiple orders of magnitude without a human in the loop. Sure maybe deletes are a billable action (also absurd and fake), but having the options to say "hey I can't spend more than X, cut my service if my spend + cleanup would cost more than X" is absolutely doable and something many people would want.
      - danpalmer 2y ago
        If you think that deleting all data (blob storage, block storage, VM states, caches, etc) is preferable to a surprise bill, then I don't think there's anything we can debate here.
        thot_experiment 2y ago
kccqzy 2y ago
That's clearly not user friendly. Users cannot predict the amount of overshoot. So we are back to square one. The user could wake up to a $1,000 bill or $10,000 bill and all data deleted, and the cloud provider can just say "oh we run our billing limit enforcer job on an hourly cron schedule but your account requested many machines very quickly so you still incurred $10,000 worth of charges." A precise billing limit is impossible, and a fuzzy billing limit with a precise error bound is the same thing and also impossible. Now we are back to a fuzzy billing limit with an unknown error bound.