Skip to content

Conversation

@jkuester
Copy link
Contributor

@jkuester jkuester commented Dec 19, 2025

Description

This is a little present for @mrjones-plip when he returns from the holidays! 🎄

image

It is a first draft of an interactive Hosting Cost estimation tool (forum thread).

It turns out it is pretty easy to add interactive HTML to your Hugo site via a custom shortcode. And, the modern CSS functionality provide very nice layout and visualization so I did not have to resort to any dependencies.

I am pretty happy with the features/layout/functionality of the whole thing, but the tuning of it could use more eyes.

One simplification that I have started with (but which could be easily refactored) is that I have only factored in the costs of 5 example EC2 instances and I try to pick one of those based on load (users * workflows). This approach has obvious limitations, but it was simple enough to let me get started with real world numbers. Definitely open to suggestions on the best way to improve this.

The other things that need more tuning are the various constant value that are used in down-stream computations:

  DISK_COST_PER_GB: 1,
  CONTACTS_PER_PLACE: 5,
  WORKFLOW_YEARLY_DOCS_PER_CONTACT: 12,
  DOCS_PER_GB: 12000,

DISK_COST_PER_GB is a rounded-up estimate from EBS. CONTACTS_PER_PLACE is roughly the "household size", but it gets used to estimate how many ancestor contacts are in the hierarchy tree (given the user input of the population size). Currently the logic assumes a completely even distribution and density of contacts throughout the tree. WORKFLOW_YEARLY_DOCS_PER_CONTACT is by far the most hand-wavy. Basically I need some way to connect how many workflows are being supported by the instance with an estimate of how many reports will be generated per year. So, in this case 12 means that I think we will have an average of 1 report created per month per workflow per contact. This may be way off. DOCS_PER_GB is a rough estimate that I made based on Watchdog data from a large production instance.

Most of this code was written (or heavily influenced) by Claude, but I have carefully reviewed and edited it for maximum maintainability.

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

…ed breakdown section. Adjust layout for improved readability.
…te instance load ranges and adjust user count limits for consistency.
…r. Update instance load range for c6g.8xlarge.
@jkuester jkuester marked this pull request as ready for review December 19, 2025 22:36
@jkuester
Copy link
Contributor Author

jkuester commented Jan 5, 2026

After thing about this more, I think that besides the basic tuning mentioned above, there are a couple additions needed before going live with this:

  • Document the assumptions being made as well as the sources for the various built-in values that are being used.
    • Should be able to capture this in some bullet points below the calculator
  • Related to the above point, we should capture any useful information regarding obtaining updated versions of the build-in values.

I think both of these will help enforce a useful level of rigor around the cost algorithm (we are not shooting for it to be perfect, but it should be good enough that we can justify the decisions made). Also, it should be reproducible/maintainable to avoid becoming stale in the near future.

@sugat009
Copy link
Member

sugat009 commented Jan 6, 2026

@jkuester I briefly used the calculator and I have a small feedback. Is it possible to have the parameters be number input fields as well as sliders?

Copy link
Contributor

@mrjones-plip mrjones-plip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OMG This is amazing - I love it! Like, I loooooove it! What a great gift to return to after the holidays - you were right!

Overall this is great and we should most definitely ship it! Before we ship it, I have some comments I made as I was playing with it. As with all GUIs, they bring about a opinions, bugs and corner cases. Feel free to push back where ever! Let's work through at least few iterations focusing on one set of feedback at a time. Possibly maybe starting with feedback from Loukman, Simon, Nitin and Derick (Jeff too?) who face the cost question so often in the field. Seems a shame to spend a bunch of time gussying up the GUI and logic only to have a new item added or a key component removed. I'm open about this approach though! As well, we'll need to ground truth the outputs. Happy to chat on this tomorrow/Fri as needed! No code review just yet - that'll come last I think!

