Here is a better model that demonstrates how cloudy databases can provide dramatic performance increases without increasing costs.
Mea culpa… I was going to extend the year-old series of posts on the economics of cloud computing and recognized that I poorly described the simple model I used, and worse, made some mistakes in the model. It was very lame. I’m so sorry… That said, I hope that you will like the extension to the model and the new conclusions.
I’ll get to those conclusions in a few short paragraphs and add a new post to explain the model.
If we imagine a workload consisting of 6 “jobs” that would execute on a dedicated cluster of 24 servers in 3 hours each with no contention, we can build a simple model to determine the price performance of the workload for three different configurations:
- M1: The usual configuration where all six jobs run together and share the configuration, multitasking and contending for the resources. As the configuration scales up the cost goes up, the runtime goes down, and the contention drops.
- M2: A silly model where each job runs serially on the configuration with no contention. As the configuration scales up the costs go up, the runtime goes down.
- M3: A model where each job runs independently, simultaneously, on its own cluster with no contention.
If we pay for servers by the hour the model shows that there is an opportunity to deploy many more servers, as many as one per “job”, to reduce the runtime and the cost. Here are the results:
| Config | Servers Deployed | Actual Runtime / Workload (Hours) | Paid Runtime / Workload (Hours) | Cost / Workload | Price / Performance |
| Multitasking | 24 | 4.5 | 5 | $480 | 444 |
| 48 | 3.8 | 4 | $768 | 533 | |
| 96 | 3.4 | 4 | $1,536 | 593 | |
| Serial Execution | 24 | 18.0 | 18 | $1,728 | 111 |
| 48 | 9.0 | 9 | $1,728 | 222 | |
| 96 | 4.5 | 4.5 | $1,920 | 444 | |
| Dedicated Server per Job | 144 | 0.5 | 1 | $576 | 4000 |
| 288 | 0.3 | 1 | $1,152 | 8000 | |
| 576 | 0.1 | 1 | $2,304 | 16000 |
Note that the price/performance metric is relative across the models. You can see the dramatic performance and price/performance increases using a configuration where each unit of work gets a dedicated set of resources. But the more dramatic picture is exposed in Table 2.
| Configuration | Servers Deployed | Actual Runtime / Workload (Hours) | Paid Runtime / Workload (Hours) | Cost / Workload | Price / Performance |
| Multitasking | 24 | 4.5 | 4.5 | $432 | 444 |
| 48 | 3.8 | 3.8 | $720 | 533 | |
| 96 | 3.4 | 3.4 | $1,296 | 593 | |
| Serial Execution | 24 | 18.0 | 18.0 | $1,728 | 111 |
| 48 | 9.0 | 99.0 | $1,728 | 222 | |
| 96 | 4.5 | 4.5 | $1,728 | 444 | |
| Dedicated Server per Job | 144 | 0.5 | 0.5 | $288 | 4000 |
| 288 | 0.3 | 0.3 | $288 | 8000 | |
| 576 | 0.1 | 0.1 | $288 | 16000 |
Here the granular billing reduces the total cost with the same dramatic price and price/performance increases. This was the point I was trying to make in my earlier posts. Note that this point, that fine-grained billing can be used to significantly reduce costs, is why deploying work in containers, or better still as serverless transactions, is so cost-effective. It is why deploying virtual machines in the cloud misses the real cost savings. In other words, it is why building cloud-native implementations is so important and why cloud-native databases will quickly overcome databases that cannot get there.
I also was trying to show that work deployed across these configurations, what I call a “job”, can be ETL jobs or single queries or a set of queries or a Spark job. If you have lots of smaller work, it may be best to run them in a multitasking configuration to avoid the cost of tearing down and starting up new configurations. But even here there is a point where the tear down cost can be mitigated across multiple semi-dedicated configurations.
