Since the user is only paying an infinitesimal fraction of the infrastructure cost, does it really matter? From the user’s perspective it’s extremely inexpensive.
If everyone started using S3 for this purpose, they would shut it down pretty quickly.
Small objects (especially small hot objects) are actually problematic in S3. They cache them in the keymap instead of retrieving from block storage. But many small objects can quickly blow out a keymap shard. The keymap is designed for high-performance lookups. Because of this, it's also more expensive to scale out this class of 'storage' at the keymap layer than to scale out block storage. And you still have to do quorum writes to block storage and then cache eviction at the keymap.
If you're doing this for slow-moving leader election in a small cluster, fine. But if, for example, you started using this for leader-election among end-user-defined workloads that could scale up/down, you might find yourself on the other side of a call from AWS.
> If everyone started using S3 for this purpose, they would shut it down pretty quickly
I work at AWS but not on the S3 service team. (Opinions are entirely my own.)
I have little doubt that the team already considered this possibility before releasing the feature. The choice to make new functionality available in a service is considered a “one-way door” that receives a tremendous amount of scrutiny. Once a feature is made available, they will do everything they can to support it as long as possible, even at the cost of convenience to themselves. And even de-emphasized services (keep the lights on) are rarely deprecated completely - existing accounts and customers already using them can frequently continue to do so.
By way of example, a little over a decade ago a famous online streaming company used to upload all of their video masters for transcoding. This process involved a huge upload and a huge workload, followed by a significant drop in activity.
The problem was that AWS had to provision for peak usage instead of average usage. This resulted in a situation where the peak-to-average ratio was very high for just one or two customers.
To address this issue, the solution was to incentivize these customers to spread out their workload more evenly over time, at least until they were no longer the largest driver of peak/avg.
This is also why things like Reserved Instances and Spot Instances exist.
You said they would “shut it down,” which can reasonably be interpreted as killing the feature. If you meant something more specific, you should have said that. Clarity is the duty of the speaker.
>> “If everyone started using S3 for this purpose, they would shut it down pretty quickly.”
> “I never said they would kill the feature. I said they would shut down the behavior.”
Seems "it" is standing in for a lot of nuance here.
With these three sentences side by side, still took a while to see how you might be referring to the "everyone using" behavior instead of the "S3 purpose" feature! Usually given ambiguity the nearest plausible reference wins.
Since in tech "shut it down" is more often systems than humans and that was the nearest reference "it" could refer to, took some doing to see how your assertion "I said the behavior" could be accurate!
I'll concede that "it" was ambiguous. Though if you take the most literal version of what I said, it would be they'd shut down S3, which clearly isn't true.
We can continue to debate whether or not I (who worked on that team and generally understands what goes into building scaled cloud services, having built several myself) understand how a cloud provider responds to customers using your service in a way you clearly didn't intend, or we can move on with our day.
I wasn't debating what you know from the vantage of someone who's founded and built global cloud SaaS services at scale for a while. I was noting how it was ambiguous but going further to say "ah, I see how you can assert you said it," giving you credit.
