What is a Tag and why do we care?
Tags are an essential component in managing your Cloud and Virtual resources. The Resource platforms (clouders or hypervisors), whether it is on premise Virtualization or Public Cloud virtualization, has very few common ways of communicating business metadata to the inventory tools, and the Platforms are typically of a more technical nature.
This also means that it is hard to identify what the resources are used for and what impact they have to the business. If you do not understand the usage of the resources, it is hard to Optimize cost, Identify Risk, route and prioritize the work effectively on the resources.
In case you do not get this data from the resource platforms, a lot of manual work could go into identifying the business context for all the resources. This is why it is so important for the business that this information gets automated and built into all processes, starting with the request and provisioning processes.
The most common way to communicate between the resource platforms like AWS, Azure, GCP and VMware and the business system is by using tags. A tag is a key pair containing a name and a value. Each resource can have one or more tags. (This is an example of Amazon Web Service – Instance Tag section). The different cloud providers are considering tags as best practices (example of Azure: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources )and so many organizations and solutions are leveraging them in processes
From the cloud provider console, there is no real governance or checks that ensure the tags are used consistently, and no standard tags that can guide the user.
Tags are more or less free form, and in that lay the biggest reason for a Tagging strategy. Your tag strategy should not only contain tag definitions but also define how to include governance and enforcement of the strategy.
Some organizations have implemented a consistent tagging strategy of their cloud resources which provides a complete scalability, agility and control of their processes.
Please know that Tags can be named in different way like Key Pair, Labels etc. This document will use the term Tag(s) for all these ways of adding information to the Resources.
Things to consider
What data is important for your business?
You properly have some business and management values you would like to track for your resources, but you also need to look at your organizations requirements for mapping the resource usage back to the business. Typically, it could be Cost Center, Owner, Location, Business Service etc. It is not important which tags or how many tags you make part of the mapping as long as it follows the company’s processes and support data integrity. At the end of the day the goal of the Tagging strategy is to have enough insight to all resources to know exactly what impact it has to the business. E.g. what happens if it is deleted?
How many tags do I need?
There is no golden number of how many Tags should be managed/mandatory, you should have enough to support the business but not too many that will become a management nightmare, you should also consider having Mandatory and Optional tags. If you choose to have optional tags, you cannot expect to enforce values for the optional tags, so they will become more as a guideline or a recommendation.
Commonly used Tags
This is a list of common tags, that is used by companies around the world, you do not need to implement them all. Please note that the actual name could be shorten. e.g. Environment could just be env, or Cost Center CC. it is not important if it is one or the other, just that it is the same for all resources.
- Cost Center: the cost center which the resource should be charged back to, or cost center responsible of the Resource.
- Owner: The person that is responsible of the resource
- Application/Service: The name of the Business Service that this resource is part of.
- Environment: The environment type e.g. Production, UAT, Demo.
- Hostname: Name of the host given resource if it differs from the Platform name
- OrderedBy: The person that ordered the resource.
- RequestID: The id from the initial request. This could help eliminate a lot of the tags, if you ensure that the business information is stored in the request.
- Scheduling: In the case of a scheduling is being used this could be used to indicate to the management system what scheduling it needs to be on. As an example of scheduling could be only run workdays 8-18
Implement the strategy in all Processes
Organizations should ensure all processes, documents, governance are in line with this Tagging strategy. A global communication is mandatory to enforce compliancy between departments and teams. What we usually see is that each region, department or team has their own tagging strategy which is not consistent. Therefore, a first approach would be to put in common all tags keys that are necessary for each team. Then agree on the naming conventions and the values that are authorized for each tag keys. An official document referencing the mandatory and optional tags should be the output of these synchronizations.
The next steps would then be to find the right methodologies and tooling to apply to each process that are managing tags (request and provisioning process, monitoring the tags in the cloud…)
Monitor deviants
You should set up a couple of views or dashboards to monitor that all mandatory (and optional) tags exist on all Cloud/VM resources. This should be both for identifying misspelled Tags name (keys) and to identify missing or wrong tag values.
Tags handling in ServiceNow
As Tags are an integrate part of communicating business and technical information from the cloud resources, ServiceNow do recognize and make use of them on many different levels. This is a list of functions in ServiceNow that are available and could be considered when you plan and implement your Tag Strategy.
Servicenow Cloud Discovery and Service Graph Connectors for cloud
You can’t manage the data if you can’t see it. A big part of supporting and automating the Business Processes is to discover the data that will underly them. Servicenow Discovery solutions enable to discover the cloud and Hypervisors but also all the tags associated to each resource (the solutions do much more but we’ll not detail all capabilities in this document). These tags will be located in the “cmdb_key_value” table. It will be organized as follow:
So once discovered in the CMDB, if tags have been set on the resources in the cloud, each resource will have as many key/value pairs as there are effectively in the cloud.
A first benefit from this is that you can have a central and agnostic visibility and management of all Tags coming from different Cloud providers. When Navigating to a specific resource, A CMDB manager or a process owner could easily understand what the resource is used for and who owns it for example.
This is the starting point for all following processes.
Example of Tags list in Servicenow
Example of a discovered resource and its tags
The Tag values can be part of any automation to import tag values into the actual CI’s attributes as an example a Cost Center tag value could be captured and update the attribute on the CI (If it is a change process accepted by the Business)
ServiceNow Tag based Service Mapping
One of the first business requests from discovering cloud data is to attach the cloud resources to the right application. Actually, Business stakeholders and IT users are more likely to work and manage the application layer because most of employees know what the application is used for in the organization (the application portfolio repository may need to be well set and maintain internally). Whereas a specific resource on its own won’t have the same attention from the same users.
Tags are really essentials for this purpose as Servicenow proposes to map applications based on resources’ tags. This is one of the most scalable and the easiest service mapping methodologies.
Creating Tag-based Service maps implies several steps:
- Identifying the relevant tag categories that are part of the mapping process. Example:
- List of tag keys that identify the application: AppName, app, Application, BusinessApp…
- List of tag keys that identify the environment of the Application: Env, Environment, Scope…
- Combining each tag category with a specific value to map an application. Example:
- Application Category = Order Management
- Environment category = Prod
The result will provide an application service object as the example bellow:
Every Cloud resource that has the right combination as mentioned above will be part of the same application Service. Now that we have created the Application Service, it can be related to the business Application and Service Offering Layers to support the organization processes.
CSDM and ServiceNow standard processes
There is many documentations on ServiceNow sites regarding CSDM, please refer to these documents if you want to know more about CSDM.
If CSDM it is used in the right way, it will complete the business structure on top of the cloud infrastructure resources. Each CSDM layer concept will then provide the right data to fuel automation and process execution.
CSDM example and how it brings data to the process at each layer
For example, when an incident is created from an alert which is bound to the cloud resource above, the assignment group will be automatically populated with the information provided on the Business service offering layer and this will trigger SLAs and reduce MTTR.
Another example: when a project team decides to stop the development of a specific Business Application they can deprovision the Cloud resources associated to the project and avoid unnecessary costs.
ServiceNow Cloud Cost Management
Another important request from the business and the cloud team is to control the cost. We have given an example in the previous section on how to correlate a Business Application with its cloud resources and so manage the ownership and indirectly the cost per teams or Business App.
But this approach doesn’t give the actual spent and the recommended optimizations that a cloud team could apply to reduce their cloud footprint.
This is the role of Servicenow Cloud Cost Management that downloads the bills from the Clouders and associate each Cloud resource cost with the right cloud resource in the CMDB.
Cloud Cost Management Interface
You can then filter on the right tag key that represents the Cost Center for example and spread the cost between each team.
ServiceNow Cloud Service Catalog
When implementing a cloud service offering, several attributes should be set as tags in the provision phase, so it is picked up during the Discovery process. ServiceNow Cloud Service Catalog comes with a predefined set of tags that are applied to each cloud request and this list can be customized. Additionally, the values for the tags can be enforced with policy rules to ensure the naming convention is respected.
Example of a cloud catalog item with some mandatory attributes
How to stay compliant with the tagging strategy
We already discussed on the governance part that needs to include documentation, processes, tooling… Here are few suggestions on methodologies.
Give the reason why you are implementing a tagging strategy
Cloud consumers will most often see constraints on following tagging recommendations. Therefore, the team in charge needs to explain and communicate the reason why they are implementing it. Usually, the main reason would be to control costs. People need to be accountable of the cloud spend, so making sure that if they are not tagging properly their resources, they will have additional fees to cover “unknown cloud spent”.
Another example is to let the consumers know that their application won’t be monitored in case there is no good tagging in place and so they will be accountable of outages that impact customers or internal users.
Making people accountable and contributing to the same business objective will most likely improve their engagement in the strategy.
Pre-deployment governance
One of the biggest challenges is to consolidate the different possible request channels that are used to request a cloud resource. Enforcing the tags before a resource is created in the cloud is the best solution but usually not the one that is the easiest to implement.
A service catalog in a portal could streamline the request process and trace all demands into a system with all mandatory information concerning the requested environment or resource (with the right policies in place for the values and the naming convention). As described earlier, ServiceNow Cloud Service Catalog could support this initiative.
You can also create a standard request catalog on your own that references all necessary information for the cloud resource. If this catalog is integrated with the provisioning process or the DevOps pipeline, it is even greater as you could pass all tags from the catalog to the resource (with the good scripting and API in place).
If not connected with the provisioning process, you should at least reference a request ID which will be present in the catalog and also you will have to reference it all the way from the provisioning workflow to the cloud resource tag.
Another methodology is to put in place guardrails or check policies during the provisioning process. Some tools can verify if tags are present and if they respect the good naming convention. Servicenow DevOps Change Automation can aggregate data from the DevOps pipeline and centralize all the information in a change before it is deployed in production (or in the Clouders). Therefore, the information on the tagging of the resource could be pushed into the change and some policies could be applied to validate and approve the change if there are respected.
There are many other possibilities, but we’ll not describe them in this document.
Post-deployment governance
This may be seen as the easiest way as you don’t necessarily change the provisioning process in place and you are not constraining the requestor or the people responsible for the request process. But on the other hand, it means that the quality of tagging may be poor afterwards and then you would need to remediate too many of them.
So, a hybrid approach may be the good solution between the pre-deployment and the post-deployment governance.
ServiceNow Tag Governance enables you to control and assess the health of the tagging strategy. Running Policies identify Cloud resources that are not compliant regarding the tagging strategy. Tasks are created on each resource that are not compliant and affected to the right team for remediation. If you have the necessary credentials to access and modify the tags directly from ServiceNow to the cloud, the remediation can be done automatically.
Tag governance in ServiceNow
Find a workaround before tagging at scale
If organizations haven’t adopted a tagging strategy from the beginning of the cloud journey, it may be challenging to implement it on existing process because cloud teams and requestors could think their agility could be impacted. So, enforcing a new change globally in a Big Bang approach would not get the expected results.
therefore governance team needs to plan a phased approach that could be adopted in a much easier way by the corresponding team. In any case, for the new resources that would be requested and deployed, they should enforce the new tagging strategy, but for the existing one they should get knowledge from the team responsible for the resource and proceed step by step.
Cloud accounts, subscriptions and resource groups
We see a lot of organizations using 1 cloud service account, 1 subscription or one resource group (when dealing with azure for example) for 1 application, 1 team or 1 project.
In this scenario we could interpret this structure as one entity representing a whole application or a whole department that hosts the ownership, costs and management of everything inside it. So, this entity could represent the Business application and the team responsible for it.
Business Tags (the ones that are the most useful for the mapping) can then at least be applied at this level. When discovered through ServiceNow Discovery, we could implement an automated process in ServiceNow to cascade them to all resources that are part of this entity. That way you could use all described capabilities from ServiceNow (Tag-based service mapping, CSDM, Cloud Cost Management…)
This is not the best-in-class solution, but it could solve some blocking points at some steps during the tagging implementation project
Relationship between Virtual machine, resource groups and Cloud service account (in Azure)
In the example above, the virtual machine has been discovered in Azure. It is related to a resource group and a Cloud Service Account (representation of a subscription). If the tags are present at least in the cloud service account or in the resource group, we could replicate them into the virtual machine.
When doing this, you should precise in the created entries in the “cmdb_key_value” table for the VM, a “tag” (this one is a ServiceNow concept that we’ll not describe here) that identifies it as a manual creation and not a discovered tag from the cloud (see below):
Example of an identification of a manually created tag
Conclusion
Tagging is important for ServiceNow but also for all governance models in organizations. These are best practices pushed by the Clouders themselves. The more tagging is respected the more automation and quality we could bring into the processes. ServiceNow is a solution that can help organizations get more value from their cloud investment, but it will not replace the need of a governance model and a team responsible for it.
