Moving to mainframe can be cheaper than sticking with VMware: Gartner

VMware users considering a new home might find it cheaper to move to an IBM mainframe than adopting Broadcom’s new licenses, according to Gartner Vice President Analyst Alessandro Galimberti. Speaking to The Register to discuss the analyst firm’s mid-April publication, “The State of the IBM Mainframe in 2026,” Galimberti said …

[Bebu sa Ware]

Choosing between IBM mainframe v Broadcom VMware

you know you are going to be screwed. The only consolation is that now you get to choose between torx and phillips head.

[Anonymous Coward]

Re: Choosing between IBM mainframe v Broadcom VMware

Fnar, Fnar

[Anonymous Coward]

Re: Choosing between IBM mainframe v Broadcom VMware

That's a big choice. Probably needs a few inter-departmental meetings and an external consultant's report.

[thedarkstar]

Re: Choosing between IBM mainframe v Broadcom VMware

Where is the BOFH when you need him to handle that consultant...

[AMBxx]

Good lunch?

The analyst must have been treated to a great lunch, a round of golf and a tickets to something nice.

[Cliffwilliams44]

Re: Good lunch?

And paid for companionship!

It's Garner, so you know the payoff was a real!

[ICL1900-G3]

Don't knock mainframes

If you can fully utilise one, they make a lot of sense. Ultra reliable, great throughput and scalable.

[I Am Spartacus]

Re: Don't knock mainframes

Totally agree.

Apart from the financial arguement, there is also the fact that a lot of what VM suppliers have in a "roll-your-own-kit" format for HA, DR, Share Disk, inter-machine memory are jist part of the hardware on a Z-Class machine. There are too many so-call IT Manager who just get to the "Mainframes are old-hat and expensive" and are unable to see beyond this. I walked away from one CIO who thought like this and would not listen to anything.

[Anonymous Coward]

Many boxes have always been more necessity than goal

The reasons for using many boxes have always boiled down to a combination of fault tolerance, system load, and cost. It's a necessity, not a goal.

Admins would rather deal with fewer physical systems. Developers have an easier job when they can deal with only one logical system.

If virtualization license costs or cloud fees get too high, that eliminates one of the major reasons for running applications on Linux on commodity hardware.

[Anonymous Coward]

Re: Many boxes have always been more necessity than goal

Well, one of read the part between the lines out loud...

Yes, that was the whole point of the article.

[Cliffwilliams44]

Re: Many boxes have always been more necessity than goal

Cloud costs get out of hand because of a lack of control. Dev teams are allowed to spin up resources without approval. No one is watching the bill until feces hits the fan.

It's no different than uncontrolled OpEx in any other department. It's just that IT doesn't have the experience to control OpEx costs. It's a new skill that needs to be learned!

[Expect Great Things]

Re: Many boxes have always been more necessity than goal

Fascinating theory. Not sure what all the IT outsourcing back in the Noughties was, then.

[x-IBMer]

Virtualization host

More than a decade ago we were clearly able to demonstrate that massive farms of virtualised Linux instances were staggeringly more cost effective on a single zSeries mainframe than being virtualised under x86. License cost changes since then only improve this position for the mainframe. However, even in customers who already had deployed Linux under zSeries and could measure the cost savings we failed to get traction for application workloads to either move to mainframe Linux or be developed with it in mind. Customers use the different hardware architectures for different purposes and mainframe was not seen as appropriate for anything other than the most critical systems of record with high transactional throughput requirements. Many applications just don’t get the benefits offered by big iron despite any potential cost benefits and developers, system architects and designers stick with what they know. To the current generation of Enterprise Architects the mainframe is the Past, and like the Past, it’s a foreign land…

[Ken G]

Re: Virtualization host

The reasons for moving from the mainframe are not about the technology or value, they're about support and skills. VMWare has spent the last 20 years building their own mainframe and Broadcom are trying to monetise that but it's still 30 years behind System Z in refinement. If you're going to move from VMWare though, realistically you're not going to buy Z, you're going to go open source. That has a much smoother on ramp for recently graduated IT students.

[Doctor Syntax]

Re: Virtualization host

Surely the argument in TFA is that you can have both: Z H/W and Linux instances running on it. Unless you are dealing with an application vendor who only supplies Intel compiled binaries - but in that case you're not open source.

[PickteamDT]

We've come full circle.

[spuck]

> We've come full circle.

again.

[Z P]

plus ça change

[FIA]

I.T. is full of them:

Dumb terminals in various guises come round every so often.....

Remote procedure calls with the current technology of the day are another one....

