3 ms·

I understand that a company I work with uses a few, and is migrating away from them. It seems clear to me that prior to robust systems for orchestrating across

I understand that a company I work with uses a few, and is migrating away from them. It seems clear to me that prior to robust systems for orchestrating across multiple servers that you would install a mainframe to handle massive transactional workloads. What I can never seem to wrap my head around is if there are still applications out there in typical business settings where a massive machine like this is still a technical requirement of applications/processes or if it's just because the costs of switching are monumental. I'd love to understand as well!

rbanffy 1y ago
Bank payment processing is the primary example - being able to tell if a specific transaction is or not fraudulent in less than 100 milliseconds - but there are other businesses with similar requirements. Healthcare is one of them, and fraud detection is getting a lot more sophisticated with the on-chip NPUs within the same latency constraints.
zifpanachr23 1y ago
There are really applications that are large enough and hard enough to parallelize and/or shard that any rewrite on a different platform would turn into a performance catastrophe, even if you hired the best engineers and wrote the whole thing in very efficient C++, which you never hear about them doing because its usually only about saving money and so it's done with as cheap of developers as possible and in Java. I've seen it and it's not pretty. They tend to be dog slow and unresponsive, and even harder to maintain than the crusty old assembler and COBOL, because you have to implement a lot of the report writing and record crunching features built into a domain specific language like COBOL from scratch it you want to write the same application in Java. That's my biggest pet peeve with people that want to ditch mainframes, which is that they seem to care very little about the quality and performance of the software in my experience or they would only be thinking of replacing COBOL and Assembler code with an equivalently performant modern language and dialect. The desire to migrate is often driven primarily to have cheap, easily replaceable developers.
philjohn 1y ago
IBM advertise 8 nines of reliability for the z17 (i.e. a second of downtime per year). If you have a workload that cannot go down it's going to be more reliable than orchestrating a bunch of cloud servers where you're dealing with the network, hosts going down, failing, or issues with errors in the CPU (yep ... happens at scale). They also test the hardware to exacting standards - 8.8 magnitude earthquake is one example.

rbanffy 1y ago

Bank payment processing is the primary example - being able to tell if a specific transaction is or not fraudulent in less than 100 milliseconds - but there are other businesses with similar requirements. Healthcare is one of them, and fraud detection is getting a lot more sophisticated with the on-chip NPUs within the same latency constraints.

zifpanachr23 1y ago

There are really applications that are large enough and hard enough to parallelize and/or shard that any rewrite on a different platform would turn into a performance catastrophe, even if you hired the best engineers and wrote the whole thing in very efficient C++, which you never hear about them doing because its usually only about saving money and so it's done with as cheap of developers as possible and in Java. I've seen it and it's not pretty. They tend to be dog slow and unresponsive, and even harder to maintain than the crusty old assembler and COBOL, because you have to implement a lot of the report writing and record crunching features built into a domain specific language like COBOL from scratch it you want to write the same application in Java. That's my biggest pet peeve with people that want to ditch mainframes, which is that they seem to care very little about the quality and performance of the software in my experience or they would only be thinking of replacing COBOL and Assembler code with an equivalently performant modern language and dialect. The desire to migrate is often driven primarily to have cheap, easily replaceable developers.

philjohn 1y ago

IBM advertise 8 nines of reliability for the z17 (i.e. a second of downtime per year). If you have a workload that cannot go down it's going to be more reliable than orchestrating a bunch of cloud servers where you're dealing with the network, hosts going down, failing, or issues with errors in the CPU (yep ... happens at scale). They also test the hardware to exacting standards - 8.8 magnitude earthquake is one example.