Once upon a time, not that long ago, everyone who’d spent time wrestling with Microsoft licensing looked to, at first, Office 365 (as it was known before rebranding) and later, Azure, as a source of relief.
“Relief” might be too strong; certainly, simplification. To focus on Azure, the subject of this blog, there was an expectation that using FinOps methods, for example, making architectural choices based in part on runtime cost impacts would be sufficient to achieve observability of cost generators.
According to legend, Aristotle stated that ‘nature abhors a vacuum.’ We might also say that Microsoft abhors a simple billing structure because complexity has returned, with a vengeance.
***
Consider, for example, the following architectures from a FinOps perspective:
Because this design uses platform services such as Azure App Service and the Azure SQL PaaS database, there’s a fair chance that its runtime cost is lower than it would be if key components were staged on virtual machines (this isn’t automatically true, but a bias towards platform services is a good place to start).
You might think that designing with cost in mind from an infrastructural point of view alone would be sufficient to anticipate and monitor the runtime cost of this design but there are other factors. And this is where licensing choices come into play.
Note that one of the critical elements of the design is identity and access management via Azure Active Directory; well, wait, what I should now say is via Entra ID:
Microsoft rebranded Azure AD as Entra a little while ago and brought along the pricing tiers of Azure AD:
This means that in addition to calculating the potential runtime cost of the infrastructure, you must also calculate the cost of the level of Entra ID deployed for users. If your enterprise environment is like most, you will at some point feel compelled to add data governance, data loss prevention and related capabilities and in the case of Azure, this means Microsoft Purview:
Purview pricing adds another layer of cost assessment complexity to the mix:
It’s typical for purchase decisions about adding services such as Purview and higher tiers of Entra ID to be made based on solving a problem and gaining a necessary capability – which is understandable. What’s also typical is neglecting to track the cost of these services and analyzing the need over time.
What’s often missing, in short, is applying the FinOps principle of observability to monitoring the cost and usage of services that, once purchased, seem to melt into the background (unless they don’t work as expected, which, as of this writing is happening quite a lot with Purview – but that’s a story for another time).
***
As Microsoft continues to add services to the Azure portfolio, and as those services fall into tiers whose runtime costs calculations become more complex, it’s important to factor them into your overall FinOps practice.
Azure FinOps 