| In theory, all IaaS services could be built like an Ethereum node: 1. fill an account with abstract "multi-resource usage credits" (or gas); 2. have each API call specify how many credits the caller is willing to spend from their account on the operation (a gas limit); 3. operations in progress are tracked using real-time resource accounting (= distributed tracing, but cheap-as-possible at the expense of granularity); 4. any operation that goes over-budget is cancelled (even if it completed successfully, the user doesn't get the benefit of that completion), with the user being charged exactly the limit they specified. (Yes, that means that the IaaS eats the overhead costs of any additional processing they did before noticing and stopping the workload going beyond its limit. This incentivizes the IaaS to optimize their scheduling, at all levels of the stack, to minimize the amount of "overhang" work it allows.) And yes, to be clear, this would "infect" every layer of every service. If the IaaS provided a DBaaS, the DB's query planning and execution layers would need to know about these limits and accounting mechanisms. Etc. I'm not saying it's practical. But it's definitely possible, with no foreknowledge of cost. |