3 ms·

This topic has been discussed many times. There's no easy solution to what happens after the cap is exceeded - should the vendor delete everything? - which is w

This topic has been discussed many times. There's no easy solution to what happens after the cap is exceeded - should the vendor delete everything? - which is why so many of them don't bother. And for customers, it's far easier to negotiate billing disputes then to try and recover from an account deletion because of spending caps (and there have been plenty of examples of companies shutting down because of such a mistake here).

xchaotic 4y ago
Imo it’s really simple, actually. Stop the service and delete after the next billing cycle. Price that in for regular price of the service.
- manigandham 4y ago
  That's limited to free tiers that usually deactivate or delete if there's too much usage. Anything with production usage and pay-as-you-go pricing means data at rest still costs money - and requires deleting to avoid accruing new charges. Do you want your databases and volumes and object storage deleted when your app stops? And if this was offered then there would be a whole new class of mistakes leading to lost data. Like I said, billing is easier to negotiate than deleted accounts.
  - brundolf 4y ago
    > billing is easier to negotiate than deleted accounts Maybe, but I'd still like the option. My blog site is stateless so I couldn't care less if the service got deleted
  - newaccount74 4y ago
    The high charges are almost never storage costs, its almost always processing or bandwidth. And storage costs are simple to predict -- as soon as you see the cap would be exceeded, stop accepting new data.
    - manigandham 4y ago
      Overages are overages, whether its 1 penny or thousands of dollars. Data also still costs money per time and can be unpredictable. This kind of pacing and billing buffer is an immense amount of complexity at scale for very little benefit (even if an individual user might like it).
      - newaccount74 4y ago
        Can be unpredictable? How would data storage costs increase if you stopped accepting new data? SaaS companies manage to pull of ridiculously complicated things, but coming up with a billing scheme that does fuck over the customer is asking too much? The simple truth is that usage based pricing is designed to be unpredictable, and surprising customers with high bills is probably considered a feature, not a bug.
        manigandham 4y ago
        Data (and all resources) cost money per time. You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges. The billing scheme is very transparent and friendly by being pay-as-you-go. It doesn't "fuck over the customer". Your entire complaint isn't about the pricing scheme but about an additional feature to stop billing at some point - which I've explained is not easy to calculate precisely because charges accrue on time and adding even more complexity for calculations and potential for mistakes is not worth it for the many reasons I outlined previously. > "The simple truth" You keep repeating that word. There is nothing simple about this. Let's end this here.
        newaccount74 4y ago
        > You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges. Yes, but it's pretty predictable. Once there's enough data in your bucket that the monthly cost would go over the limit, just stop accepting new data. Nobody cares if the spending limit is accurate to the cent. What people care about is not being surprised by huge invoices. > The billing scheme is very transparent and friendly by being pay-as-you-go. Have you looked at eg. the glacier pricing scheme, or at lambda pricing? It's almost impossible to know how much it's going to cost you ahead of time. The only thing you know is that if you happen to use it differently than anticipated, it's going to be expensive.
imtringued 4y ago
It's very easy to solve this problem. Just let people set a cap on the things with usage billing: "I want to cap the amount of data I store to 50GB and the amount of traffic I serve to 1000GB" Of course there is an obvious problem with this, the pricing structure would become transparent and you don't want that as a cloud provider. You want your customer to just pay his bills and not even know why it costs this much.
- manigandham 4y ago
  > "an obvious problem with this, the pricing structure would become transparent " How is the pricing structure not currently transparent? What number are you missing exactly?
newaccount74 4y ago
It's pretty simple: Ask people when signing up if they want to set a spending limit or not. If they do, return HTTP 500 as soon as the spending cap is reached. If it's for storage, return a quota exceeded error. Obviously the vendor shouldn't delete data, that would be stupid. A lot of people try to get hobby users on a platform as a form of PR -- if you don't have spending caps, you are probably going to scare a lot of them away. And I've never heard a company shutting down because they exceeded a limit -- I've only heard of people being surprised by unintended extremely high bills.
- manigandham 4y ago
  > "Obviously the vendor shouldn't delete data, that would be stupid" Since data accrues charges over time, there is no alternative if you want a hard cap. Which is why none of this is very simple at all and requires a tremendous amount of planning and complexity just to implement, let alone all the possible new issues and mistakes it creates for customers. Again, this is the typical "write some code in a weekend" approach that's missing all context of what it actually takes. And as I mentioned before, it's far easier to just negotiate billing then to deal with the aftereffects of whatever service and data disruption this feature would cause for the tiny fraction of customers that end up with this problem. Waving your $5 fee is far easier and cheaper than spending millions on trying to avoid it in the first place, only to get replaced with potential complains that a production account was suspended or deleted.

