3 ms·
It's hard to think of it as a monopoly when the same services can be performed by a rack of servers running other software. For any type of data processing that
by GavinB 16y ago
It's hard to think of it as a monopoly when the same services can be performed by a rack of servers running other software. For any type of data processing that mainframes perform, I'm sure you can find examples of similar jobs running in server farms.
You can't define mainframes as a separate market just because they're physically large.
- jacquesm 16y agoThe whole point is that you can't. > You could perform the same services by a rack of servers running OTHER software. But with the software that is there today the cost of re-writing it would be prohibitive and that's why the mainframe market is still as large as it is. It's nothing to do with them being physically large. Converting a couple of billions of lines of COBOL to something more modern, re-test the whole thing and add a bunch of magic to get the same kind of reliability is not a task any sane CTO at a bank or insurance company is going to sign off on.
- sophacles 16y agoNot to mention, the system interface provided by mainframes has inherent failover capabilities. This means the cobol software is intentionally less robust in the "what happens if a part of the system fails" area, as that is something that rarely happens in a way that actually affects app level software.
- wmf 16y agoI think people are assuming that if you ported your COBOL app to a cluster you'd use some kind of middleware that provides the same "inherent" reliability that the mainframe environment provides. The cost of such middleware is an open question.
- gaius 16y agoWell, this is kind of "the web is the whole of computing" mentality. You pick up the phone, you get a dial tone, not a fail whale. You put in a plug, you get electricity. When a bank's core systems go down, it makes the evening news. It's a whole 'nother world from OMG sharding RoR lol that web kids think is "scalability".
- rbranson 16y agoWeb companies operate in a different world entirely. If Twitter goes down, it's sad, but nobody really cares. They also don't have very much money, so running lean on development time and hardware is critical to survival. If Twitter had the IT budgets like banks and insurance companies, things would be a little different. Of course scaling isn't that hard when you have billion dollar budgets. Per byte of content processed, Twitter probably operates at orders of magnitude more efficiency than banks or insurance companies. Each byte of data HAS to cost almost nothing, or the business can't exist. Nobody would pay for social networking, so it has to be dirt ass cheap.
- gaius 16y agoThe fascinating thing is that, including VC, Twitter really did - does - have a comparable IT budget. They could have just licensed Tibco Rendezvous, which is how banks and exchanges distribute thousands of price updates/sec, to the level of this desk at this bank is allowed to see that, but that desk isn't, and the other desk over there gets it 20 seconds later. Instead they went of and tilted at windmills, all the while telling themselves that they were breaking new ground.
- rbranson 16y agoI don't think the economics quite work out that way. Most enterprise scaling products are extremely expensive, have long sales cycles, and require lots of expertise to install and maintain them. They affect your application architecture design because of the per-server or per-socket licensing. You're also pretty much going to have to use that once it's purchased and put in place. If it no longer fits your business need, you've just wasted a ton of money. In fast-moving businesses this is absurd. For slow-moving industrial-age Fortune 100s, it makes more sense. It also really sucks when you run into a problem and can't open the damn thing up. Case in point: I was working with some code that was instrumented with HP OpenView OVPA to collect performance analytics. When the new version of OVPA came out, we were planning a huge rollout to bring all 4k+ servers up to date. Problem is, the new major release had moved to a pthreads library and changed a bunch of the threading code, causing a 2 second lockup on start due to some sloppy code. For the vast majority of server software, this is almost undetectable, but these were CGIs that were invoked millions of times per hour. It took me about a day to locate the problem with truss (Solaris' strace). I had to spend a week in 5am meetings with HP's offshore development team to convince them that it was their bug. Of course, it took another week to get a patch.
- bitwize 16y agoNo. You can't replace a mainframe with a rack of x86 boxes. In mission critical applications where reliability (effectively 100%; five nines just isn't good enough) and I/O throughput are of paramount importance, System z is your only choice. These applications underpin our entire monetary system, among other things.
- timthorn 16y agoYes, you can. I know of a delivered project at one of the World's major financial institutions where their mainframe was replaced with x86 hardware. The system architecture was funky, but the hardware was commodity. Just because one x86 box doesn't have the required level of reliability doesn't mean you can't build a reliable system out of them.