One problem when working in an enterprise company is that there is a lot of people (developers, devop's and operation engineers) is allowed to create their own services and solutions, and this can be very messy if you don't have any convention's.
So the main purpose of naming conventions in Azure is to get a better way to navigate and maintain system and services hosted on Azure. This will also get a more detailed and clear overview in regards to billing and usages of their services.
Me and my team have made the following naming conventions, that is used for services in all environments on Azure:
{Environment}-{Purpose}-{component}-{geographic zone}-{datacentre}-{company}-{service}
This gives the following abbreviation naming pattern:
{prd|stg|tst|dev}-{Purpose}-{dvc|pdt|plc}-{us|eu|ap}-{e|w|n|s}-{wdx}-{rg|asp|tm|ws|sql|st}
Note:It is not all azure services that is able to follow the naming pattern. There are services that do not accept “-“, for example the azure storage accounts. The last example shows how the pattern would looks like without “-“.
Examples
·
prd-dvc-eu-n-wdx-asp is a app hosting plan for the production
environment for the dvc project (dvc
is an abbreviation of devices) in Europe North data center.
·
stgdvcdcoeuwwdxst is a storage account for the staging
environment on the dvc project and
is specific for the component datacollector
service.
Geographic
zones and datacentres
There should always be a default Datacentre to use. Example EMEA North, if there is a need to have
failover or has a need to bring data closer to countries, you can split them of in for example three different geographical zones. Every geographical region has a primary
datacentre and a corresponding failover datacentre. if you think of having you default datacentre in EMEA I will recommend EMEA West, it seems that new services is available sooner in west than in north.
• Americas defined as [us-e] or [us-w]
• EMEA defined as [eu-w] or [eu-n]
• Asia-Pacific defined as [ap-s] or [ap-e]
Geographical zone
|
Abbreviation
|
Primary or failover
|
Americas East
|
us-e
|
Primary
|
Americas West
|
us-w
|
Failover
|
EMEA West
|
eu-w
|
Failover
|
EMEA North
|
eu-n
|
Primary
|
Asia-Pacific Southeast
|
ap-s
|
Primary
|
Asia-Pacific East
|
ap-e
|
failover
|
Azure
services
Short list of the Azure
services can be identified by an abbreviation, here is a short list to get an idea.
Service
|
abbreviation
|
TrafficManager
|
Tm
|
Website (obsolete)
|
Ws
|
Web App
|
Wa
|
SQL Database
|
sdb
|
SQL Server
|
sql
|
Storage
|
st
|
Resource Group
|
rg
|
App Service Plan (old web hosting plan)
|
asp
|
DocumentDB
|
ddb
|
DocumentDB Account
|
dda
|
Virtual Network
|
vn
|
Cloud Service
|
cs
|
Azure Service Bus
|
sb
|
Virtual Machine
|
vm
|
Virtual Images
|
vmi
|
Subscriptions
|
sub
|
Virtual Images
|
vmi
|
Azure
environment setup
There are 4
different environment setups in our azure naming conventions. They all 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.
Environment
|
abbreviation
|
Production
|
prd
|
Staging
|
stg
|
Testing
|
tst
|
Development
|
dev
|
Hope you think this information was informative, and if you have any suggestions or other ways of doing this, please let me know.
/ronnie
