Comment by AnthonyMouse
3 days ago
You're configuring something that costs money (electricity, hardware, real estate) to provide. Either it's "pay as you go" or you have a flat rate and a cap.
If you have a cap and then your thing hits the front page and suddenly has 10000% more legitimate traffic than usual, and you want the legitimate traffic, they're going to get an error page instead of what you want. If there is no cap, you're going to get a large bill. People hate both of those things and will complain regardless of which one actually happens.
The main thing Google is screwing up here is not giving you the choice between them.
The main thing Google is screwing up is that if my API key somehow leaks and I end up with extremely out of line billing at Microsoft, I will be on the phone with a customer representative as soon as we or they notice something weird happening and a solution will be found.
Google will probably have me go through five bots and if, by some kind of miracle, I manage to have a human on the phone, they will probably explain to me that I should have read the third paragraph of the fourth page of the self service doc and it's obviously my fault.
It took me approximately 6 months to get a billing dispute resolved with Google. Somehow my maps key got leaked, and someone ran up 1.8k in charges on it.
Super, super painful. That being said, I'm still using Google for geocoding (mostly batch) because their service works better for my data.
Imagine the outrage here, when a company credit card expires and the cloud provider terminates all their instances, deletes all your storage and blob backups?
That does happen, it's just usually not when the card expires, but when the follow up billing emails get ignored for some period.
This is one of the reasons people have suggested using a different provider for backups.
it's not an either or, they can easily let me configure any kind of behavior that I want. No cap, a hard cap, a soft cap, a cap that I program with a python script, a cap where I throttle, a cap where I opt in to deleting certain machines to save money. It can all be done. People are complaining because obvious features are not provided. People would not be complaining if they had all the options that we needed to control how to scale resources in response to load, not just technical load but also financial load.
You can already do any of those things in your own code when making the API requests. The issue here is, if you unintentionally try to make a billion expensive requests or allow someone else to do it against your account, do you want them to automatically turn off your stuff or do you want the bill that comes if they don't?
You seem to not comprehend the concept of informed choice.
Upstream in the comments someone said they expect the EU might soon rule this type of billing illegal. That doesn't mean it becomes illegal, it just means yet another reaffirmation or reminder that - yes - this is indeed illegal.
You said that no fixed response -whether that is allow unexpected billing to increase without limit upon a surge vs serving error pages- will be accepted by the clientele, because some want it one way and others want it the other way.
Why would you force a single shoe size onto a population? Give them the choice. Whenever freedom of choice is violated in the name of market freedom, it is nearly always a violation of law, it's just a matter of hoping one lives in a jurisdiction that upholds its laws
> The issue here is, if you unintentionally try to make a billion expensive requests or allow someone else to do it against your account, do you want them to automatically turn off your stuff or do you want the bill that comes if they don't?
That is precisely the choice people are asking for! And it doesn't have to be just those 2 options: let the user define their own trigger formulas for different levels of increase: a small one might result in a notification delayed until certain working hours on weekdays and log each visitors reported origin (referer header), a slightly larger one might result in a notification during awake hours regardless of weekday or workday, yet a further larger consumption increase may trigger an unconditional notification, yet a further one might trigger an unconditional notification that requires a timely confirmation by the user/organization, in the absence of which a soft measure could be taken like adding a small header to the page being served notifying visitors that while still functional a hug of death may be in progress, and asking the visitors to paste the URL of the page from where they clicked the link to your site (to make sure that a full URL can be consulted in case the host operators are unable to find the hyperlink that led to their site from merely the origin domain), yet another increase in traffic may be chosen to result in specifically rate limiting users from the originator domains that caused the peak, so that your regular visitors from the past can still make normal use of the page, and so on.
Do freedom, choice, informed choice, preparedness mean something to you?
We could have an open standard configuration textual machine readable file format for these choices and settings, so that people can share their settings, and the machine readable format could have <private> tags to wrap around phone numbers etc to notify, so that people can easily run a command line program or script that censors those exact values and replaces the first phone number like "<private><phone>(+32)474123456</phone></private>" with "<private><phone>generic phone number 1</phone></private>" and the second email address in the file like "<private><email>john.smith@nonprofit.org</email></private>" is replaced with "<private><email>generic.email@address.2</email></private>", so that people can easily export and share such files, possibly hosting it like robots.txt but say billing_policy.txt so people can inspect how others handle these situations so that popular consensus policies can form.
Hosting, compute etc. services that allow users to configure such files and have them be executed by the hosting service will be more attractive than those which don't.
1 reply →
You're oversimplifying the problem in the other direction. Fine-grained scriptability of hard limits would bump up against all of the thorny distributed systems problems. But I do agree that fixing the simple cases is straightforward - maximum spend rates per instant and per unit of time (eg per minute, hour, day, month). Providers would shoulder the small costs from the slightly-leaky assumptions they have to make to implement those limits, and users can then operate within that framework to optimize what they want on a best-effort basis (eg a script that responds within a minute to explicitly scale resources, or a human-in-the-loop notification cycle over the course of hours so that you have the possibility to say "actually this is popularity traffic that I really do want to pay for, etc).