In the DevOps and FinOps world we often have a conflicting requirement around tags. In the FinOps team we need to be adding metadata to be able to create appropriate views of our Azure Costs.
In the DevOps world we are focused on delivering a solution and cost management is often not at the top of the priority list until much later.
The problem is that there is only a single set of metadata tags and they are often managed as part of an infrastructure as code solution by the DevOps team.
Your FinOps team may want to add a new tags or modify a tag value but they don’t want to get the DevOps team to redeploy stuff every time this need arises.
What we need is an approach which allows the FinOps team to evolve their needs without the friction point created by the dependency on the DevOps Team.
In this blog post we will look at how we can implement an IaC approach using Bicep to help both teams meet their needs.
As a side note, as we work through this article the script that is used is available at the following location:
The sample with an example basic Bicep script is at this location:
DevOps Perspective
In the target state, I want to deploy resources in DevOps with a set of tags that I manage as part of a Bicep file. I will evolve and change these tags however I like as a DevOps person.
I am mindful that my FinOps team will be adding some tags outside of my DevOps process and I want to ignore those tags when I do my deployment.
In the image below you can see there are two tags called FinOps-Team and FinOps-Department. The FinOps team will be adding these themselves via a process that’s external to my DevOps process. When I do my deployment I want to preserve these tags post deployment.
In the below image in my Bicep script you can see where my DevOps engineer is managing some tags for the resource but they are not managing the FinOps tags.
To achieve the desired outcome we need to modify our DevOps process slightly to look like the following.
To implement this process I have a Powershell script which will wrap my Bicep deployment and it will handle the archive and restore process.
In the next section we will take a closer look at that script.
Running the Script
When we run the script you can see in step 1 it will inspect resources in my resource group and look for any resources which have a tag matching the prefix “FinOps”.
It will then back up these tag values.
Next up the script will run the Bicep deployment. My new and updated resources will be deployed.
By the nature of how Bicep works it will replace the tags on the resources with only the ones configured in my Bicep.
At this point I have 2 challenges:
- New resources will be deployed which might not have my FinOps tags
- The existing resources will have their FinOps tags removed.
The final part of my script will now run as shown below.
In this case one of the resources was not in the Bicep file so it still has the FinOps tags on it, but the other resource had its FinOps tags removed so the script will now replace those tags with the ones which were backed up earlier.
Conclusion
By wrapping my Bicep deployment inside the Powershell script I have been able to preserve the FinOps tags across my deployment. I now have the below positive outcomes:
- FinOps tags preserved
- FinOps team can add and update their own tags on the resources with their own scripts and 3rd party tools
- DevOps team can deploy new stuff and modify resources without having to worry about impacting the FinOps team.
The new resources which I have provisioned will not have tags on them, but the FinOps team can continue to use their existing processes with their scripts and external tools to manage their chosen tags.
The result here is we have been able to break the dependency between the FinOps and DevOps team to allow them to both get on with their primary focus without blocking each other which is hopefully a good win for both teams.
