> For Azure Blob Storage, storage accounts are scoped with an account name and container name, so this is far less of a concern.

The author probably misunderstood what "account name" is in Azure Storage's context, as it's pretty much the equivalent of S3's bucket name, and is definitely still a large concern.

A single pool of unique names for storage accounts across all customers has been a very large source of frustration, especially with the really short name limit of only 24 characters.

I hope Microsoft follows suit and introduces a unique namespace per customer as well.

▲

Twirrim an hour ago | parent | next [-]

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.

▲

iann0036 5 hours ago | parent | prev | next [-]

Author here. Thanks for the call out! I've updated the article with attribution.

▲

ryanjshaw 5 hours ago | parent | prev | next [-]

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.

▲

mwalser 3 hours ago | parent [-]

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.

▲

xmcqdpt2 3 hours ago | parent [-]

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.

	▲	mixdup 28 minutes ago \| parent \| next [-]
		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
	▲	throwaway173738 2 hours ago \| parent \| prev [-]
		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.

▲

mirashii 2 hours ago | parent | prev [-]

> 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.