Change all references to "commitment-based discounts" to "commitment discounts"

[flanakin]

Type

Dimension: PricingCategory, CommitmentDiscount*, ChargeSubcategory, and more Normalized: Yes

Description

FinOps Framework is moving in a direction where "commitment-based discount" will be shortened to "commitment discount". Should we change our references to also be the shorter version?

This is only a change to the descriptive content and does not impact anyone implementing the spec. The only thing in the actual columns is where PricingCategory uses a value of "Commitment-Based" for commitment discounts. All commitment discount columns are prefixed with "CommitmentDiscount", which is already aligned to the shortened name. PricingCategory uses "Commitment-Based" as a bit of a conceptual prefix so it can be read as "commitment-based pricing" or "on-demand pricing" or "dynamic pricing".

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.
• [ ] Include principles and governance criteria for maintaining this dimension

🗳️ Vote now!

Please react to this message to cast your initial vote:

🚀 =  Change all references to use commitment discount

👎 =  Do not change. Keep commitment-based discount

👀 =  We should have a conversation before we change this

Click here to vote ↴

[mike-finopsorg]

The current work on the FinOps Framework is still a WIP. However, the current work with the Technical Advisory Council has the capability changing to "Rate Optimization", so I think there is less pressure to change this value here. I am not for or against changing this name, generally I think it's not going to cause any confusion, however, I do see simplification as a benefit.

As you say this will change the value used in the PricingCategory column. We would need to ensure we are positioned ok to change this with the currently adopted cloud service providers. @flanakin you are one :) so sounds like we just need from feedback from @rupagcp.

[udam-f2]

Commitment Discount is confusing (maybe Commitment-based discount is not much better). When many agree to an EDP, they're also making a 'commitment' for an amount of spend for the contract period. How do we differentiate RI/SP type rate optimization discount constructs from other 'commitments' that also result in a rate optimization (e.g. 15% EDP discount)?

[gparker-at-sf]

To @udam-f2 's point about distiguishing from Enterprise level discounts, maybe something like 'Resource (or Resource-level) Commitment Discount'?

[rupagcp]

I don't have major objections

[flanakin]

Commitment Discount is confusing (maybe Commitment-based discount is not much better). When many agree to an EDP, they're also making a 'commitment' for an amount of spend for the contract period. How do we differentiate RI/SP type rate optimization discount constructs from other 'commitments' that also result in a rate optimization (e.g. 15% EDP discount)?

Fwiw, this came up in the TAC and I believe there was some alignment on negotiated discounts are a "commitment-based discount". For these, I wonder if we should refer to them as "pre-purchase commitment discounts". I'm assuming we'd leave the column names as-is tho. If we want to change those, that's a bigger deal [which we would need to prioritize].

[udam-f2]

@flanakin But these aren't pre-purchased always either. AWS has partial upfront and no upfront SPs and RIs. Did the TAC come up with a name for this?

I'm curious if calling the negotiated discounts 'contract commitment discounts' or 'provider commitment discounts' and we can keep the capacity/spend commitment discounts as is OR call them 'service-based commitment discounts'? I know its not always limited to a single service but the name doesn't imply it's just one only.

@rileyjenk @mike-finopsorg

[udam-f2]

To @udam-f2 's point about distiguishing from Enterprise level discounts, maybe something like 'Resource (or Resource-level) Commitment Discount'?

@gparker-at-sf Wouldn't SPs (spend commitment-based discounts) not qualify as resource-level?

[gparker-at-sf]

Resource Commitment Discount could still be appropriate. E.g. AWS SPs are tied to either compute, instance types, or Sagemaker. Ref: https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html

[jpradocueva]

Classified as Discounts by the Maintainers on the May 24 call

[jpradocueva]

The group agreed this issue is not a breaking change on the TF-1 May 28 call.