FOCUS_Spec
FOCUS_Spec copied to clipboard
FinOps-Open-Cost-and-Usage-Spec
SKU categorization columns
Type
Dimension Normalized: Yes + No
Description
The most fundamental thing we are describing in FOCUS is the SKU. Yet as-is, the only thing we know about the thing we're explicitly being charged for is 2 IDs that need to be looked up in another system. And how those IDs map to the provider's price list is not clear since each provider uses different terms for those attributes. This makes relying on SkuId and SkuPriceId very difficult.
Since SKU attributes are the most common way leaders throughout an organization look at their cloud usage, there needs to be a human-friendly categorization of SKUs. At a bare minimum, we need a
SkuCategorythat is the same asServiceCategory(since there will be a one-to-one mapping in some cases). ASkuSubcategorywould also be helpful, but having a normalized column for this might require a significant effort.Beyond normalized columns, FOCUS needs to allow practitioners to categorize their SKUs. Each of the main providers have a logical way to organize SKUs already so this is mainly about identifying clear names to describe a taxonomy of products. As an example, AWS has
product_groupandproduct_familyin the CUR, GCP has SKU group as a concept outside of the cost data, and Microsoft hasMeterCategoryandMeterSubcategory. In some cases, providers merge multiple concepts into these attributes because there isn't a very well defined structure that can support such a broad catalog of services. Having a predefined structure that is more open would go a long way to making it easier to understand what SKUs are being used across an expansive account, especially when those SKUs span services and need to be measured for things like commitment discounts.There's already a somewhat common taxonomy for product categorization that exists that we could leverage as a starting point. You can find many different websites that discuss product categorization, but as a starting point, see https://catsy.com/log/product-categorization.
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.
- [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.
Want these columns in FOCUS 1.0 GA?
Give it a 👍 below ↴
If you can discuss and help finalize the change, add yourself as an assignee ↗
Comments are welcome and encouraged!
It wasn't for a lack of trying :D
After all the hours that were spent by many smart people over many weeks, my opinion here is there's no fixed/hierarchal structure that any provider product offerings can generically fit into. As such, I propose that we provide the necessary information in SkuDetails and SkuPriceDetails as JSON columns.
I also believe that SkuCategory would bring a lot of value to get a high-level categorization that is provider agnostic, and it's probably possible to get to it, as it was done for ServiceCategory.
A provider-agnostic sub-categorization seems challenging, but provider-specific columns SkuDetails (or SkuType?) would be good enough to answer the need of sub-categorization.
Last, not sure it's related to this issue, but useful to get a more complete picture (should I open another issue?), I believe a SkuSize column would be useful to specific the size of the SKU within its type (when it makes sense, so it would be nullable). This relates to the concept of rightsizing: selecting the right size to optimize the usage.
Taking the example of Virtual Machines:
SkuCategory= Virtual MachinesSkuType= <VM family/series>SkuSize= < Number of VCPUs >
are we thinking of aligning to something like ATUM?? as a mirror of on-prem taxonomy or creating something new? as there is definitely value in disambiguating providers product catalogues to enable a more effective comparison or summarised reporting
We need to make sure that providers are synced up on the categorization assumptions. In particular, there is a discussion that SKUs may be relevant to multiple service categories - CC @rupagcp
Action Items
- [ ] TS2-#315: Maintainers: To determine a suitable task force for Issue #315 and ensure adequate cloud representation in meetings.
Microsoft columns for SKU categorization:
- ServiceFamily / x_SkuServiceFamily
- MeterCategory / x_SkuMeterCategory
- MeterSubcategory / x_SkuMeterSubcategory
One related that isn't exactly SKU categorization would be PublisherType/x_PublisherCategory. For us, this differentiates Marketplace from native services.
The group agreed to assign this action item to this issue:
- [ ] TF2-#315 Zach, Michael, and Rupa will share their columns used to group SKUs
Summary TF-2 call on Oct 16:
#315 SKU Categorization Columns Key Discussion Items: Adding categorization columns for SKUs, similar to how service categorization is handled. Problem Identification: Currently, there is no clear categorization for SKUs, which creates challenges in analyzing costs at different levels. Divergent Views: The group considered whether the issue should combine provider-specific and provider-agnostic categorizations. Final Agreement: Michael will create a work item, focusing on both provider-agnostic and provider-specific SKU categorizations. Action Items: [TF-2-#315] Michael, @flanakin will create the work item.
I believe that before introducing SKU grouping columns with normalized values (e.g., SKU Category), we should first specify a SKU grouping column containing provider-specific values (e.g., SKU Type), mentioned in the issue #313.
I'm not sure if this issue is intended to cover both #313 and #608.