First, what's to love about this? So much!

  • It's easy to use - 4 sliders covers 90% of user cases
  • It's intuitive - population, workflows, age and users are accessible concepts. They also prompt healthy discussion about how to plan for a deployment in a mostly non-technical way ("what's a workflow? how do I know how many I need?")
  • Because it can answer such a wide range of questions with all the sliders, it really addresses the ongoing questions of "I still don't know how much the CHT costs to run!!!" - this is a lovely answer!
  • It's just really pretty to look at it 😻
  • Being instant is a real dopamine hit. You instantly see the changes and it's a real joy to use.
  • I'm inspired for v2, v3! Maybe adding some pre-filled examples to get people thinking? Like, "this shows the cost of an East African country in it's 6th year of operation. There were 100k people and 5 workflows. Note how the disk becomes the predominant cost at over 80%" vs something like "This small deployment serving a population of 1k with 100 CHWs has an EC2 cost of almost 99% and is well under $1k/year"
  • From a technical perspective, this is readable code, easy enough to maintain and not megs and megs of some superfluous JS framework - Raw JS FTW! \o/

GUI suggestions:

  • add a reset to advanced parameters. I was playing with it and got way outside of normal parameters and had to hard reload to page to reset them all
  • don't show cents on cost estimates & instance (maybe OK on cost per user?). Round up to the dollar.
  • don't show decimals in GB (Storage Breakdown) or on people per user
  • make sure "Cost Per User" dollar amount is on one line (no break between "$0.46/" and "mo"
  • add darker border color around the 4 boxes when in light mode. maybe #a4a4a4 ?
  • add slightly darker background color behind the the 4 boxes when in light mode. maybe #eee ?
  • mobile layout is a bit wonky. On my phone, the page loads with it slightly zoomed in so the parameters and cost estimates are cropped on the right. Recommended hosts goes way off the screen. when in responsive mode I would make all 4 boxes 100% width and ensure they don't crop or require horizontal scrolling to see
  • if you're trying to set up a small amount of users, say 100, it's pretty much impossible to get there: it jumps from 99 to 134 with no inbetween when using mouse input (I do know you can click the slider and use arrow keys, but lets assume most folks won't do this.) Interestingly my zoom level affected the numbers it jumped between! Suggestion: go in increments of 100 if possible or something more smooth. Age of deployment works really well with a range of 1-10 years in 1 year increments.
  • "Cost Per User" should be shown in $/yr like the rest of the system. We could do a smaller $/mo like we do in the larger "Cost estimate"
  • Given the calculator is likely both 99% of what people want and has disparate data than the current page, make the calculator the default under "Hosting Cost" and move the existing page to something like, "Hosting Cost Case Study".
  • for "Storage Breakdown", spell out "Over-provisioning" in full. Likely if we get rid of decimals on $s, make RAM and CPU on their own line (instead of one line with a +), we'll have room to split the "Recommended Host" box 50/50 instead of the 66/33 (or what ever it is ;)
  • remove "Block Volume Storage" under "Disk" - it's effectively a redundant label even if it's accurate.
  • I'm torn on the inclusion of "Age" as a slider. Is it helpful to know your 100k population, 5k users will cost $3.6k in year one, but $13k in year 10? Likely year 2 and 3 are key to know there's an increase. Maybe break this out into a separate "cost over time" table? Maybe leave as is?!

Calculator logic:

  • When I do 400k population, 4 workflows, 1 year, 200 users, my "People per user" is 2400 out of a scale of 250. Similar issues for "Docs per user". Pretty as they are, I'm not sure a slider visualization works for these two. Maybe it does for the happy path and I'm over thinking it? Clearly 200 users can't service 400k population ;)
  • We should include info about "resource utilization". I was confused how I could be adding 100s of users but my cost was static - it was because resource utilization started at 12% and was working it's way toward 90%
  • I don't think we can sanely allow say...>80% utilization? I was able to get it to >99% which will guarantee a high replication latence - sad times. Suggestion: add an "advanced" setting to flip the recommended host over to the next level up at 75% utilization.
  • Add a total for "Storage Breakdown". I was so confused why Used and Overprov were always the same.
  • Sad as it is, sigh...we need to set "Database Over-provisioning Factor" to a default of 5. Given our upgrades require it, I don't see how we could reasonably suggest any other amount :(
  • not sure what the solution is, but 100k population with 10k users, 5 workflows, at year 10, won't have 0.0% utilization. Feels odd to bake in a fixed 20% minimum. Maybe an advanced setting?! Maybe I shouldn't over complicate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 💻 In Progress

Development

Successfully merging this pull request may close these issues.

3 participants