The analogy seems more clear to me in IT operations. Let’s say we have one server running our stuff, and it’s too slow. One option is, upgrade the CPUs or add

The analogy seems more clear to me in IT operations. Let’s say we have one server running our stuff, and it’s too slow. One option is, upgrade the CPUs or add more RAM. This seems analogous to “build a bigger engine” in your example. There’s no added complexity (well, mostly, maybe you run into NUMA issues or something). But some kinds of upgrades are more costly or complex than they appear on the surface. If we want to add 1 TB of usable storage space, at the physical level that means multiple drives for redundancy, keeping multiple copies of the data for backup, keeping replicated copies of data that are ready to turn on at any moment, and so on. So in the developer’s mind we think “add a single 1 TB drive”, but in reality it might take adding 15-20 drives in numerous servers to accomplish this. The same thing happens when going from a single physical server to multiple. With a single server you can scale vertically. But horizontal scaling is a different type of complexity, now having to think not only about server redundancy, but redundancy at the network layer, now you need redundant network switches, and it all needs to be configured right to handle any part in the communication path failing (server down, server network card down, server network card port down, bad network cable, network switch down, network switch port down), and all of those require some configuration and protocols, and maybe you’re not familiar with VRRP or LACP on the network switches and also how those interact with VMware load balancing and failover, so now you need a VMware person and a Cisco person and that’s not even considering how you handle split brain scenarios where both servers are still running but can’t talk to each other due to a network partition. And that’s all a very different kind of upgrade than slapping more RAM sticks in the server and keep rolling.