Add Commitment Utilization columns to help practitioners easily determine Commitment efficiency

[cnharris10]

Type

Type of issue (e.g. Dimension, Metric, Attribute, Documentation etc.) Normalized? Yes

Description

Description of the issue

We need a way to track not just that a commitment was burned down via usage cost and/or hours but how it was burned down. For a partial commitment, how much of the drawdown occurred from an amortized upfront fee or a recurring fee.

Definition of done

• [x] Rationalize vendor-neutral, cross-cloud naming
• [x] Complete spec template and include naming (code name, display name), constraints, guidelines, compatibility with major providers etc. If Normalized Dimension
• [ x Include principles and governance criteria for maintaining this dimension

If Normalized Dimension Work for generating the normalized list of supported values is tracked in a separate issue. Mappings between normalized values and vendor specified values need to be explored as a part of this work. However, these mappings are not included in the spec documentation. Separate tasks will be created for making these mappings available to practitioners outside of the FOCUS repository.

[flanakin]

What do you mean by "how it was burned down"? A partial commitment would result in 2 rows. One with the committed usage and one with the uncommitted usage. Does that cover what you're after here?

[cnharris10]

I don't think that scales well with something like a savings plan. If a savings plan commit for $500/hour exists and it splits 100 ways per hour, that's a lot of rows to account for per month to determine how well a savings plan is utilized.

[cnharris10]

Without providing an implementation, I could see something like the following columns representing hours-based and spend-based discount programs with a CommitmentFee Charge Type:

• Used Commitment Quantity
• Total Commitment Quantity
• Commitment Quantity Unit

[flanakin]

Used Commitment Quantity is covered by PricingQuantity for usage and EffectiveCost for spend commitments, right?

Total Commitment Quantity isn't possible without merging with another dataset. And fwiw, I'm not sure that's posisble given the total can change over time as commitments are split, exchanged, etc. To that end, knowing the total per row could make sense.

Wouldn't the unit be the same as PricingUnit? Maybe the thing that's missing is the period. Is this within an hour or the entire commitment term?

Regardless, even with these 3, we still need a way to identify a row as being for unused commitment. So I think ChargeSubcategory = "Unused Commitment" still applied. Right?

[flanakin]

I flagged this as a potential breaking change, but I'm not completely sure. It's only potentially breaking if introducing these three columns would cause us to take something else away.

@cnharris10 Do you see this as additive or would it replace ChargeSubcategory for tracking used/unused commitments?

[cnharris10]

@flanakin Above is just one option, so take with a grain of salt. However, extending above for the purposes of this conversation, I see it as additive to ChargeSubCategory.

ChargeSubCategory gives you visibility around how your commitment was amortized across eligible resources, but it requires non-nominal work to determine how much of my commitment was used during a month (or other period).

For example ...

• Hour-based Commitments (Reservations / CUDs) --> It is possible for me to determine how many hours (or sub-hours) were used by summing all UsageQuantity values, determining how many hours exist for that month, and then sum(UsageQuantity) / number_of_hours(month), but I'd rather this data exist without doing the work.

• Spend-based Commitments (Savings Plans / Flex CUDs) --> It is possible for me to look up my hourly commitment (likely from an alternate source) for a spend-based commitment, sum up my EffectiveCost per hour and roll up to a month, and then dollars used / hourly committed total * number_of_hours(month), but I'd rather this data exist without doing the work.

I think an equivalent comparison is EffectiveCost. Someone could feasibly calculate EffectiveCost by amortizing commitments over their term, so BilledCost is really the only necessary column needing to exist. But, the FOCUS spec should (IMHO) aim to both expose raw data and abstract non-obvious logic (i.e. amortization, utilization, ... coverage?) to make it dead-simple for customers to understand.

[cnharris10]

Correction Above ...

I don't think that scales well with something like a savings plan. If a savings plan commit for $500/hour exists and it splits 100 ways per hour, that's a lot of rows to account for per month to determine how well a savings plan is utilized.

I thought the commitment would be split by instance type (AWS) but it is not, so the Hourly fee is 1 record and is not exploded. Disregard that point of the argument in this thread.

[flanakin]

Related #330

[jpradocueva]

Classified as Discounts by the Maintainers on the May 24 call