1. They run complicated infrastructure software, written by third-party developers.
2. And they run their own simple programs on top of them.
So for example you can rent Kubernetes cluster from AWS and run simple HTTP server. If your server crashes, Kubernetes will restart it, so it's resilient. There will be records in some metrics which will light up some alerts and eventually people will know about it and will fix it.
Another example: your simple program does some REST GET query. This query failed for some reason. But that query was intercepted by middleware proxy and that proxy determines that HTTP response was 5xx, so it can retry it. So it retries it few times with properly calibrated duration and eventually gets a response and propagates it back to the simple program. Simple program had no idea about all the stuff happening to make it work, it just threw HTTP query and got a response.
There's a lot of complicated machinery to enable simple programs to be part of resilient architecture. That's a goal, anyway.
You actually need both, the point of the extremely resilient hardware is that it can act as the single source of truth when you need it - including perhaps hosting some web-based transactions that directly affect your single source of truth. (Calling this a "model" for web-based infrastructure in general would be misleading though: a credit card transaction on the web is not your ordinary website! The web is just an implementation technology here.) Everything else can be ephemeral open systems, which is orders-of-magnitude cheaper.
TSYS is super expensive and is dying out. The current generation of banking software is very much shifting to distributed software across commodity data centers.
IBM Z mainframes play a pivotal role in facilitating 87% of global credit card transactions, nearly $8 trillion in annual payments, and 29 billion ATM transactions each year, amounting to nearly $5 billion per day. Rosamilia highlighted the continuous growth in demand for capacity over the past decade, which has seen inventory expand by 3.5 times.
https://thesiliconreview.com/2024/04/ibm-new-mainframe-web-t...
Some stayed at on prem, some pushed code to mainframe VMs in the cloud, some went to OpenShift (mostly on prem from what Ive seen, probably 80-85%).
Eh, they can but even a couple of decades ago there was a shift to open platforms. 90s and early 00s, sure, it was mainframe and exotic x86 species like Stratus machines. But even then the power of “throw a ton of cheaper Unix at it” was winning.
Banks’ central systems maybe, I have less experience there. IBM did also try for a while to ride the Linux virtualisation wave as well, saying “hey, you can run thousands of Linux instances on a single mainframe”, and I did some work porting IBM software to s390 Linux around 2007.
All our production stuff was being deployed on Aix, HP-UX, Solaris and Windows NT/2000 Server.
Likewise most of my university degree used DG/UX and Solaris, when Red-Hat Linux was first deployed on the labs, it was after the DG/UX server died, and I was already on the fourth year of a five year degree.
We did use NT/2K internally but that was because we had some who insisted on using SMB via Windows.
Such fun times. The nix and nix-like OSes were spreading like fire. I never would have thought I'd ever wrangle them for the majority of my career.
Just because things hung around didn't mean that Sun/Solaris/Java were long for this world. Linux/x86 was just too cheap compared to SPARC gear. Even if it wasn't as robust as the Sun gear, it just made too much sense especially if you didn't have any legacy baggage.
But the x86 I was referring to in my comment above, Stratus, was (maybe still is?) an exotic attempt to enter the mainframe-reliability space with windows. IIRC it effectively ran two redundant x86 machines in lockstep, keeping them in sync somehow, so that if hardware on one died the other could continue. I have no idea how big their market was, but I know of at least one acquirer/issuer credit card system that ran on that hardware around 2002-3.