PSA: If you're using the Linode API, the 2048 plan is now PlanID 2 and the new 1024 plan is now PlanID 1. The other PlanIDs were incremented by one as well. I wish they hadn't done that, but there it is.
But that doesn't work with Linode plans because they keep increasing the resources every now and then. They doubled the RAM on all the low-end plans a couple of years ago. Before that, they doubled the storage.
Another option would be to use random IDs that point to a specific bundle of resources. But then the plans change, and the previous bundle is no longer available for purchase.
It's hard to use consistent identifiers when the resources they point to change so often. Linode customers absolutely love those free upgrades.
I bet there is a piece of code in Linode codebase that has the plan resources mapped in a table, with a list of ID attached to the various sizes. The genius developer decided that it makes sense to have the "growing number ID" match the "growth in resources" assigned to the plan. In other words, the bigger ID should always mean MORE resources.
This leads them to alter IDs if they have to introduce plan-sizes that are small.
Imagine if AWS did this: you would see riots in the streets!
Presumably you can select the relevant ID based on plan properties (cores, RAM, etc.) rather than hardcoding IDs. Though I completely agree that once a plan has a specific ID, as long as that plan is available the ID should be constant.
What if they upgrade the 1024 plan to 1536? (That has actually happened, by the way.) Now you're extracting the number and comparing it to a range?
> Give me the plan where the RAM is >= 1024 and < 2048.
What if they upgrade the 1536 plan to 2048?
> Nevermind, just give me the plan with two cores.
Okay, do you want the $20/mo plan or the $120/mo plan?
> Fine, sort the plans by cores and memory and give me the smallest plan.
Oops, they introduced a new plan with one core and less (i.e. not enough) storage.
I'm not saying it's impossible. Just impractical.
The API should throw an error, so I can adjust my scripts, instead of silently provisioning a server I never intended to provision.
There should be a deprecation process when a plan is discontinued, so this doesn't happen unexpectedly.
If AWS can't provision me a t1.micro, they don't just go and give me a m3.small instead.