3 ms·

There are other good answers to the complexity. An additional aspect not mentioned yet is that your bill is not a single thing. Usage, metering, pricing, and bi

There are other good answers to the complexity. An additional aspect not mentioned yet is that your bill is not a single thing. Usage, metering, pricing, and billing are all discreet problems. Theyre all interdependent and all of them need to be solved to provide a value thats useful to you, the customer. A resource is used, when is the usage metered? If your instance is priced by run time when is that metering durably recorded? End of a time period, a billing period (oops! Havent got to billing periods yet!), on resource state change? Assume you have a bunch of metering records. What price do you apply? There are LOTS of prices, even for the same thing. So now we need to know per account/service/region/contract/whatever the price to apply to the metering data. Oh no! The final price depends on aggregate usage! We cant determine the “price” for any single metering record without knowing cumulative usage. So now we have to aggregate total usage and apply the different marginal prices before we can determine any single price :( Now we have lots of metering data + pricing data, lets make a bill. Who is the bill for? An account, a group of accounts, an organization? I hope you dont support credits, discounts, or similar that cross accounts. In practice the answer is probably “yes” and you e run in to another round of aggregation. This isnt specific to SaaS, but describes billing in general. Its not A hard problem, its Many hard problems. And that general pattern of business problems is why you see most (all?) providers end up at a process that looks like recurrent batch computations. Disclaimer: principal at AWS, but do not work in the metering/billing space directly. None of the above is specific to my employer and solely my personal observations/opinions.

gdfgjhs 4y ago
Wouldn't it would be great if pricing was simpler. I work for a Cloud provider too, and I keep pushing for simpler pricing models. My team/service does actually uses simpler per unit billing with no tiers or region. Discounts/contract rates are applied at account level at but any client could easily predict their actual cost, if we provided them realtime before-discount cost. But other teams seem to replicate AWS pricing models, I assume to stay competitive with it.
- donavanm 4y ago
  Personally I love usage based pricing that’s tied to costs. One thing I’ve noticed, maybe more in the last few years, is that customers don’t actually want this because, when done comprehensively, it leads to an overwhelming number of line items/dimensions. That instance example should really be run time per cpu/ram, and storage volume, and network IO, and maybe even storage IO. Multiply those half dozen dimensions by the 10s of resources used and now they’re going to struggle to parse the bill and tie it together. The other bane is value based pricing that business units and MBAs love. Trying to extract the maximum downstream (economic) value from the customer who’s using the service. I do reckon you’re right though. Providing more timely estimated usage, and maybe even an approximate or base rate, would answer a LOT of these questions.

gdfgjhs 4y ago

Wouldn't it would be great if pricing was simpler. I work for a Cloud provider too, and I keep pushing for simpler pricing models. My team/service does actually uses simpler per unit billing with no tiers or region. Discounts/contract rates are applied at account level at but any client could easily predict their actual cost, if we provided them realtime before-discount cost. But other teams seem to replicate AWS pricing models, I assume to stay competitive with it.

donavanm 4y ago
Personally I love usage based pricing that’s tied to costs. One thing I’ve noticed, maybe more in the last few years, is that customers don’t actually want this because, when done comprehensively, it leads to an overwhelming number of line items/dimensions. That instance example should really be run time per cpu/ram, and storage volume, and network IO, and maybe even storage IO. Multiply those half dozen dimensions by the 10s of resources used and now they’re going to struggle to parse the bill and tie it together. The other bane is value based pricing that business units and MBAs love. Trying to extract the maximum downstream (economic) value from the customer who’s using the service. I do reckon you’re right though. Providing more timely estimated usage, and maybe even an approximate or base rate, would answer a LOT of these questions.