The question of how much would it cost to run CHT comes up fairly regularly and the hosting cost estimation documentation could be improved by being structured as a calculator over time because project context likely changes as discoveries are made and new goals set.
What I’m seeing could be most helpful would be a dynamic page where the input would be initial user count and expected growth rate. Resources required over time for optimal operation would be forecast & displayed on a 2 axis graph together with associated costing for major cloud service providers. The user can experiment with different deployment scenarios for more realistic planning.
Please share thoughts on how total cost of ownership documentation can be enhanced.
I like this line of thinking! Hosting costs will always be something of a moving target as costs and the demands of the system will not remain constant. This probably just makes it even more essential that folks have a way to calculate estimated costs with the greatest possible accuracy.
One idea that I think would be an incremental improvement over the current docs page you have linked would be just a template Google Sheet that could operationalize the calculations from the docs. The idea would be that anyone could make a copy of the sheet and plug in the estimated numbers for their deployment. Then the sheet could show not only the current cost estimates, but could also be sophisticated enough to allow extrapolating to future costs based on some parameters…
Yes - seconding Josh’s interest in the topic - thanks for raising it Elijah! And for sure it can be a moving target. A big challenge that we’ve faced when trying to offer dynamic calculators is not only what’s included and what’s not, but even the costs differences between a bare-metal installation and a cloud installation.
To that end, maybe you can help us out here with some practical use cases? For example, would it be helpful to have a more detailed/interactive calculator based on current Amazon Elastic Kubernetes Service (AWS EKS) and Amazon Elastic Compute Cloud (AWS EC2) pricing? While helpful for planing an AWS cloud deployment, this likely would not be applicable to a bare-metal installs which would require hundreds and likely tens of thousands of dollars ($USD) of hardware capitol purchased upfront. “Upfront Purchase of Hardware” is very much excluded today!
A more simple solution might be the “T-Shirt sizes” approach, where we add two more “medium” and “large” pricing tables to the existing “small” size already published. Maybe this is more impactful in the immediate term?
@elijah I would appreciate any feedback you have on this Docs PR I am cooking up:
Like I note in the PR description, the parameters/algorithms need more tuning so any thoughts you have there are most welcome as well as ideas on any key metrics that I may have missed.
First, thank you, this is a much requested and valuable feature! The idea of having a dynamic hosting cost calculator for CHT deployments would be extremely helpful.
I’m curious: when building the hosting cost estimation or total cost of ownership guidance, are actual production metricsfrom Watchdogsuch as CPU, RAM, and disk usage, taken into account? Or is the guidance based purely on model assumptions and projected user/device counts?
It would be great to know whether live operational data is being leveraged to make these forecasts more accurate, and if not, whether integrating it is being considered
I think the short answer is, yes. Even this first iteration of the calculator is based on data collected from production instances.
However, it is important to note that the current algorithm is extremely primitive (mostly for the sake of starting simple and then layering on complexity as necessary). For example, the server costs are being scoped to 1 out of 5 different EC2 instance configurations. The actual production costs for that EC2 instance are included, but there are many other EC2 configurations that could be used instead.
I think it should be pretty feasible to get accurate numbers for things like hosting cost per CPU/RAM/Disk as well as for things like docs-per-GB of disk space. However, precision is going to be harder for things like projecting the doc growth rate. Currently I am approximating a number based on the number of workflows implemented and the number of contacts in the instance. But perhaps there is a better way?
So, yeah, the main goal here is to leverage the data we have about productions instances into the most accurate estimation of the TCO for instances with various properties. But, some level of abstraction, approximation is always going to be required. My hope is that we can continue to evaluate and refine the algorithm and “test” it against known production instances to gain confidence in the accuracy of the estimation.
@jkuester - I just spent a BUNCH of time playing with this and it’s just amazing - thank you! To try and increase the community awareness and spread my excitement, I made a short video clip of how it’s working in you first generation. While the numbers may not be correct, I hope seeing it live in action will solicit more questions and discussion!
Scope creep is the challenging aspect, not the math. The best course of action for estimating hosting costs is to map actual production metrics (cpu, RAM, and disk) to a limited, subjective range of AWS EC2 sizes. The calculator becomes useless once you attempt to cover every potential configuration.
Although document growth will always be ambiguous, it is acceptable to tie it to contacts and workflows as a starting point. Simply state that it is an estimate and not a guarantee.
I would completely exclude bare-metal from the dynamic calculator. distinct economics and audiences. A dynamic AWS calculator combined with a basic t-shirt sizing chart for bare metal is much more understandable and useful.