xchaotic 4y ago

Imo it’s really simple, actually. Stop the service and delete after the next billing cycle. Price that in for regular price of the service.

manigandham 4y ago
That's limited to free tiers that usually deactivate or delete if there's too much usage. Anything with production usage and pay-as-you-go pricing means data at rest still costs money - and requires deleting to avoid accruing new charges. Do you want your databases and volumes and object storage deleted when your app stops? And if this was offered then there would be a whole new class of mistakes leading to lost data. Like I said, billing is easier to negotiate than deleted accounts.
- brundolf 4y ago
  > billing is easier to negotiate than deleted accounts Maybe, but I'd still like the option. My blog site is stateless so I couldn't care less if the service got deleted
- newaccount74 4y ago
  The high charges are almost never storage costs, its almost always processing or bandwidth. And storage costs are simple to predict -- as soon as you see the cap would be exceeded, stop accepting new data.
  - manigandham 4y ago
    Overages are overages, whether its 1 penny or thousands of dollars. Data also still costs money per time and can be unpredictable. This kind of pacing and billing buffer is an immense amount of complexity at scale for very little benefit (even if an individual user might like it).
    - newaccount74 4y ago
      Can be unpredictable? How would data storage costs increase if you stopped accepting new data? SaaS companies manage to pull of ridiculously complicated things, but coming up with a billing scheme that does fuck over the customer is asking too much? The simple truth is that usage based pricing is designed to be unpredictable, and surprising customers with high bills is probably considered a feature, not a bug.
      - manigandham 4y ago
        Data (and all resources) cost money per time. You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges. The billing scheme is very transparent and friendly by being pay-as-you-go. It doesn't "fuck over the customer". Your entire complaint isn't about the pricing scheme but about an additional feature to stop billing at some point - which I've explained is not easy to calculate precisely because charges accrue on time and adding even more complexity for calculations and potential for mistakes is not worth it for the many reasons I outlined previously. > "The simple truth" You keep repeating that word. There is nothing simple about this. Let's end this here.
        newaccount74 4y ago
        > You don't need to add new data to an S3 bucket to get a bill every month because the existing data accrues charges. Yes, but it's pretty predictable. Once there's enough data in your bucket that the monthly cost would go over the limit, just stop accepting new data. Nobody cares if the spending limit is accurate to the cent. What people care about is not being surprised by huge invoices. > The billing scheme is very transparent and friendly by being pay-as-you-go. Have you looked at eg. the glacier pricing scheme, or at lambda pricing? It's almost impossible to know how much it's going to cost you ahead of time. The only thing you know is that if you happen to use it differently than anticipated, it's going to be expensive.

imtringued 4y ago

It's very easy to solve this problem. Just let people set a cap on the things with usage billing: "I want to cap the amount of data I store to 50GB and the amount of traffic I serve to 1000GB" Of course there is an obvious problem with this, the pricing structure would become transparent and you don't want that as a cloud provider. You want your customer to just pay his bills and not even know why it costs this much.

manigandham 4y ago
> "an obvious problem with this, the pricing structure would become transparent " How is the pricing structure not currently transparent? What number are you missing exactly?

newaccount74 4y ago

It's pretty simple: Ask people when signing up if they want to set a spending limit or not. If they do, return HTTP 500 as soon as the spending cap is reached. If it's for storage, return a quota exceeded error. Obviously the vendor shouldn't delete data, that would be stupid. A lot of people try to get hobby users on a platform as a form of PR -- if you don't have spending caps, you are probably going to scare a lot of them away. And I've never heard a company shutting down because they exceeded a limit -- I've only heard of people being surprised by unintended extremely high bills.

manigandham 4y ago
> "Obviously the vendor shouldn't delete data, that would be stupid" Since data accrues charges over time, there is no alternative if you want a hard cap. Which is why none of this is very simple at all and requires a tremendous amount of planning and complexity just to implement, let alone all the possible new issues and mistakes it creates for customers. Again, this is the typical "write some code in a weekend" approach that's missing all context of what it actually takes. And as I mentioned before, it's far easier to just negotiate billing then to deal with the aftereffects of whatever service and data disruption this feature would cause for the tiny fraction of customers that end up with this problem. Waving your $5 fee is far easier and cheaper than spending millions on trying to avoid it in the first place, only to get replaced with potential complains that a production account was suspended or deleted.