|
|
|
|
|
|
by ryandrake
3235 days ago
|
|
|
It's almost as if... they should offer multiple options so customers could choose based on their business/hobby needs: 1. Warn me at $X but don't throttle me for any reason--I'll pay if I go viral 2. Warn me at $X and start throttling until I get to $Y at which point stop service and stop charging 3. Warn me at $X and stop service/charging immediately |
|
|
When you are on shared hosting, the expectation is that you get shut off when you go over.
When you are on "unlimited" shared hosting, the expectation is that you and everyone on the server gets throttled when you go over.
When you are on a VPS, the expectation is that you will be throttled when you go over, and you will be throttled much less than with other options when your neighbor goes over.
With cloud, then, the expectation is that if you go over, you are charged more proportionately, but things continue to work.
Of course, this is a simplification, but I think it accurate enough to be useful.
I do agree that it would be better to choose your api/provisioning and node reliability separately from overage behavior, but most of these behaviors and expectations were based on traditions that were shaped by technical constraints.
To credibly say "we will keep you online and just charge you" you need a lot of spare capacity.
Throttling one customer on a shared host without impacting other customers used to be very difficult. It is still way easier to throttle one VPS customer, and easier stil to throttle that one customer when they have their own kernel and reserved memory; it is not as big of a deal as it once was, considering everyone now uses ssd, but systems that share page cache are notoriously difficult to setup such that light users don't impact heavy users.