I think there's maybe an argument that 'Vibe Coding' is the latest iteration of the 5GL type languages.. (if you could just describe what you wanted we wouldn't need programmers...)

[handle handle]

>> If you could just describe what you wanted we wouldn't need programmers...

... and there is the problem in a nutshell. Too many are unable to clearly see their problem and cannot logically describe the steps which must be taken to fix said problem.

[FIA]

Yeah, the skill of the programmer is not writing code, it's knowing what code to write.

This is often lost.

[Slant Four]

I am just some rando on the web but...

I used to be a senior IBM Global Tech Lead for database migrations...for 15 years until 2020 when I retired.

I had done numerous projects taking databases from a mainframe to Unix/Linux (not always IBM hardware) and did one migration project to a mainframe: Oracle Solaris to LInux on a mainframe around 2018.

This was for a major airline and we had 300 databases to move (dev and prod).

Long story short...after we got maybe 50 prod databases in, the mainframe performance went off a cliff (basically unresponsive) and we then used the remaining project budget to do a reverse migration back to Solaris. I was told that via the emulation, memory access speeds took a dive once we hit some threshold. I ain't a mainframe expert so can't provide more details but it's basically the same issue when a Unix system starts to spin on swap to keep the system alive.

In my time, I have done 100's of large scale db migs from unix to unix, unix to linux, linux to unix and linux to linux and one mig to a mainframe. All projects were successful with target performance matching or exceeding expectations except for one case: Unix to Linux on a mainframe.

Even with a fresh, unloaded mainframe, I felt migration performance when compared to other platforms was sluggish so maybe mainframes when used natively are fine but maybe when emulating Linux, it ain't great.

Sure, it's just one data point, but in my limited experience with LInux on a mainframe, it sucks..

Bluck

[Steve Channell]

Re: I am just some rando on the web but...

Seems like such a long time ago, I saw the same cliff running VM/SP with over-committed real memory.

It's likely your problems was Oracle rather than z/linux. 50 instances of Oracle is not the same as one instance with 50 schema/table-spaces, each instance will grab a large shared segment for the SGA resulting in over-committed real memory. On Solaris, Oracle use dynamic intimate memory to reduce load.

A "mainframe attitude" is to avoid public synonyms, and treat placement as a DBA decision, with one instance and multiple schema

[Slant Four]

Re: I am just some rando on the web but...

Not many people run a multi-tenant production oracle database instance... who would run an OLTP database alongside a DSS database or multiple high throughput OLTP databases in the same instance. You want dedicated resources that can be tuned for specific workloads. Dev db's and smaller less critical ones... sure

I am sure that many of the VM's touted as running great on mainframe run Oracle as above... so now we have two layers of virtualization.

