There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

The Problem

It's easy, almost to easy to create new resources in Azure. In a way, it's nice to have so little friction to create new resources from nothing in minutes. However, this can also become the wild west very quickly. You'll most likely end up with a lot of stuff in your Azure subscription and not knowing who owns what and if these resources are still used.

The solution

I'm a big fan of convention over configuration.

Convention over configuration (also known as coding by convention) is a software design paradigm used by software frameworks that attempts to decrease the number of decisions that a developer using the framework is required to make without necessarily losing flexibility

What's the link with naming resource in Azure? The truth is that many Azure resource's names will become DNS entries under one of many Azure DNS domains like *.azurewebsites.net, *.database.windows.net, *.vault.azure.net to name a few. There's a very good chance that at some point, you'll have a service or a piece of code referencing those urls. When that happens, it's very nice not having to look all over the place in Azure to find the resource's URL and instead just follow your convention to build the URL, knowing there's a resource with that name on the other end.

Now let's think about what property could be useful to identify our resource. This should probably be parts of your naming convention.

  • Project name
  • Team name
  • Environment
  • Context
  • etc...

The proposition

Here's the convention I've been using for some time now and with which I'm pretty happy. It's flexible, I'm able to enable some complex scenarios without any issues like Multi-Region deployments, DR plans, Blue/Green deployment, Progressive Roll-out.

Type Naming pattern
Subscription {subsidiary}-{productname/teamName}-{subscriptionType}
Resource group {productName/teamName}-{env}-{context}-{location}
Resource {projectName/teamName}-{env}-{context}-{type}-{name}

Subsidiary

If you have many subsidiaries in your company, this will help you filter many views in Azure.

Product name / Team name

Depending how you organize your projects and teams, this could be used at the subscription level and/or at the resource group level to regroup all the resources that should be together.

Subscription type

This is only used to differentiate dev/test subscriptions from prod ones.

Env

This is mainly used by development teams to split their different deployment environments. Most common ones are

  • Dev
  • QA
  • UAT (User acceptance tests)
  • Staging
  • Canary
  • Production
  • etc...

Context

I get challenged a lot about this one. This is mostly to give you another dimension to group and filter by. So this could reflect something that is very close to your business domain. If you are following DDD (Domain Driven Design) practices, these are known as Bounded-Context and can then be express in the names or your Azure resources. Be pleased to use it as you see fit or just ignore it if you don't think you need it.

Location

Here we mean Azure locations like East US, West US, South Central. This is useful when you have an application deployed over multiple regions. This could be use to enable performance or redundancy cloud patterns.

Type

It's always useful to filter by resource type. I know that many screens in the Azure Portal already give you this feature, but don't forget that your resource name could be required elsewhere like in Azure CLI or in a PowerShell script. As names are often limited in Azure, I highly suggest you use short names for types.

i.e.

Type Short Name
Key vault kv
App Service as
App Service Plan asp
Storage Account sa
SQL Server sql

Name

After all, you need to give it a meaningful name at some point.

Examples

Here's some examples, just to give an idea of what it could look like.

  1. Subscription {subsidiary}-{productname/teamName}-{subscriptionType}
    contoso-projectx-dev
    contoso-projectx-prod
    
  2. Resource group {productName/teamName}-{env}-{context}-{location}
    projectx-dev-sales-useast
    projectx-qa-sales-useast
    projectx-qa-sales-uswest
    projectx-prod-marketing-useast
    ...
    
  3. Resource {projectName/teamName}-{env}-{context}-{type}-{name}
    projectx-dev-sales-as-paymentapi
    projectx-dev-sales-kv-default
    projectx-qa-sales-as-paymentapi
    projectx-prod-marketing-as-publicsite
    projectx-prod-marketing-sql-publicsite
    ...
    

Conclusion

Naming is hard, harder than you think. But when it's well done, it's so much easier for everybody to get their way around in Azure. You'll be able to search, sort, filter very quickly and save a lot of time. Establishing a naming convention is a simple action that can give you a great payback over time.


The "Azure Governance" series

  1. How to organize your subscriptions
  2. Naming conventions