> Not something we could fix by tossing HW at the issue.

I'm curious to learn why, if there's any more you can share. What about vertical scaling, i.e. bigger machines instead of more of them? Can't that go pretty far?

Shipping unit was a VM to a customer. Tossing more CPU & RAM at the VM would hit general issues of how VMware allocates CPU to a guest. Within the VM we had containers for each sub-unit of the tool. For some part of the system we made the deployment model more than one VM, distributing more containers to the other VMs. However for a key part of the design there was an in-memory DB and we just it the scale limits of the number of elements that could be handled that way without a rethink of how and what we stored.

For everyone that will say "well why..."

1. real products need a generally available shipping unit (SKU) when your customers are enterprise / telco types.

2. for item 1, what is the lowest common thing this type of customer would take - a VM they can run on their existing virtualization setups. the reality of K8s, containers in this type of customers at that point was near zero.

3. there was thoughts about a SKU of a HW appliance, ie, beefy server and just toss CPU/RAM in it and ship that. shipping some stupid HW appliance that we controlled would just be a distraction and a waste of money also requiring 2 shipping artifacts, 2 test setups, etc. not to mention the need to sort for support for HW failure (you can contract with Dell for example to have them label their Kit as your appliance).

Shipping a VM makes a lot of sense. I wish there were better off-the-shelf tools for packaging up a web application into an easy-to-deploy, self-managing VM, without trying to stuff the typical cloud complexity (e.g. Kubernetes) into a box.

I don't understand the issues with using a bigger VM, but I have no reason to doubt you.