On the Tagging options
Tagging is the act of putting labels on objects. There is 1:n relation, meaning one object can have many labels applied to it.
Traditional systems that implement tags are usually backed with a “set” data structure: an unordered/unindexed collection. The key is the value. E.g: Prod, Dev, CC127638, Finance
Immediate limitation: you have to guess the key from the value. For the previous example, it may be obvious that we are talking about environment or lane for the Prod and Dev values, depending on your company’s lingo. But how would you differentiate a cost center and an app owner? It is subject to interpretation.
We need a key:value structure for better clarity.
On modern cloud platforms, Tags tends to be at least a key:value pair which make use of “dictionary” data type. E.g: Environment:Prod, CostCenter:127638,Owner:Finance.
On OCI, this is the first type of tags available, and it is called Freeform Tags. You can use it with arbitrary keys:value pairs.
The second type of tags you can use on OCI is called Defined Tags. They add a namespace construct to Tags. The data type becomes key:dic, the value is a dictionary itself, hence able to contain a nested key:value pair.
This is particularly interesting to aggregate directly related tags together. E.g: Operations.Environment:Prod, Operations.Owner:Finance, Operations.State:Live, Finance.CostCenter:127368, Finance.Budget:378473
The syntax is now namespace.key:value
Another advantage of this new construct is the scheme definition: the keys are not arbitrary anymore, they are defined in advance. This effectively helps to prevent Tag Sprawl ans misspelling.
There is much more to Defined Tags on OCI, and we will explore it later. For now we can summarize the following about Tags & OCI:
- Freeform Tags are arbitrary key:value pairs,
- Defined Tags are a collection of tags regrouped as namespaces.
1️⃣ You should use Defined Tags almost every time, as they are more feature rich and allows better control and governance.
A good use case for Freeform Tags
Freeform Tags are best to use when you don’t have Defined Tags ready yet, just after tenant creation for example. They can also be useful when you want to keep some tags independent from the global tagging strategy and/or avoid any circular dependency. How do you tag your tagging namespaces with a defined tag during an automated process? 😅 -> 🐔 + 🥚
2️⃣ Make it clear whether a component is created manually or by an automated process.
For exemple, when deploying infrastructure with Terraform, you can « watermark » the resource with a specific freeform tag, same with other automation tools:
Terraformed: <value>
Ansibled: <value>
Hashipacked: <value>
<value> may be a timestamp dated from the last modification time. This « watermarking » Freeform Tag would just be absent if the resource is created manually.
That’s it: you can now quickly search for the presence or absence of your watermarks.
An alternative proposition: using more generic tags to label your IaC strategy :
Automation: Terraformed/Ansibled/xxx
ConfigMgmt: Chef/Puppet/Salt/Tower
This second solution may be more suited for a defined tag namespace.
Additional metadata regarding the automation tool may be useful: for exemple, if the component is provisioned by a terraform module, it doesn’t hurts to add a Freeform Tag for that: TF_Module: xxx.
Using freeform tags for objects created by Terraform allows to tag any resource right from the beginning, without having to rely on Tag Namespaces not being provisioned yet.
3️⃣ When editing an existing object with Terraform, for example the Default Security List automatically created with a VCN, leave a trail for any other user : Terraformed: Default Security Rules edited.
Beside of the exposed use cases, try to keep Freeform Tags usage really exceptional and use Defined Tags instead as much as possible. They offers lot more of features like usage control, consistency, defaults, variables, and more to come.
New features and innovation for Tags comes only on Defined Tags, not on Freeform Tags.
Leave a Reply