One of the things I’ve seen in working with cloud based resources is that you get a lot of them in your account quickly. A database might end up with a server, an IP address, a network, security groups, and more. A few clicks of the mouse in the Azure Portal can create a new Resource Group that doesn’t just have the one thing you need, but 3, 4, or more other items.
In addition to the quantity, there are also the problems of namespaces in cloud resources. Some of the items you provision are publicly named in a domain, such as database.windows.net. In these cases, the resources need to be unique among all cloud customers. Just like domain names, this means that you might have collisions with your favorite name. While I might like jones.com, there are a few other people that would likewise prefer this. The rest of us might have to choose jones2.com, stevejonesincolorado.com, or some other variation. In large organizations, you might end up with LA34532345454.database.windows.net for an Azure SQL Database.
That means that the names of the systems don’t make sense to anyone, and many of the people that need to use or manage them will not even know which resource belongs to which system. This has been true for servers in many organizations for a long time, even with their own domains. Often there is some document, perhaps stored on the root of the machine or in an online share, that provides more information for people accessing the system.
The cloud makes keeping track of systems harder, and there is a greater need to classify, categorize, and tag resources. Most of the cloud providers have built extensive tagging systems that help users add metadata to various resources and search/filter by these tags.
Today I’m wondering which tags are useful in the cloud? How do you decide which tags, or type of tags, to apply? You might choose to apply an application name, a business department or owner, or some other type of information that helps you keep track of which resources are needed and how to deal with them. Is there some guideline on the type of key-value pairs you use for tags?
I also would you want to easily have tags for on-premises SQL Server instances? We do have extended properties, but those are cumbersome. Would you want some sort of easy system query that retrieved all tags. Perhaps something like @@InstanceTags or @@DatabaseTags that retrieved all the data you’d stored in extended properties.
We are only seeing more and more resources that need to be managed, patched, and deployed. Tagging is one of the ways that helps our organizations keep track of resources, especially if we provision them and we move on to our dream job somewhere else. Let me know how you handle things today.
Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.
Tagging strategies are messy, just like server names. I should write a blog post about this. Effectively, I feel like tags should be used for at a minimum two major functions:
1) Who the resource is billed to and is paying for it
2) Enough technical information for an on-call engineer to know what they are working on (e.g. system, tier, SLA, etc)
You have 15 tags available (in Azure) per resource. VMware also supports the use of tags, as does Kubernetes, so it’s not exactly unique to the cloud.