Open marc-perreaut opened 6 months ago
By focusing on capacity metrics like vCPUs, TB, and GB/s, organizations can make informed decisions about scaling resources up or down based on the demands of their applications. This contributes to performance optimization and cost-efficiency.
SkuCapacity/SkuCapacityUnit are definitely important for cross referencing configurations and the cost among the cloud service providers. This will help practitioners or consultants in recommending best suited solution for the project/application.
Happy to provide more context in upcoming meetings.
Would you think of this as a core part of the data set, or as a reference table that sits alongside the main data set for dynamic enrichment?
@ahullah, adding columns SkuCapacity and SkuCapacityUnit to the core data set (detailed spec) makes sense for me as a practitioner. It helps in many scenarios like analyzing on-demand vs commitment to derive scope further.
These two columns alone might not be enough to do the analysis, it require other columns related that identifies charge type alongside quantity billed on-demand vs commitment.
Aren't there scenarios where there would be multiple types of capacity? We've previously talked about adding SkuDetails column that would be JSON and could have whatever SKU-specific attributes are needed.
Aren't there scenarios where there would be multiple types of capacity? We've previously talked about adding SkuDetails column that would be JSON and could have whatever SKU-specific attributes are needed.
Probably, so the SkuCapacity would be the main capacity type. For example, a VM has a capacity in CPU and in memory: the main capacity would be the CPU. One can argue that the main capacity is memory for memory-bound workloads, for example databases. If happens, both CPU and memory would be needed as capacity: new columns SkuCapacity2 and SkuCapacity2Unit could be added, so that both CPU capacity and memory capacity are present in the dataset. Or maybe something smarter?
A SkuDetails JSON column could do the job, if the keys SkuCapacity and SkuCapacityUnit are always present whatever the SKU (as the goal is to have an aggregated, high-level capacity view), but I find it less convenient than dedicated columns from a practitioner perspective, as it implies to decode the JSON.
Consider a hybrid approach would be a smarter approach here to Use separate columns for primary capacity (CPU) and secondary capacity (memory). If both capacities are needed, populate the relevant columns. If only one capacity is relevant (e.g., memory-bound workload), leave the other column empty. This way, we can maintain clarity while accommodating different scenarios
Description
Proposed approach
Github issue or Reference
Context