The point I am making is while the mainframe is great for running native apps, just like moving a native mainframe ecosystem off a mainframe to Linux (i.e. it's hard with lots of traps), moving VMware OS images emulated on Linux which itself would now be emulated is full of risks.

Bluck.

[Steve Channell]

Re: I am just some rando on the web but...

That's simply not true.. Oracle used to make a big thing about its ability to run mixed workloads with Multi-Version-Concurrency-Control - though that was mostly pitched to OLTP and reporting on the same server.

Mixing OLAP and OLTP has different issues: [1] single SGA page cache reduces OLTP performance when large hash or sort-merge joins are running, [2] Adhoc/dynamic access is a risk that many would not want. When boxes are cheap, the cost of segregation is low

Combining multiple OLTP databases is only an issue if the box can't cope - the mainframe attitude is to provision a big-box capable of supporting multiple workloads without issue, using capacity-plan to provide better-than-SLA performance under normal operation. Cloud service and Oracle RAC design mirrors the mainframe with shared CXL memory pools.

[Doctor Syntax]

Re: I am just some rando on the web but...

"when emulating Linux"

Not that I've ever had my hands on one and not likely to ever do so, but Z-series is a native architecture for Linux these days so I don't see why "emulating" would be needed.

[Poink!]

Re: I am just some rando on the web but...

Bare metal on mainframe always runs better. Seems like the Oracleness needed to be cleaned up a bit. Worked for a fortune 50 insurance company that migrated many products back to Z/os bare or Linux environment on mainframe. Always had issues with Oracle because their DBAs were in Oracle-land thinking and not DB2 or DBMS or even generic SQL best practices. It is a slog to translate, but once done, the performance trounced x64 or Solaris (Sparc64) clustering solutions that were previously being used. This sounds like either a hardware limitation or a migration that didn't take into account what Oracle does in their environment. Oracle in Z always seemed to be 40-60% slower than native or linux when just ported directly over. Didn't have that issue with MS, MYSQL PostgreSQL, or others.

[lordminty]

Re: I am just some rando on the web but...

If your mainframe performance "went off a cliff", your mainframe Sysprog(s) wasn't doing their job properly!

There are shelves full of books on mainframe performance tuning. And I'm guessing your Storage team weren't up to much either, in terms of distribution of LUNs across the storage arrays.

Mainframe performance only goes "off a cliff" its its not configured and tuned correctly. Yes its an almost lost 'dark art', but a very necessary one. You don't just shovel your OS, page/swap, software libraries and DBs all on a few disks like on an average server. Its simply not how they're designed to work.

[Groo The Wanderer - A Canuck]

Still pushing the products of whoever pays you the most to shill them, eh, Gartner?

[Slant Four]

exactly

Lets take the least obvious platform to move VMware to, not have any practical experience in this but we will tout it cause that's what the customer wants.

I well remember when Linux on the mainframe first came out (I was at IBM and did some benchmarking of LInux Oracle workloads on it), IBM were touting you could run 10,000's of websites on a mainframe under LInux. I never heard of any customer doing this in my time at IBM (would have been big news on the sale channels I got feeds from)

Like running VMware on a mainframe under linux, it's a nice idea but has/had zero market traction.

Bluck

[herberts ghost]

If your virtualizing --- never get locked in --- if you do it is your own fault.

By using ANY vendor specific feature of the VM. The main test for a If your virtualizing --- never get locked in is, can you tell you are not running directly on HW. If you can you either have a possibly solvable performance problem, or your getting your self locked in.

[Jamie Jones]

Re: If your virtualizing --- never get locked in --- if you do it is your own fault.

I was going to say similar. Surely one of the main advantages of virtualisations of operating systems is you are host agnostic. If you can't move your instance to/from any other VM host, or even bare metal, then you're doing it wrong.

[FILE_ID.DIZ]

Re: If your virtualizing --- never get locked in --- if you do it is your own fault.

Sure, you are hardware agnostic, but have you not installed VMware tools or Hyper-V Integration tool? (BTW: Removing VMware tools is a right PITA after a migration.)

Then you need to consider that the backend networking could be completely different between the two virtualization platforms. (VXLAN - I'm looking at you!)

Then you need to consider that the virtualized disk format for each product is also different. Now you're looking at something like Double-Take.

Then you need to consider how different your backups may be done depending on the environment you came from and are going to. (Speaking to Veeam, specifically.)

So - yes, it's possible to migrate from one virtualization platform to another, but it's not as simple as copying a config file and some disk files over.

[Anonymous Coward]

So, what you are suggesting is moving from Broadcom Software to...

...Broadcom Software?

Someone doesn't know much about who owns the mainframe software space it seems (just like they own x86).

[Anonymous Coward]

A lot of boxes replaced by one large box

Garntner recommends z for those running over 500 instances of Linux. How many do that? Those that do should investigate.

[Anonymous Coward]

Re: A lot of boxes replaced by one large box

I'm running about 850, and I'd never consider moving them to z/OS. Maybe its because I haven't been a mainframe admin since 1999 (starting in 1988). Also, when did they stop running Linux on the FEP and start running on the main system CPUs?

[lordminty]

Re: A lot of boxes replaced by one large box

Wut? Lots of places run over 500 instances of Linux!

Place I worked had over 2,000 just for one business function. Overall they had over 60,000 VMs in total.

[DrXym]

I don't get it at all

VMWare is toxic and of course people should get the hell away from it. But the hardware it runs on is still viable. So it seems like the best solution is NOT to buy IBM hardware under any circumstances - just dump VMWare and use something else on the same racks - e.g. Promox, XCP-ng, or KVM.

There are migration tools for all of these (XCP-ng does most of it automatically with creds) so it should be viable to at least shift the non-critical VMs over immediately, potentially reducing licence usage and then start working on the more critical VMs individually with due care & attention until there are none left.

Same hardware, new software. No Broadcom, no IBM.

[Anonymous Coward]

It's another tool in the toolbox

I'm no fan of VMware, but there are instances where it's the best approach for a particular application set. Same is true for the mainframe. And for that matter, you could say the same about a cluster of standalone servers, or even one big honking server running the app. It's a matter of figuring out what works in _your_ environment with _your_ workload, _your_ support staff, and _your_ budget. Consultants arguing that one approach is "better" than the others gets so tiresome. I'm pleased to hear this one is at least asking folks to give the mainframe a fair shot in an evaluation, but we really need to start focusing on how one chooses the optimal platform for a specific function instead of all this "one way" nonsense.

[watsot]

Every single application that you run on VMware would have to be recompiled.