4 ms·

It is a careful balance. At my last startup we knew we had scale technical debt in our SW. Not something we could fix by tossing HW at the issue. It was all gre

It is a careful balance. At my last startup we knew we had scale technical debt in our SW. Not something we could fix by tossing HW at the issue. It was all great until we landed that major customer that blew past our supported scale. 6 months of engineering work and a complete stop of feature process. A more careful consideration of the tradeoffs when making them would have saved a huge headache, but no one wanted to look at the issue preferring to ignore it.

mwcampbell 4y ago
> 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?
- gameswithgo 4y ago
- myrandomcomment 4y ago
  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).
  - mwcampbell 4y ago
    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.
gameswithgo 4y ago

mwcampbell 4y ago

> 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?

gameswithgo 4y ago
myrandomcomment 4y ago
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).
- mwcampbell 4y ago
  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.

gameswithgo 4y ago