It is possible to move that complexity into the platform and outside the applications themselves. When I build a web application I don't need to do anything special about failovers, as long as I remember the local filesystem and state is fungible and it only is persisted when I persist it someplace else (that also employs the same safeguards).

I liked to use Google's App Engine classic environment (the Python 2.7 one) as a good example. It really hammered down some good practices (such as keeping the filesystem read-only) and gracefully handling degraded modes such as a datastore that becomes read-only for no reason or the cache that's supposed to be there that just isn't. It was a great teaching tool.

In a way, yes, swapping out entire computers are how one is expected to work with x86 machines. Ask anybody running a critical state full workload(Relational database with lots of writes for example) and they will tell you how nice it is to have a system so reliable to run their writes onto.

Running a Postgres cluster or a Kafka cluster on a bunch of x86 machines sure gives you scale, but definitely brings the pain of handling availability scenarios for write consistency. Distributed locks and distributed data stores that use Raft/Paxos serve as a good reminder of how hard it is to achieve them. If IBM could do it at hardware level, some Enterprise customers are willing to loosen their rich wallets for that comfort.