July 1, 2022 at 12:00 am
Comments posted to this topic are about the item The Useful Cloud Tags
July 1, 2022 at 12:57 pm
The tags I found most useful are Application Name, Integration Name, and Owner. For Owner we sometimes use a Team name but if it is one primary person we might use something like 'Scott - Dev Team' to indicate I am primary person but it belongs on our team if I am not available. We are also evolving to a naming standard for resources and we are minimizing shared resources so that a Resource Group only contains items for one application so if that application goes away all it pieces can be removed easily.
July 1, 2022 at 2:24 pm
We have a tag for "environment" which we use to specify the workload; typically "prod", "dev" or "test". These tags are then used to apply varying policies, backup retention, LAW, etc.
July 1, 2022 at 6:20 pm
We use tags, but having a standard naming convention really keeps the confusion to a minimum. Something like "LA34532345454" would make me cry.
We have a very long internal wiki page that describes our naming convention for every type of Azure resource we use, with reference to a second wiki page containing a standard set of abbreviations for Geography (for example, EUR for Europe) and Regions (for example, WE for West Europe). We encode an acronym for those, along with one for the application or business service name, the item type (for example, EP for Elastic Pool), the environment (DEV for development), other type specific naming elements into our names in a standard order, and a standard element separator for readability.
Because of this, we have never run into an issue of finding a name we want that must be globally unique already being in use. Another advantage is that when I see an alert, for example, I can tell just from looking at the name of the referenced item what it is, where it is located, and whether it is production, test, dev, etc. I have gradually memorized the type abbreviations (like DB for Database and EP for Elastic Pool) and which Regions we use for Database Primaries and which we use for Secondaries so I don't have to keep looking them up in the wiki. One drawback to this is our names tend to be very long, and they can often be truncated when displayed in some of the Portal pages.
Here is a plain text paste of the table of contents from our wiki page:
1Introduction
1.1Purpose
1.2Definitions
2Naming Convention
2.1Application Service Plan
2.2Application Insights
2.3Availability Set
2.4Azure Active Directory
2.5Azure Active Directory RBAC Group
2.6 Azure Active Directory Service Account
2.7Azure Active Directory User
2.7.1DisplayName
2.7.2 Username
2.7.3 AAD Identity Name
2.8Analysis Services Server
2.9 Azure Automation Account
2.10Azure CDN
2.11Azure CDN Endpoints
2.12Cosmos DB account
2.13Data Factory
2.14Data Share
2.15Domain Naming for Client Facing Applications
2.16Domain RBAC Job Function Group
2.17Enterprise Agreement Account
2.17.1Account name
2.17.2Associated Microsoft account
2.18Event Hubs
2.19Function Application
2.20KeyCDN Zone
2.20.1Production
2.20.2Other Environments
2.21KeyCDN Zone Alias
2.22KeyVault
2.23Load Balancer - External
2.24Load Balancer - Internal
2.25Local Networks
2.26Log Analytics Workspace
2.27Logic Apps
2.28Logic App - API Connections
2.29Machine Learning Workspace
2.30Machine Learning Web Service Plan
2.31Network Security Group (NSG)
2.32Network Security Group Rule Names
2.33Office365 Entity name
2.34Office365 OnMicrosoft name
2.35Office365 Service account name
2.36OMS Workspace name (deprecated - use Log Analytics Workspace)
2.37Power BI Embedded
2.38Public IP
2.39Recovery Services Vault
2.39.1Recovery Services Vault – Backup Policies
2.40RedisCache
2.41Resource Group
2.42SendGrid Account
2.43Service Bus
2.44Service Fabric Cluster
2.45Storage Accounts
2.45.1Storage Account – Cool Tier
2.45.2Storage Account – Premium
2.45.3Storage Account - Standard
2.46Subnet
2.47Subscription
2.48SQL Resources
2.48.1Azure SQL Database
2.48.2Azure SQL Database Account
2.48.3Azure SQL Elastic Pool
2.48.4Azure SQL Failover Group
2.48.5Azure SQL Server
2.48.6IaaS SQL Service Accounts
2.49Stream Analytics Job
2.50Traffic Manager
2.51 Virtual Network
2.52 VM
2.52.1Azure Active Directory Connect
2.52.2Local Administrator Account
2.52.3 Network Interface
2.52.4 SQL Cluster
2.52.5 Scale Sets
2.52.6 Virtual Hard Disk
2.53WebApp
2.54Synapse Analytics Workspace
July 4, 2022 at 7:15 am
I'm surprised no-one has mentioned tagging for cost tracking.
Cost tracking and reporting in the cloud is important if you want to identify where the unexpected bills are coming from.
Creating a meaningful taxonomy of tags requires care. I'd advise looking at tags from two perspectives
As to SQL Server extended properties, I wish they'd overload the maintenance of descriptions with a COMMENT ON <<object>> IS 'What ever the comment is'; syntax.
For that matter what is wrong with CREATE OR REPLACE PROPERTY <property name> ON <object> IS <property value>?
July 14, 2022 at 7:25 pm
Great discussion! All the replies are meaningful. I have used tags like below
Name - value would be typically resource name
Division - value would be name of the division or the code as used in the organization
Environment - value would be stages of developement. Dev,QA or prod.
Platform -value would be data or application or storage etc.
Created by -value would be individual name. I think it is good to use team name here instead of or in addition to individual name.
David Poole has a great suggestion to use CostCenter. Keeping standard naming convention as stated by M60freeman is very important. Thanks for great discussion point Steve!
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply