So, it was 8 characters, and now it's 17. Was the thinking any more scientific than: "Is doubling it enough? Probably, but let's add an extra character, just to be sure."
Amazon Web Services has extended its resource numbering scheme, after last year warning that without a new scheme it would “start to run low on IDs for certain EC2 and EBS resources within a year or so.” Every AWS resource gets a unique identifier. For most of the service's history those were eight characters in length. But …
This post has been deleted by a moderator
It's doubling of powers though. Just going from 8 to 9 would increase it by 36 fold. Not sure what I'm missing here but there should be about 2.8 trillion combinations of 8 character lower alpha + digit
= (26 + 10) ^ 8
Just going to 9 characters gives you 101 quadrillion possibilities, which grabbing my not really Bill Gates hat ought to be enough for anyone.
I don't follow what they are running out of because these are already big numbers. . My suspicion is that they are concatenating more info into those identifiers (first x characters means y, etc) but that's just a guess.
Because of the birthday paradox, if the identifiers are assigned at random (and they better be or the whole system is insecure) that after assigning about square root number of all available means you have a 50% chance every time you assign a new one to pick already selected one.
In other words, they prepare for a more modest number of about 1.69266 * 10^13 (16 trillion short scale, 16 billion long scale) tracked items.
It isn't 0-9and a-z (36) but rather 0-9a-f (16) Ie. Hexadecimal.
Since it takes 2 hex digits to make a byte, and 17 digits isn't divisible by 2; the odds are that they are simply 64-bit (8-byte) integers, displayed in hex and with a single digit checksum.
And unsigned 64-bit integers gives 2^64 = 18,446,744,073,709,551,616; or ~18e18
Which is ten orders of magnitude less than your calculation, but still sufficient that every person on the planet could deploy 2.5 billion of each resource type and still leave change.
(An IT correspondent that doesn't recognise hex? )
Well, I for one, am looking forward to the day when their services "experience" technical difficulties.
I have no particular Luddite view of this, it's just the idea that we seem to be thinking that it's a good idea to put all our eggs in one basket. We're just one curious squirrel away from disaster.
To strech your already tenuous metaphor, why would you put all your eggs in one basket when you can distribute the between Ireland, Frankfurt and Sydney? Or if you really care, add in soft microfibre bag in Hong Kong too.
Never has multi-continent resilience been so easy.
...and even without multi-region, AWS encourages spreading your implementation across availability zones within a single region. An 'AZ' may then often split into multiple data centres.
And there are advantages of using a 'single basket', including:
1) Optimised data transfer between different parts of the infrastructure (and it's often free too - e.g. you won't pay for data transfer between EC2 and S3 / Cloudfront) for example, which you would if the transfer hit the public internet)
2) A single set of APIs to learn, no matter which datacentre you're using.
3) If things aren't working, a single port of call in determining the issue, rather than having to deal with multiple companies all saying "not me guv"
...and if you are choosing a single 'basket', then AWS is a great choice, which is why their business is doing so well.
this is because the birthday paradox presupposes 23 randomly chosen birthdays. this is equivalent to choosing them all at once with a random function.
in this case we have n *distinct* identifiers and are choosing one more. we can't take advantage of a collision in the pre-allocated numbers because there isn't one. given n randomly distributed allocated numbers in a field of m size, the probability of a collisionis n/m.
otherwise of course, the previously chosen values would pre-dispose the next choice. but we know numbers aren't calvinist.
Biting the hand that feeds IT © 1998–2022