[Work_Item] Bring your own license support

[flanakin]

Problem Statement

Bring your own license (BYOL) is a common scenario across cloud providers and a key part of rate optimization activities. In order to help practitioners identify when a discount is applied because of BYOL, there needs to be a way to identify when it's applied.

Objective

Define a set of columns needed to identify and quantify the impact of BYOL use.

Supporting Documentation

• https://learn.microsoft.com/windows-server/get-started/azure-hybrid-benefit
• https://learn.microsoft.com/azure/virtual-machines/linux/azure-hybrid-benefit-linux
• https://learn.microsoft.com/azure/azure-sql/azure-hybrid-benefit

Proposed Solution / Approach

Some potential columns:

• SkuLicenseCategory to indicate the license being used (e.g., Cloud, On-Premises).
• SkuLicenseType for the type of license being used.
• SkuLicenseStatus to indicate whether the license is used or not (e.g., Enabled, Not Enabled, Not Eligible).
• SkuLicenseQuantity for the metric that determines how many licenses are used.
• SkuLicenseUnit for the unit of the quantity (e.g. "Cores").
• SkuPriceDetails.Cores may also need to be explicitly called out for core-based BYOL to compare what was used by the resource vs. what the license required (in case it is rounded up).

Epic or Theme Association

Rate optimization, Licensing, BYOL

Stakeholders

Thumbs up from issue #311:

• @hrishikeshsardar
• @matdriks
• @dflood007

[kk09v]

I would think about this the same way as any other license and I believe that the license should have its own record, regardless of whether it's paid or free (either actually free or paid for via another agreement) rather than being bundled with the virtual machine.

So under my thought process, I'd see the following records for a VM in Azure running Windows Server (for instance)

• I'm charged for a Virtual Machine.
• This Virtual Machine consumes 8 licenses (on a per core license).
  • There would be separate a SkuPriceId for an AHUB (Azure Hybrid Usage Benefit) license with a unit price of $0 versus a PAYGo license which would have a non-zero unit price.

With my limited thinking on this topic so far, I believe this approach would allow all of the reporting and analysis without driving the need for additional columns to be introduced. This would also allow for a situation where we have commitments which are applicable to the licensing component but not to the underlying components, and it would help enable analysis to answer questions such as "how much are we paying for licenses?"

[thecloudman]

I think this idea is great but am concerned about the number of additional columns. Could we consider a SkuLicenseDetails Column JSON formatted and have all the details in there such as {"LicenseType":"RHEL", "LicenseCategory":"BYOL", etc....] and then use SQL queries or other methods to pull that data by the practitioner and provide use cases on how to do that? Would be very good to have the core count of the item being applied to and the core required count and an ability to add in your per core cost of your BYOL licensing to get a full end to end view.

Additionally, it would be good to be able to use marketplace data for license purchases for example when you use VMware engine in cloud you cannot use existing BYOL Microsoft SA licensing for windows and Microsoft application licensing and need to purchase cloud licenses (gcp does this) or windows licensing from a 3rd party through the marketplace, we should have a way to bring that into the fold too?