The successor IBM Mainframes are still alive... for the time being.
replies(2):
they also moved on three more CPU generations since that redbook, to z17.
I think it's Linux on Z that makes it sexy and keeps it young, in addition to a number of crazy features, like a hypervisor that can share CPUs between tenants, and a hardware that support live migration of running processes between sites (via fibre optic interconnect) and the option to hot swap any parts on a running machine.
It's doing a number of things in hardware and hypervisor that need lots of brain power to emulate on commodity hardware.
_and_ it's designed for throughput, from grounds up.
Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
They feel fantastic when running Linux, but, if you don't need all the reliability features that come with the platform, commodity hardware might be a better choice for the kind of workload that has evolved on Linux.
> Depending on your workload there may be very good economical reasons to consider a mainframe instead of a number of rack-frames.
Absolutely - it makes a lot of the administrative toil disappear. I know clusters are sexy, but getting the job done is always better.
But most people don’t want to deal with the hassle of dealing with IBM.
In this case they will just use a mainframe, even it isn't cheaper in the long run.
For legacy companies yes but it would be very hard for new YC companies or existing non-mainframe companies to create a spreadsheet showing how buying a new IBM Z mainframe would cost less than the latest commodity x86 or ARM servers in the cloud or on-premise.
The IBM pricing for mainframes makes sense for legacy companies like banks and airlines with a million lines of old COBOL code that want to keep it all running with the latest chip technology. (The mainframes from a few years ago are coming off the lease and they need to upgrade to whatever new mainframe IBM is offering and sign another lease & service contract.) So, IBM mainframe prices are very expensive -- but legacy companies will pay it because migrating the code away from mainframes can be even more expensive.
It's similar to expensive enterprise pricing of Oracle, Embarcadero Delphi, Broadcom etc that takes advantage of existing customers already locked into their products. Virtually no new tech startup with a greenfield project is going to pay Delphi $1599-per-seat for each of their developers. Only existing customers stuck with their investment in Delphi code are going to pay that. (https://www.embarcadero.com/app-development-tools-store/delp...)
But some companies do endure the costs of migration to get out from IBM lock-in. There are lots of case studies of companies shifting their workload from mainframes to AWS/GCP/Azure. I can't think of a notable company that did the reverse. Even a mainframe hardware vendor like Fujitsu quit making mainframes and shifted to x86 running an emulation of their mainframe os.
Yes, IBM mainframe can run other workloads besides COBOL like Java and C/C++ but no company that's not already using mainframes would buy & deploy to IBM's Z hardware for that purpose.
It depends. As we have seen the other day, HPE has a machine with more than 1024 logical cores, and they have machines available to order that can grow up to 16 sockets and 960 cores on a single image of up to 32TB of RAM. Their Superdome Flex goes up to 896 cores and 48TB of RAM.
I believe IBM's POWER line also has machines with more memory and more processing power, but, of course, that's not the whole story with mainframes. You count CPUs that run application code, but there are loads of other computers in there doing a lot of heavy-lifting so that the CPUs can keep running application code at 100% capacity with zero performance impact.
> It's the easiest, most reliable way to scale a classical transactional workload.
And that's where they really excel. Nobody is going to buy a z17 to do weather models or AI training.
Which is the Mainframe vs commodity server dichotomy.
This may be true, but because there's basically no on ramp to running on a mainframe, there's no way anybody is going to try it unless they're already on a mainframe. Or maybe unless they really need something that only a mainframe can provide. But most companies can live with some downtime, and once you can live with some downtime, you have options for migration between sites, and options for migrating loads so you can swap parts on a stopped machine. Splurging on network infrastructure with multi-chasis redundancy is an easier step to take to get to a more reliable system than building against a totally different system architecture.
When I was growing up (decades ago, mind), my dad kept trying to convince me to get into machining. Lathes, mills, tool and die making, etc. In his line of work, he saw lots of machining companies basically paying all education and training expenses for new hires because their experienced old timers were retiring faster than they could be replaced. (He also thought computers were a fad...) I'm sure it was a good opportunity at the time. But nearly all of those companies eventually closed up because offshore manual labor was and still is way cheaper. If I'd had taken his advice, I'm pretty sure I would have had to reboot into another career at least once by this point.
You can get a partition of IBM Z to run in the cloud. The cost is about $5/hr for the smallest configuration.
> Splurging on network infrastructure with multi-chasis redundancy is an easier step to take to get to a more reliable system than building against a totally different system architecture.
Yes and no. If you truly need that redundancy than the mainframe is going to provide a much better version of it. SYSPLEXs and LPARs are some insanely powerful technologies.
I agree with this, and all your other reasons why mainframes will remain legacy platforms.
But man, how crazy is it that an industry that is 100% productivity driven and (until AI data centers, at least) labor-cost-constrained would snub its nose at paying a fraction of a percent of those developers’ salaries to put good tools in their hands.
mainframe pricing usually is not by pound of iron but per cpu cycle. unless you say nah I'm buying the thing, not just cycles. soyou have a choice of cloud pricing or hardware pricing.
for significant pure Linux workloads that need an own on premise cloud the TCO pricing is surprisingly competitive with any home grown solution.
even if you don't _need_ an own on premise cloud, AWS and similar donate come for free and there may be a break even there, too.
that said, legacy host software, Delphi, cics, Oracle, DB/2, cobol etc, you named it, yes that's a different story, with all the extra software licensing.
but a pure Linux mainframe is surprisingly competitive not just in compute and throughput but also in pricing.
plus you get quite some high availability in silicon. think ECC on the ALU, hot stand by spare CPU, multipath everything, if your business depends on uptime your system architecture becomes much simpler on highly dependable hardware.
so that spreadsheet compares own people and software construction vs IBM tax in some columns.
lol I start sounding like an IBM sales person https://www.ibm.com/products/integrated-facility-for-linux
I just did Linux on Z for a while and I loved it, so please bear my enthusiasm :-D
It's not competitive when you consider what long-time IBM mainframe customers actually do. E.g. SABRE airline and travel reservation system was one of the first IBM mainframe customers in 1960 with the IBM 7090 and then upgraded to System 360 and then the newer Z mainframes. SABRE's multi-decade experience with IBM mainframes with mission-critical business applications means they are one of the world's foremost experts on its capabilities & costs that's not biased by any IBM marketing or sales pitches.
Even with all that in-house experience, SABRE still chose to gradually migrate off of IBM mainframes to less expensive tech stacks. Some have touted IBM's TPF (Transaction Processing Facility) on the mainframe as compelling technology but that still didn't dissuade SABRE in ~2001 when they migrated the airfare pricing application to Tandem (Compaq/HP) NonStop servers running UNIX. (https://www.computerworld.com/article/1339621/has-mainframe-...)
They then started a 10+ year effort to migrate more mainframe workloads to Google Cloud. E.g. from https://www.sabre.com/insights/a-journey-to-tackle-legacy-co... :
> We moved 93% of compute capacity from physical data centers to the public cloud, resulting in a 50% decrease in our compute costs.
> We migrated more than 120 million bookings from a mainframe-based system to one using Google Cloud’s Spanner database, without impacting customer operations.
JP Morgan Bank is another example of migrating from IBM mainframes to cloud. If anyone out there truly thinks that running a new greenfield Linux workload will be be cheaper or even cost-competitive on a new IBM Z mainframe, just pause and consider if you truly know something about IBM mainframes' OpEx that multi-decade IBM customers like SABRE and JP Morgan don't already know.
Why would any new customers in 2025 willingly buy into IBM Z mainframes if they see existing customers spending billions trying trying to move off of them?
Nearly every installation site and their internal support director agrees that the z/OS installations are far less expensive to support, simply because the minimum level of experience for a z/OS engineer is about a magnitude more than a cloud engineer.
you don't have racks with blades but one box or two, that you upgrade every few years and other than that your hardware side is covered.
rewiring networks, reattaching storage etc all remotely, CLI, and most importantly you only pay what you use.
you need one guy or a consultancy for the initial etc up and for fancy Config changes but once it's essentially set up you simply have a large Linux data centre and do Linux stuff.
oh and you can hot plug additional physical CPUs into a running VM and pull it out and reassign when it's not needed, likewise RAM. that's somewhat difficult with commodity hardware.
and there _are_ companies that value this and choose Linux on Z as a pure Linux deployment.
but you have a point. if nobody in the building knows this, nobody's gonna call IBM and ask for a quote. it's simply not on anybody's radar.