WI #619: SKU Price Details Supporting Content #683
Conversation
|
NOTE: this is a working draft, converted to a PR for easier discussion. |
kk09v
changed the title
| | Category | ProposedKey | Explanation | Concerns | | ||
| | ---- | ---- | ---- | ---- | | ||
| | Size & Shape | SizeVcpu | This is to capture the size in terms of cores / vCPUs per the Pricing Unit of the SKU | Time Normalization | | ||
| | Size & Shape | SizeGib | This is to capture the size in terms of GiB per Pricing Unit; this was intentionally kept generic to allow it to be used for multiple different types of SKUs | Time Normalization, Unit Size, a SKU may have 2 different things that could be measured in GiB (e.g. memory + ephemeral disk) | |
There was a problem hiding this comment.
Doesn't this mean we'd need separate attributes for every unit? Will that scale?
To propose something different, what about a nested object that supports adding all specs in a consistent way?
SkuPriceDetails = {
Size: "Medium",
Specs: [
{ Component: "Processor", Quantity: 8, Units: "Cores" },
{ Component: "Memory", Quantity: 32, Units: "GB" },
{ Component: "Disk Size", Quantity: 128, Units: "GB" },
],
}
This could also be a separate SkuPriceSpecDetails column that is an array of objects. Or we could extract the component and make it an object of objects:
SkuPriceDetails = {
Size: "Medium",
Processor: { Quantity: 8, Units: "Cores" },
Memory: { Quantity: 32, Units: "GB" },
DiskSize: { Quantity: 128, Units: "GB" },
}
This is probably a little simpler all-up. I think I prefer this given how flexible it is. My only concern is usability for non-technical users. Is this something non-technical users need to access? I think we need to know personas per scenario. How would you feel, as a practitioner?
Btw, I know I'm merging different things together here. This is a hypothetical scenario where a SKU has a mix of different components that each have their own overlapping units to convey the flexibility. I don't know if this happens today, but it does feel like it's feasible for managed apps and composite services.
There was a problem hiding this comment.
We will certainly discuss the format and names further, but it does seem practical to have generic placeholders for Size Details (Name, Component/Type, Unit, Quantity).
Of course, not everyone may be able to interpret this, but it seems to me that this column is intended for those who should be able to make sense of it. :)
Also, if we're going in this direction, let's not forget to mention that:
- Unit SHOULD conform to the UnitFormat requirements
- Quantity MUST conform to Numeric Format requirements
- Etc.
On that note, we should probably add a reminder that these 'predefined' keys are quite similar to OPTIONAL FOCUS columns and should therefore be treated in the same way (apart from the description/introductory section, we should also include normative requirements, etc., as we move forward).
There was a problem hiding this comment.
@flanakin your suggestion (both options) would require a change to either the value format of SkuPriceId or the definition of Key-Value Format.
"Values in a key-value pair MUST be one of the following types: number, string, true, false, or null."
Ref
| | Size & Shape | SkuXUnits | This is to capture units specific to a PaaS offering which often conatain a measure of processing power (RUs, PTUs, DBUs, etc.) | X is a placeholder for another word | | ||
|
|
||
|
|
||
| | ID | Type | CSP | Description | SizeVcpu | SizeGib | SizeName | SkuVersionName | SkuXUnits | |
There was a problem hiding this comment.
nit: Description == SkuMeter?
| | ID | Type | CSP | Description | SizeVcpu | SizeGib | SizeName | SkuVersionName | SkuXUnits | | |
| | ID | Type | ProviderName | SkuMeter | SizeVcpu | SizeGib | SizeName | SkuVersionName | SkuXUnits | |
| | ---- | ---- | ---- | ---- | | ||
| | Size & Shape | SizeVcpu | This is to capture the size in terms of cores / vCPUs per the Pricing Unit of the SKU | Time Normalization | | ||
| | Size & Shape | SizeGib | This is to capture the size in terms of GiB per Pricing Unit; this was intentionally kept generic to allow it to be used for multiple different types of SKUs | Time Normalization, Unit Size, a SKU may have 2 different things that could be measured in GiB (e.g. memory + ephemeral disk) | | ||
| | Size & Shape | SizeName | This is to capture the name of the size/shape so that it can be used for aggregation independent of other factors that make up the SKU (e.g. region) | |
There was a problem hiding this comment.
I have a bunch of reports that have a column for size. To support building those reports in Power BI, I will need to extract this into a dedicated column, which means I will start referencing x_SkuSize as a custom column that is extracted from SkuPriceDetails.Size. The same would happen across APIs and databases that practitioners and vendors build when they do care about size. While this is fine, it makes it feel like FOCUS doesn't support my needs because I had to reference a custom column. You could make this argument about anything in here, but this one feels super common. Thoughts?
There was a problem hiding this comment.
I can totally understand your use case, but for me, the "SKU Family" is reported on far more often than the Size. The idea with having all of the data in this semi-structured column is that each consumer can extract and structure the data that's relevant/necessary to them without having a hundred of columns of data that could be sparse, redundant, and/or unneeded.
My proposal is that for the 1.2 release, we should focus on enumerating common properties in the SkuPriceDetails column. Then, we can review the adoption, usage, etc. to evaluate promoting some to dedicated column.s
Merge SizeCoreCount renaming suggestion Co-authored-by: Michael Flanakin <flanakin@users.noreply.github.com>
Aligned column names in example table to FOCUS terminology
shawnalpay
changed the title
No description provided.