While there is some truth to what you are saying in your linked post, the real truth is more nuanced and, as usual, lies between any extremes. Firstly, when tal

While there is some truth to what you are saying in your linked post, the real truth is more nuanced and, as usual, lies between any extremes. Firstly, when talking about extreme flexibility and experimentation, you're not talking about MVP in my book, but rather about a prototype. You can experiment with a prototype all you want, but no so much with an MVP, which, be definition, is a product, even if a minimal viable one. Secondly, your argument that MVP-stage early startups don't need HA breaks due to the corollary of MVP being a product. If your early-stage startup has, say, 5-10 important enterprise customers (those whose logos you so desperately need for initial sales as well as further marketing) using your MVP as product or even a pilot, guess how many of them will stay with you after a first 5-hour outage of your platform? Thirdly, in order to prevent disastrous exodus situations like mentioned above, an early startup does not need to have a globally scalable geographically distributed HA system (or, as you put it, "multiple servers, multiple load balancers, multiple failover databases, multiple data centers, multiple regions"). It would be quite enough to have a single level of redundancy for each major single point of failure. For a typical cloud architecture, it just means architecting, deploying and maintaining your system for/to/in two availability zones. This IMO represents a pretty good compromise between costs (both monetary and effort-wise) and risks (reputational, current and future sales, etc.). Fourthly, your suggested preference of VMs to containers will most likely lead to a) lower agility [due to spinning a VM being a much slower process versus spinning a container; that would be especially noticeable across development cycles: CI/CD etc.] and b) overspending on infrastructure [due to overhead stemming from the fact that you simply cannot pack VMs as efficient as containers into a given computational asset]. Fifthly, some/many operational aspects that have to be managed - manually or via automation such as Terraform - in non-HA scenarios could be partially or completely eliminated in cloud-based HA scenarios thanks to those aspects being embedded into relevant PaaS products, hence potentially significant cost savings and, equally or more importantly, time savings, thus, enabling a potentially much higher agility, which is so important to early-stage startups.