I don't quite understand what they're used for. Who buys these things and what are they doing with them that can't be done with other cheaper alternatives now? The article says they're over $100k.
Ah, so is it something like $HugeHealthCareCompany can't send this kind of data to AWS or something because of HIPPA or whatever? Along those lines, I'd bet banks and finance places can't ship anything outside either. Makes more sense now :-)
I'd bet the problem is maintenance scaling. TCO of IBM mainframe + support + staff vs lots and lots of servers + staff + hardware staff (+ probably porting some legacy mainframe code to something distributed).
If you're looking at a clean room build, it might not make sense often. But if you're starting with certain situations that accumulated over decades, maybe?
I know a lot of the people I work with are gradually porting stuff off mainframe onto more modern hardware stacks, but Rome wasn't built in a day, etc etc.
"The company's CEO said the total cost of ownership of the new mainframes is about 50% lower than that of the company's sprawling server farm."
"However, mission-critical workloads that typically run on mainframes aren't a good match for public clouds, because mainframes are far more reliable. Public clouds such as Amazon's Amazon Web Services sometimes undergo unscheduled outages, and often the system must be rebooted in order to apply security patches or upgrades. For companies that require 100% uptime, public clouds simply aren't feasible."
What commodity servers have Channel I/O with sustained 90+% utilization without virtual machines? And which support virtualization using software that passed pentesting with source? And which have 30+ years uptime at high volume sites?
Really, because I'd love to buy them. I'd have believed you if you said VMS clusters or NonStop systems. They're not x86 either, though, although a VMS port is underway.
The mainframe shops I have worked in liked to talk about the continuous uptime of the mainframe, but it was always phrased in "unplanned outages". They still IPLed (Initial Process Load - aka rebooted) the mainframe every Sunday night, to apply maintenance patches to z/OS or perform other maintenance, which would take down all the applications. So, while the mainframe was technically up, I wouldn't call it continuous uptime, since the apps were all down. Just my observations, maybe better run mainframe orgs could work around that.
Mainframes are very impressive beasts. The shops I know that use them needed them to do "big data" before such a term existed. They were the only game in town in the 80s and 90s to perform operations on massive quantities of data, and run massively parallel operations. Most people worry and generate alerts when their CPU goes over 80 or 90% utilization, but on the mainframe running at 100% utilization is the ideal scenario to maximize your investment.
Once you're on the mainframe though, it's a very long and difficult process to get off. And usually there is little to no business incentive to do so. Want to embark on a 18 month 7-8 figure project to migrate off the mainframe, or spend that money to build X feature our customers have been demanding? Tough sell for the CIO..
Interesting perspective and examples. Yeah, Im sure some get planned downtime. Ours never has that I've seen. We are a 24/7 business too. They might have Sysplex or something, though, to take one node down with system still running.
Frankly, these questions sound like a red herring. Or rather, they seem to imply that the actual question to ask is "on what other hardware can we efficiently run mainframe software?". And not, for example, how to evolve software architectures in a way that will allow them to run on contemporary and/or future hardware.
He said mainframes were equivalent to x86 servers in capabilities. So, I started asking if they've achieved a few mainframe capabilities businesses depended on since the 1970's. Also, I already knew the answers ahead of time. Questions were more for parent to see why x86 servers != mainframes.
Basically, highly transactional workloads that have severe performance and reliability requirements. If you're serving a web app, maybe you can spin up a bunch of instances on AWS because while performance and security are important, they're not that important. And by "not that important", I mean not important enough to spend hundreds of thousands of dollars on. To a large consumer bank, it is that important. You also may be able to get away with having an eventual consistency model because it's okay if two different users see two different views of your app. But that's not okay for a bank processing credit card transactions, so they are forced to deal with highly transactional workloads which are now consistent.
I had the same questions as you did, but after talking to some of the z systems folks, I think it may be the case that mainframes, or things that look like mainframes, will always be around. Consider that basically the entire consumer banking and insurance industries still use mainframes. It's possible to consider that an artifact of legacy, but it's also possible evidence that their use-case doesn't fit well with the alternatives (clusters of smaller systems).
Disclaimer: I work for IBM Research, but not in this area.
> Consider that basically the entire consumer banking and insurance industries still use mainframes. It's possible to consider that an artifact of legacy
Legacy is certainly a large chunk of it. The vast majority of Fortune 500 companies have been using IBM mainframes since the 1960s or 1970s, and some were IBM "shops" before computers were invented.
The cost of moving software and data from a proprietary IBM stack would be enormous, even if you could guarantee that it would work. However, the failure rate and cost overruns that appear to be endemic to very large systems development (including IBMs) make moving a risky proposition.
The average CEO is focused on quarterly numbers and is unlikely to stay around for very long. If IBM mainframes were in place decades before the CEO arrived, and will likely be around for at least a decade to come, why take the risk?
> I think it may be the case that mainframes, or things that look like mainframes, will always be around.
It's also easy to imagine a future where compute workloads begin to dramatically trail behind compute power and space requirements. Then, you've got one of these Z13 mainframes the size of an Apple power adapter plugged into the wall of every home.
Maybe we wouldn't even need cloud providers anymore.
My father's entire career revolved around IBM's TPF mainframe systems. Airline Reservation Systems, Credit Card Processing, and the IRS use it for extremely high volume processing.
What shocks me is that they still lack highly assured endpoints despite IBM's prior work in that area through Karger. The chips were already fabbed. They could cram a bunch in there alongside computd and I/O processors. Run legacy with ttusted code in secure envirinment.
Instead, more features still with same breakable model.
21 comments
[ 3.0 ms ] story [ 62.4 ms ] thread100k gets you lots and lots of servers with crypto hardware.
If you're looking at a clean room build, it might not make sense often. But if you're starting with certain situations that accumulated over decades, maybe?
I know a lot of the people I work with are gradually porting stuff off mainframe onto more modern hardware stacks, but Rome wasn't built in a day, etc etc.
"The company's CEO said the total cost of ownership of the new mainframes is about 50% lower than that of the company's sprawling server farm."
"However, mission-critical workloads that typically run on mainframes aren't a good match for public clouds, because mainframes are far more reliable. Public clouds such as Amazon's Amazon Web Services sometimes undergo unscheduled outages, and often the system must be rebooted in order to apply security patches or upgrades. For companies that require 100% uptime, public clouds simply aren't feasible."
https://aws.amazon.com/compliance/hipaa-compliance/
Really, because I'd love to buy them. I'd have believed you if you said VMS clusters or NonStop systems. They're not x86 either, though, although a VMS port is underway.
Mainframes are very impressive beasts. The shops I know that use them needed them to do "big data" before such a term existed. They were the only game in town in the 80s and 90s to perform operations on massive quantities of data, and run massively parallel operations. Most people worry and generate alerts when their CPU goes over 80 or 90% utilization, but on the mainframe running at 100% utilization is the ideal scenario to maximize your investment.
Once you're on the mainframe though, it's a very long and difficult process to get off. And usually there is little to no business incentive to do so. Want to embark on a 18 month 7-8 figure project to migrate off the mainframe, or spend that money to build X feature our customers have been demanding? Tough sell for the CIO..
Basically, highly transactional workloads that have severe performance and reliability requirements. If you're serving a web app, maybe you can spin up a bunch of instances on AWS because while performance and security are important, they're not that important. And by "not that important", I mean not important enough to spend hundreds of thousands of dollars on. To a large consumer bank, it is that important. You also may be able to get away with having an eventual consistency model because it's okay if two different users see two different views of your app. But that's not okay for a bank processing credit card transactions, so they are forced to deal with highly transactional workloads which are now consistent.
I had the same questions as you did, but after talking to some of the z systems folks, I think it may be the case that mainframes, or things that look like mainframes, will always be around. Consider that basically the entire consumer banking and insurance industries still use mainframes. It's possible to consider that an artifact of legacy, but it's also possible evidence that their use-case doesn't fit well with the alternatives (clusters of smaller systems).
Disclaimer: I work for IBM Research, but not in this area.
Legacy is certainly a large chunk of it. The vast majority of Fortune 500 companies have been using IBM mainframes since the 1960s or 1970s, and some were IBM "shops" before computers were invented.
The cost of moving software and data from a proprietary IBM stack would be enormous, even if you could guarantee that it would work. However, the failure rate and cost overruns that appear to be endemic to very large systems development (including IBMs) make moving a risky proposition.
The average CEO is focused on quarterly numbers and is unlikely to stay around for very long. If IBM mainframes were in place decades before the CEO arrived, and will likely be around for at least a decade to come, why take the risk?
It's also easy to imagine a future where compute workloads begin to dramatically trail behind compute power and space requirements. Then, you've got one of these Z13 mainframes the size of an Apple power adapter plugged into the wall of every home.
Maybe we wouldn't even need cloud providers anymore.
https://news.ycombinator.com/item?id=4446880
My father's entire career revolved around IBM's TPF mainframe systems. Airline Reservation Systems, Credit Card Processing, and the IRS use it for extremely high volume processing.
There is a lot of legacy COBOL and FORTRAN programs out there still in use that need legacy mainframes to run the code.
Instead, more features still with same breakable model.
Back in the good old days, here's what an IBM mainframe front panel looked like! https://upload.wikimedia.org/wikipedia/commons/9/9e/360-91-p...
It was really fun to watch the lights blink, even if you didn't know what their significance was.