FinOps-Open-Cost-and-Usage-Spec / FOCUS_Spec

The Unifying Specification for Cloud Billing Data
https://focus.finops.org
Other
147 stars 30 forks source link

Add a Commitment-Based Coverage column to rows that are or potentially can be covered by a Commitment. #406

Open cnharris10 opened 2 months ago

cnharris10 commented 2 months ago

Type

Dimensions Normalized? Yes

Description

Commitment coverage is calculated as: # of running hours of committed usage / # of hours of committed + on-demand usage. This ratio helps practitioners determine how much savings potential still exists across their platform. Based on their coverage goal(s), practitioners can determine if they want to purchase additional commitments or not.

For even the most advanced practitioner, it is a non-trivial task to determine whether an on-demand usage-based charge is eligible for a commitment (and which commitment) or not. While practitioners likely know that spot/preemptible VM's across clouds are not available for commitments, identifying and excluding these resources to exclude from commitment coverage calculations is non-trivial.

More so, attempting to exclude SKU-specific rows from coverage calculations is much more tedious as a practitioner must ensure that they understand cloud or SaaS-based documentation perfectly to achieve an accurate calculation. See below more details.

The goal of this column is to:

  1. Provide an easy way for pracitioners to calculate and drill down into commitment coverage details.
  2. Categorize whether ever on-demand line item is eligible for a commitment, and if so, what type(s)?
  3. Roll up Commitment Discount Types to a "Resource", "Spend", or (rarely) "Other" categories.

--

For visibility around some of these restrictions, the following are few restrictions across AWS, Azure, and GCP:

  1. AWS a. Spot instances b. P5 instance family c. Mac instance families d. Ubuntu OS

  2. Azure a. Spot VM's b. VM series - A-series, Av2-series, or G-series

  3. GCP a. Preemptible VM's b. n1 shared-cost, or extended memory VM's

mike-finopsorg commented 1 month ago

We just need to be clear the goal here isn't for the practitioner to use the value as a direct coverage calculation (e.g. Lines that are covered by a commitment-based discount over those lines that are eligible for a commitment-based discount).

However, that isn't the right approach to "coverage" calculations just because a single line charge could be covered by a commitment, does not mean it is financially sensible to have it covered. While I see the value in this field I think we need to be clear on how the practitioner should use the column correctly.

cnharris10 commented 1 month ago

We just need to be clear the goal here isn't for the practitioner to use the value as a direct coverage calculation (e.g. Lines that are covered by a commitment-based discount over those lines that are eligible for a commitment-based discount).

However, that isn't the right approach to "coverage" calculations just because a single line charge could be covered by a commitment, does not mean it is financially sensible to have it covered. While I see the value in this field I think we need to be clear on how the practitioner should use the column correctly.

@mike-finopsorg

100%. The goal is to expose what is eligible for coverage by commitments, because it's hard enough figuring out what is/is not eligible. We should definitely clarify that we're not giving an opinion on a coverage strategy based on aspects like target rates, on-demand fluctuation percentages, or similar.

I envision people doing roughly the following:

1. Determining their coverage percentage.

(SELECT SUM(ChargePeriodEnd - ChargePeriodStart) FROM <table> WHERE CommitmentDiscountCategory IS NOT NULL AND ChargeSubCategory = 'Used') 
/
(SELECT SUM(ChargePeriodEnd - ChargePeriodEnd) FROM <table> WHERE CommitmentDiscountCategory IS NOT NULL AND ChargeSubCategory IN ('Used', 'On-Demand'))
* 100

2. If above coverage rate target, query rows (or rollups), drill down further into coverage rates above where coverage is higher than expected.

3. If below coverage rate target, query rows (or rollups) with on-demand spend with a CommitmentDiscountCategory value to determine what to do next.

SELECT * FROM <table> WHERE ChargeCategory = 'Usage' AND ChargeSubCategory = 'On-Demand' AND CommitmentDiscountCategory IS NOT NULL