4 ms·

This is especially true for scaling. A solution that works great for your current deployment may be completely unworkable for 2x your current deployment. You j

This is especially true for scaling. A solution that works great for your current deployment may be completely unworkable for 2x your current deployment. You just won't know until you fall off the cliff. The armchair quarterback can opine that you should have just hired experts in XYZ domains from the start to design robust systems that can scale to arbitrary sizes, but most orgs don't need to scale to arbitrary sizes so this is highly likely to be wasted effort.

otterley 4y ago
While I largely agree with you, this isn’t one of those cases. If Fly wasn’t supposed to scale in due course to this size, it probably wouldn’t have been funded. If your business model is predicated on you scaling, yes, you should hire appropriately in anticipation of that. Besides, I’m not even necessarily talking about hiring here - even consulting would have been sufficient to avoid this catastrophe.
- mixmastamyk 4y ago
  Yes, although it's rarely possible to know which bottlenecks will hurt the most up front. Unless you've done the same thing before, which is not the case with anyone pushing boundaries. Basically this is an argument around so-called premature optimization. Good to have issues now while it is mostly enthusiasts that are the customers. Guessing that this bump will be forgotten in five years? And not like AWS et al don't have outages occasionally that they learn from.
  - otterley 4y ago
    Consul has been around for close to 9 years now, and people have in fact tried to use Consul in the very same way Fly did, in many different business and industries, with similarly failing outcomes. Hashicorp knows this and almost certainly would have counseled against it if asked.
    - mixmastamyk 4y ago
      Insert Donald Rumsfeld quote about un/known un/knowns.