Obviously there is a business use case for mainframes, these can't all be legacy systems. But what is it? Can someone who has worked with such a system shed some light?
The business case is that they work, and have a great track record.
Overall the biggest selling point that I've seen is probably reliability. There's a perception that mainframes are more reliable than commodity-parts systems. In truth I think this is confirmation and sample bias; if you run a business that has a mainframe (very expensive, built for reliability, software has had 20+ years of debugging) and a bunch of servers (inexpensive, cost-optimized, software is constant work-in-progress), it's always going to seem as though the mainframe is unbreakable and everything else is dangerously unreliable. It's as much a mindset issue as an architectural one.
So many businesses will pay the premium for mainframes as their "core" systems, and then hang a lot of commodity systems off of it to provide access or interaction with the mainframe data.
I worked on a mainframe for a major Bay Area school district during and shortly after high school, as a computer operator and COBOL programmer.
I was there for a couple of years; rebooting the mainframe was unheard-of. It never seemed to develop memory leaks, it didn't get more quirky after it had been running for a long time. Since it wasn't accessible to the internet (or even most of the network), it didn't need to have any time spent on it trying to secure it against the latest Windows bug. It never required software updates, other than the ones that we coded ourselves and deployed without having to reboot anything. The database didn't fall over when we ran a payroll job or report cards.
But, best of all -- and I love telling this story, because I think it really illustrates something that the techs using all the modern stuff just don't "get" -- it had the best recovery systems I have ever seen, hands down.
So, one day there was a power outage. We had backup power systems, but like a lot of data processing departments we were just a couple of overworked people and they hadn't been checked in a while. They didn't last as long as we were expecting and the mainframe kicks off. Around that time, I'd been playing around with Linux and such, and I had some idea of just how ugly things got when a complex operating system powered off in the middle of doing things.
I was a little bit stressed out. The other guy, a clean-shaven greybeard, wasn't.
When the power came back on, the mainframe booted up -- quickly -- and resumed its operations from pretty much the exact point at which the power had gone out. It didn't miss a beat, none of the data it produced was erroneous.
That was in '98 or thereabouts.
To say that mainframes are more reliable than the popular alternatives is an understatement. :-)
1. Writing completely solid, fully debugged software is Not Sexy, which is why Linux is getting shinier and shinier but the software still has bugs.
2. You and I have probably been spoiled by working with Unix. Now, I've never used an IBM mainframe, but I have used VMS, which is definitely more businesslike than Unix. Working with VMS feels like going to the DMV. Imagine how it would feel to be living in a mainframe world, right out of IBM's most conservative, straight-laced era--because I'm gonna bet you wouldn't be able to play as fast and loose if you had mainframe-style fault tolerance.
Of course a big SMP such as System p has the same advantages (plus the greater familiarity of Unix), so in my mind the question stands. Why mainframes?
That is the real difference between mainframes and supercomputers. A supercomputer is about computation, a mainframe is about I/O.
2) Extreme reliability. There are mainframe clusters in production with a continual service availability for decades. Again, nothing in the Unix world can touch this.
2) When was the last time Google or Amazon or NASDAQ or Arca was actually out of service because of hardware failure or maintenance?
I would be willing to bet that Amazon do their warehouse and logistics operations on a mainframe too.
http://blog.seattletimes.nwsource.com/brierdudley/2008/05/am...
This stark distinction in order of magnitude of scale is why there may be so much incredulity here as to the technical superiority of mainframes.
NYSE also apparently unplugged their last mainframe in 2008[1]. It appears NASDAQ OMX's INET trading platform is based on x86-64/Linux/Oracle stack on commodity hardware[2]. NASDAQ's US exchange has a record of 194,205 orders per second[3]. The latest VisaNet peak message rate I could find was from 2008 and was 8,442 transactions per second[4]. Based on the fact that Visa aggregates transactions over hundreds of major banks, I would guess that each individual bank processes less credit card transactions. Visa's 2009 volume was 9.0 billion transactions[5]. I couldn't find anything substantial on NASDAQ's stock market order volume, but NASDAQ does about 10 billion contracts/year JUST in US & European option derivatives[6].
[1] http://searchdatacenter.techtarget.com/news/article/0,289142...
[2] http://www.nasdaqomx.com/digitalAssets/66/66992_genium_inet....
[3] http://www.nasdaqomxtrader.com/trader.aspx?id=inet
[4] http://investor.visa.com/phoenix.zhtml?c=215693&p=irol-n...
[5] http://www.creditcards.com/credit-card-news/credit-card-indu...
[6] http://www.nasdaq.com/aspx/company-news-story.aspx?storyid=2...
http://blogs.computerworld.com/14876/london_stock_exchange_d...
I imagine that the primary reason companies buy mainframes is that their monolithic architecture abstracts away a lot of the hard thinking that goes into a clustered system by putting it all in one chassis. If my 2000 CPUs are on separate machines then I have to write code to coordinate them and move data between them. If there's a super-fast bus connecting them and they can work with shared address space and let the OS deal with scheduling and data flow then even the average corporate code monkey can write naive large-scale apps that run a little slower but get the job done well enough to please their corporate overlords. And maybe the cost of developing a "proper" architecture for these sorts of business jobs is too high compared to the cost of a few hundred thousand in rent-a-mainframes.
Basically, the mainframe is FAST. Everything is simple there. The process in question was more or less a COBOL stored procedure doing a bunch of lookups in an incredibly denormalized DB2 database. The entire batch job would take less than 15 minutes on the mainframe of which this particular process was only a small fraction.
Now, the Java app to replace the mainframe process was apparently written by some smart dudes that had gone on to make lots of cash doing more exciting things by the time I got there. The replacement system was what lots of naive people drinking the Hibernate Kool-Aide were writing back then. The database was normalized to the extreme, it had a hierarchical object model that was mapped to objects with Hibernate, had a slick web interface, and so on. Well it ran like balls. It got exponentially slower as data was added. The administrative interface took 30 minutes to save a setting. This new process would increase the runtime of the overall batch by an estimated 10 hours. So I looked at it, and with another guy cleaned up a bunch of bad SQL and Hibernate.
The administrative interface got shaved down to seconds for a post. But in the end the overhead alone of marshaling and unmarshaling XML for the service calls was enough to push the batch process a full two hours longer than the mainframe one. Which, by the way, was unacceptably long for the 1 hour maximum processing window allotted to the batch.
OK, I know what you're saying. That's when you bring in the cloud and run a bunch of parallel instances and such and such. Or dump XML and use some kind of raw binary message format. But shit. The mainframe already did all that with a single threaded COBOL stored procedure in under 15 minutes. Needless to say, today they're still using that same old COBOL stored procedure and they're still making money hand over fist.
So yeah. Big companies spend lots of money trying to get off the mainframe every year. Believe me, I have personally witnessed tens of millions of USD lost to failed mainframe replacement projects by developers who think they know better. It's not like some manager looked at the the estimate and said "hell no." Actually they said, "Hell yes! My top architects say the mainframe is dead. I will write a check for $50 million dollars right now because that is nothing compared to the $10 billion in revenue we make." It's just not as easy as it looks.
- payment processing
- mail order sending (retail market)
- insurance databases
All on fairly large (world-sized) markets. Never programmed these myself, but had to interface (file or api) with it.
My feeling is that high reliability / data throughput is favored over programmer productivity and data structure elegance (most data I've seen there was fixed width strings :-).
See Host Integration Server (http://www.microsoft.com/biztalk/en/us/host-integration.aspx) for an example of product that allows to use .Net (I guess, even IronRuby) to talk to a mainframe.
However, 2-4x the bandwidth (and lower latency) than 10GE, for the same price, could make it compelling. Does the price you quote include all of host adapters, cables, and switch ports?
How is Infiniband not commodity?
How many suppliers are there for the critical components? There may be more than one vendor for adapters, but if they all use the same HBA-on-a-chip, the market hasn't yet been commoditized.
[1] Since my POV is centered around disk I/O, it would compete against SAS. Per 8-lane bundle, it's 24x the bandwidth at about $400 at the host and $100 at the expander, as of the previous generation. The current generation doubles the bandwidth, though I don't have reliable "street" prices yet.
You're ignoring System p, Superdome, Altix, Beckton, etc. which are also big SMPs but are significantly cheaper and easier to use than mainframes.