upvote
S3 was well aware of the pain when I was there ~10 years ago, just considered themselves handcuffed by the decisions made before the idea of a cloud was barely a twinkle in a few people's eyes, and even the idea of this kind of scale of operation wasn't seen as even remotely probable. The namespace issue is one of a whole long list of things S3 engineers wish they could change, including things like HTTP status code behaviour etc.

I've never really understood S3's determination not to have a v2 API. Yes, the V1 would need to stick around for a long time, but there's ways to encourage a migration, such as having all future value-add on the V2, and maybe eventually doing marginal increases in v1 API costs to cover the dev work involved in maintaining the legacy API. Instead they've just let themselves, and their customers, deal with avoidable pain.

reply
V1 never dies. You support it forever, including for customers who desperately want v2-only features but would rather escalate than migrate.
reply
AWS has a privileged position compared to other deprecation struggles in the industry, though. They can price the v2 version aggressively/at a loss to incentivize migration without major bottom line impact.

And sure, v1 is forever, but between getting to the point where new accounts can’t use it without a special request (or grandfathered in sweetheart rates, though that might be a PR disaster) and incentivizing migration off for existing users could absolutely get s3v1 to the point where it could be staffed for maintenance mode rather than staffed as a flagship feature.

It’d take years, but is totally possible. Amazon knows this. If they’re not doing it, it’s because the costs don’t make sense for them.

reply
Laughs in CodeCommit and S3 Select
reply
I recall being shocked the first time I used Azure and realizing so many resources aren’t namespaced to account level. Bizarre to me this wasn’t a v1 concern.
reply
And the naming restrictions and maximum name lengths are all over the place: https://learn.microsoft.com/en-us/azure/azure-resource-manag...

Storage accounts are one of the worst offenders here. I would really like to know what kind of internal shenanigans are going on there that prevent dashes to be used within storage account names.

reply
I wonder if it's related to the fact that Windows as such weird rules about allowed file names. Like not directly obviously, more like culturally inside microsoft.
reply
I’m pretty sure Azure was built out with Hyper-V, which was built into the Windows kernel. So everything that relied on virtualization would’ve had bizarre case insensitivity and naming rules.

I’ve lost track of servers in Azure because the name suddenly changed to all uppercase ave their search is case sensitive but whatever back-end isn’t.

reply
Isn't case insensitivity a Win32 thing only? I would not expect it to impact stuff in Hyper-V or the windows kernel. AFAIK for example NTFS is case-sensitive.
reply
I would not dismiss something like that directly being the cause. Not the reason you can't name a file "CON" on Windows, but it's very likely some weird ass thing they were stringing together with Windows Server and Hyper-V and SMB backed them into the corner we're all in now
reply
Author here. Thanks for the call out! I've updated the article with attribution.
reply
> especially with the really short name limit of only 24 characters.

And with no meaningful separator characters available! No dashes, underscores, or dots. Numbers and lowercase letters only. At least S3 and GCS allow dashes so you can put a little organization prefix on them or something and not look like complete jibberish.

reply
Use 1 for your separator.
reply
You also can't even have hyphens in the storage account name. It's a complete shit show tbh. Same with container registries and other resources.
reply