Navnkonvensjoner i Azure

For reasons unknown, naming conventions tends to end up in heated debates. A naming convention is a systematic method for naming a *resource. Your naming convention will always be an powerful and easy method for organizing and retrieving information. You want to get this right the first time, so it is important to invest enough time to think about this carefully.

* A resource could be an Azure resources or service, a file name or pretty much anything else that should have a logical name.

Background

In Azure, we use a combination of subscriptions, resource groups and resource names to organize environments. The Azure resource list is typically a big mess of everything in your subscriptions. Everything is by default listed in alphabetical order, and it is typically hard to find what you are looking for, especially when your lacking a naming convention.

Since most of our clients ask us for help to create a good naming convention, we decided to share our general recommendations with everyone.

What Clients Tend To Do

Our clients typically go with either camelCase or TitleCase because that's what they are used to. Some clients don't even care and just write something completely random, such as "rgnergmerewrw". The problem is that Azure has internal inconsistencies for naming resources and no one can understand what "rgnergmerewrw" is related to. For example, Azure only allows alphanumeric lowercase for some resources, while others support a whole range of characters such as "Case Insensitive, Alphanumeric, underscore, and hyphen". Whoa...

There is another quirk with Azure naming where hyphens are allowed in most cases, but not in some (eg. storage account naming). Some clients have opted to just never use hyphens at all. The problem with this is that alongresourcenameisdifficulttoread.

Some resources get auto-generated names, based on Microsofts naming convention. Some resources require a globally unique name. Some resources can only be named properly when being deployed from PowerShell, REST API, CLI and others. Most resources can't even by renamed!  It's a mess if you don't do it the right way, the first time!

Our Recommendations

Back to the heated discussion; You might not like the order we have placed our identifiers in, or our abbreviations. But that's not the point. The point is that you actually have a naming convention to follow. If you decide to have the "Environment" identifier first or last, is completely up to you. 

Since we now agree that it's more important to actually have a standard, then to not have it, and that you can build it any logical way you want, there is no need for a heated argument :)

Naming Principals

1. The naming pattern must support easy application level grouping for showback/charge back billing when required.
   Constraints: Some resources are constrained by their identifier length, and case sensitivity
2. The convention MUST Describes type of resource in the subscription.
   Constraints: Some resources must be uniquely named across entire Azure.

• The establishment of good name standard before you implementing different types of resources is imperative, as it can be difficult, or sometimes impossible to rename them afterwards.
• Azure will try to automatically create various resources. For example Virtual Machine Disks and Network Interfaces will still be named poorly. However, they can be named properly by using ARM templates, Powershell, Azure API or CLI.
• It is unlikely that if we follow these rules for global naming that we will run into any naming conflicts with other Azure users. However, the chance still exists, so you need a strategy for coping with such conflicts (Not covered in this post).

Naming Limitations in Azure

Azure has a number of constraints, which are implemented at different scopes, and must be considered while naming resources. Most of them are documented under Microsofts Naming conventions documentation.

Some important limitations worth mentioning:

Scoping

Each resource or service type in Azure enforces a set of naming restrictions and scope; any naming convention or pattern must adhere to the requisite naming rules and scope. For example, while the name of a VM maps to a DNS name (and is thus required to be unique across all of Azure), the name of a VNET is scoped to the Resource Group that it is created within.

Naming Identifier

An identifier can refer to different aspects that describe the particular resources and are eminent for building a good naming convention. Before building our resource naming scheme, we should write down some commonly used identifiers we can build our naming convention on.

Customer Names

Customer name shortenings are used to identify the customer's services without exceeding naming limitations in Azure.

Service names

Service names are used to describe a services name without exceeding naming limitations in Azure.

Geographic Zones and Data centers

 See Azure Paired Regions for more information and a complete list of data centers.

Environment

Companies have different environment setups and they all should have their own abbreviation.

1. Production: This is live and is actively being used by customers. This is running on real data and exist on the azure production subscriptions.
2. Staging: This is a validation system that new features are evaluated in before final approval and roll-out to the production system. This is running on data as close to the reality as possible.
3. Testing: This is a system for trying out newly developed features that might not be fully completed. This is running on testing data.
4. Development: This is the playground for developing and explore new things on the Azure platform, and can be removed without further notice.

Azure Services 

A list of some Azure services that can be identified by an abbreviation.

Resource naming

Finally, what you have been waiting for; The place where the debate temperature always rises. 

Let's establish some rules that can be used for almost all Azure resources;

- Use lowercase
- Use hyphens where permitted
- Include the service name
- Prefix/Suffix with Azure Service abbreviation
- No spaces! Resource names should be made up of a minimum of 3 parts joined together without delimiters. There should not be any spaces in the resource name. Use hyphens where permitted!
- Highly available resources should include an instance number.
- (Add your own rule(s) here)

With the rules in place, we can create a resource-name convention. Our universal recommendation without knowing your environment in details are;

No Hyphen:
<Customer><Environment><Location><Service><InstanceNumber><Resource>

Hyphen:
<Customer>-<Environment>-<Location>-<Service>-<InstanceNumber>-<Resource>

Examples

App Services