Mainframe versus Distributed

by Administrator on September 21, 2008

A fellow in Boston last week remarked that his management is working hard to get rid of the mainframe and hoping to leverage virtual servers to rehost applications.  He thinks (and I agree) that it is a terrible f—ing idea!

With a five person support team, his mainframe has not gone offline for as long as he can remember.  Downtime in the distributed server environment, which sports nearly ten times the administration requirements, is legendary.

The problem is, the entire mainframe environment shows up as a single line item in the IT budget, while distributed computing platform and support costs are spread all over the page, preventing an apples to apples comparison of cost and value.

We agreed that there are different apps and business needs that may support the need for both centralized and decentralized computing, for mainframes and for client/server.  However, a lot of boneheads in management aren’t seeing the truth of this in part because of the overwhelming noise of the distributed camp.  When it comes to storage, distributed systems don’t begin to approach the efficiency of storage behind mainframes.  Most of what the software folks are up to in distributed storage amounts to little more than trying to re-create what already works in the mainframe shop.

Guess I’m starting to sound like an old fart, but facts is facts.  All of SNIAs combined “architecture” (they are applying that term to XAM and SMI now) pales by comparison to big iron in terms of effect, reliability, scalability or cost-efficiency.

There.  I said it.

{ 2 comments… read them below or add one }

opensystemsguy September 24, 2008 at 2:47 pm

A few points just to play devil’s advocate:

“The problem is, the entire mainframe environment shows up as a single line item in the IT budget”- yes, but it’s a very very large line.

“When it comes to storage, distributed systems don’t begin to approach the efficiency of storage behind mainframes”- in terms of real hardware and software efficiency, you might be right, but in terms of $/GB while keeping a moderately high performance SLA, mainframe storage is pound for pound the most expensive you can buy.

“All of SNIAs combined “architecture” [...] pales by comparison to big iron in terms of effect, reliability, scalability or cost-efficiency”-
-Reliability is better on mainframes
-Scalability is about equal if you can choose to scale the application out or up
-Cost-efficiency is much higher on commodity servers unless you need the reliability of mainframes. A SAP solution running on Power or Intel compared to the same workload on a mainframe will usually have a lower total cost of ownership in the open systems area once you factor in the commodity open systems storage.

All that said, however, I respect the place mainframes have always occupied: ridiculously stable enterprise applications that have needed five nines availability for the last 10 years. Also, I think they show promise for massively parallel enterprise virtualization environments. I don’t think that they’re going to be the first choice of many when it comes to new applications though.

LeRoy Budnik September 28, 2008 at 10:24 pm

I agree that mainframe has its place. Most people in the open systems space, particularly the MS space do not do service cost accounting. If they did, they would see real numbers, and those numbers would be closer to mainframe. However, the mainframe is still highest cost, because it can be.

As to SNIA, I have to say that some of the other “old guys” working on the spec are guys who did the mainframe stuff. Sometimes that is a problem because the new kids think that they know it all and the old guys have difficulty comprehending the degree of risk acceptance taken on by the kids. Perhaps it is that the kids do not comprehend risk? while the mainframers have forgotten the agility of their youth?

I find it interesting that in the midst of building application gateways while distributing workload, it repeats a pattern – cluster controllers, which had the screens local to manage perception while minimizing communications cost – a 9.6 kb line could look good to 30 users. Isn’t this like Citrix? and so on.

XAM and SMI are not even related to the discussion, except that on the XAM side, there are some aspects of SMS. However, in the mainframe, the concept of lifecycle happened because storage was finite, and expensive. The fact that SMS evolved to include management of data sets was out of necessity. Yet, when Y2K passed and many people had moved to ERP solutions in open architectures, they moved with some though of “data forever”, or that we might be able to mine something in the future, essentially transferring the responsibility for the retention decision to their vendors.

Anyway, enough of my rambles – I think we agree.

Most of it is frustrating.

Previous post:

Next post: