#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
| - Time Normalization: The pricing unit for 1 SKU may be per month and another sku may be per hour, which would make it more difficult to use this field to calculated | ||
| - Unit Size: GB was used to mean either GB and GiB in differnt contexts, prior to ISO 80000-3; there may be some services truly measured in GB (or other Base10 units) which would be difficult to state in GiB (or other Base2 units) | ||
| - Also one services make sense measured at different scales (e.g. L1 cache is measured in KiB versus disks that are measured in GiB or TiB). | ||
| - With regards to SKU sizing / naming, different CSPs think about the problem in different ways. E.g. in Azure, SizeName would be the property of the sku, but in GCP SizeName would be the property of the resource. |
There was a problem hiding this comment.
@kk09v If we add SizeName, would GCP be nonconformant with our rule that all keys/values must be consistent for a single SkuPriceId? Or do they already have separate SkuPriceId values for every unique core count value?
Adding a reference to this requirement:
| - With regards to SKU sizing / naming, different CSPs think about the problem in different ways. E.g. in Azure, SizeName would be the property of the sku, but in GCP SizeName would be the property of the resource. | |
| - With regards to SKU sizing / naming, different CSPs think about the problem in different ways. E.g. in Azure, SizeName would be the property of the sku, but in GCP SizeName would be the property of the resource. | |
| - This is an important distinction because SkuPriceDetails requires that all keys/values be consistent across rows with the same SkuPriceId. |
There was a problem hiding this comment.
The way I have it structured in my example table below, GCP would not include the SizeName as a property of that given SKU, because it isn't a property of the SKU. The way they communicate this today is that it's in the system_labels (somewhat equivalent to AdditionalInfo).
| | 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.
| | 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?
Merge SizeCoreCount renaming suggestion Co-authored-by: Michael Flanakin <[email protected]>
No description provided.