Ingrid Bakke

My opening complaint about resource identifiers is that they are strings carrying a hierarchy, and every mistake follows from treating them as opaque. A resource identifier is slash-separated: subscription, resource group, provider, type, name. The type itself is a two-part pair of namespace and type, and the name is a further path. Because the type can contain a slash, a naive split on slashes produces the wrong number of segments for roughly half of all resources, which is why a parser that works on a virtual machine identifier fails on a disk or a subnet. Case sensitivity is the second trap. Identifiers are documented as case-insensitive in most respects while the underlying names preserve case, so two references differing only in case resolve to the same resource on some operations and not on others. ARM templates are declarative JSON describing a resource graph. Two things cause most of the problems: a property whose value is only known after something is created, which forces the dependency to be declared or the deployment to fail, and a template that silently creates a resource with a default that differs from what the docs describe. On cost, scope is the whole problem. A resource's cost depends on its resource group, its region and often its availability zone, and estimating from a name alone means guessing three values. Region is the one people forget, since a resource identifier carries it and nobody reads that segment. I keep a note on which properties are required versus which have defaults, because the ones with defaults are what get deployed differently from what was documented.