Hacker News Reader

Comment by vhab | Hacker News Reader

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

View on HN

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.

V1 never dies. You support it forever, including for customers who desperately want v2-only features but would rather escalate than migrate.

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.

Laughs in CodeCommit and S3 Select

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.

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.

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.

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.

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.

NTFS supports case-sensitivity, but if you have case-sensitive distinctions in a directory that's marked case-insensitive, bad things happen. (Those bad things are probably entirely deterministic, theoretically-predictable, and documented in one of Raymond Chen's big books of Windows sadness, but that doesn't mean I want to deal with them as a mere mortal.)

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

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

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

Use 1 for your separator.

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 on news.ycombinator.com