I prefer to see the resource type as a prefix, while the environment (dev, qa, uat, prod) as a suffix. In the middle, I like to see the purpose of the resource.
So my format is:
<what>-<why>-<where>
What: The resource type
Why: The purpose / project
Where: The environment (eg. dev, qa, uat, prod)
This naming convention allows me to see all the resources ordered by their type (eg. sql for SQL Server). In the following example, I can visually scan for "sql"
sql-myproject-dev
sql-myproject-qa
sql-myproject-prod
sql-thierproject-dev
sql-thierproject-qa
sql-thierproject-prod
Notice that this allows all the sql resources to be grouped by project name. Using the suffix, I can then easily see the environments related to those projects.
In the examples below, the I use "nicename" for the "purpose".
Naming
General rules:
- All resources (including resource groups) are lower case
- Where hyphens are not permitted, simply omit them. eg. storagenicenameprod
- Use industry accepted abbreviations (eg. vnet, app, net)
- Where there is no widely accepted short abbreviation, use full words (eg. search for Azure Search)
- Where character limits are imposed, fall back to acronyms (last resort as this is harder to understand)
Resources groups
rg-<purpose>-<environment>For example:
rg-data-prod
rg-net-prod
rg-web-prod
Data Group - Data / storage related
Examples:
- Database server
- Blob Storage
- Table Storage
- Azure Search
Net Group - Network, Security and Protocol related
Examples:
- Virtual Network
- Network Security Group
- Application Gateway
- Azure Front Door
- Load Balancer
Web Group - Web App & Content Delivery related
- App Service Plans & App Services
- Functions
- Sendgrid
Resources In General
<resource type>-<purpose>-<environment>Examples:
app-nicename-dev
search-nicename-prod
sql-nicename-qa
App Service Plans
Examples:asp-nicename-dev
asp-nicename-qa
asp-nicename-uat
Example Resource Group: rg-web-prod
asp-nicename-prod
App Services
Examples:app-nicename-dev
app-nicename-qa
app-nicename-uat
app-nicename-prod
Example Resource Group: rg-web-prod
Example Resource Group: rg-web-prod
SQL Database Server
sql-<purpose>-<environment>Examples:
sql-nicename-qa
cosmos-nicename-prod
Example Resource Group: rg-data-prod
Databases
db-nicename-<environment>Examples:
db-nicename-qa
db-nicename-prod
Example Resource Group: rg-data-prod
Azure Search
search-<purpose>-<environment>Examples:
search-nicename-qa
search-nicename-prod
Example Resource Group: rg-data-prod
Virtual Networks
vnet<int>-<environment>Networking is an interesting exception, as I prefer to take a numbering approach at network levels. This is because networks can be used for all types of purposes. I also like to keep the network dependencies together. So I will prefix the Network Security Group (nsg) with the name of the the vnet.
Examples:
vnet01-dev
vnet02-prod
Example Resource Group: rg-net-prod
Network Security Group's related to a VNet should follow the pattern:
<vnet>-nsg-<purpose>-<environment>
Examples:
vnet01-nsg-appgateway-prod
vnet01-nsg-frontdoor-prod
Example Resource Group: rg-net-prod
In this example the "purpose" is to attach a Network Security Group to the Vnet for the Application Gateway and Azure Frontdoor
Application Gateways
agw<int>-<environment>
Examples:
agw01-uat
agw02-prod
Final Thoughts
Naming things is a balancing act which I (and many) struggle with. Something that you are happy with might start annoying you years later. What ever you choose, try to ensure that your naming is understandable, consistent, and easy on the eyes.
Also, keep in mind that you probably won't like your naming convention in the future :)
Also, keep in mind that you probably won't like your naming convention in the future :)
No comments:
Post a Comment