4 ms·

> Do realize that every time you swipe your credit card, you are very likely hitting a mainframe in a bank somewhere. Talk about throughput. Why do "mainframe"

> Do realize that every time you swipe your credit card, you are very likely hitting a mainframe in a bank somewhere. Talk about throughput. Why do "mainframe" computers stick around? (I use quotes because I'm not sure what qualifies a machine as a "mainframe"). I'm curious, and not trying to start an argument. Is it that more popular operating systems and languages we see on HN/SO aren't up to the task of operating at the scale/responsiveness required by financial institutions? Technical lock-in? If-it-aint-broke-don't-fix-it? I'm mildly surprised that these systems haven't been replaced by something more modern (or at least, modern sounding), but I am blissfully unaware of the world here and am likely missing important data that causes these types of institutions to use mainframe hardware/software.

loganfrederick 14y ago
I work for one of the major banks and all the reasons you listed are true. From talking to coworkers who work with the mainframes, the mainframes still provide fantastic performance that Java and other higher level languages haven't matched on the stack (yet). Also, the applications are so large and so critical to our customers that the process of transitioning to a new stack would be a nightmare for almost zero short-term gain. It should be noted that the industry is trying to make a push for porting the COBOL applications to Java to help resolve issues regarding an aging workforce, hiring, and documentation.
a-priori 14y ago
It's partly historical: these applications already exist on mainframes, and it would be very expensive to change, so they don't. But mainframes have a lot of advantages because they are integrated systems designed for exactly the sort of high-throughput tasks that businesses use them for. Their (single-threaded) processing power is good but not outstanding; where they really shine is parallel I/O performance which lets you execute large numbers of operations per second, or distribute workloads across large numbers of processors with extremely high bandwidth inter-processor communication. They're also designed to be highly reliable, redundant and modular. You can do things like upgrade and replace processors, RAM, and disk drives without interrupting applications. And speaking of processors and RAM, modern mainframes can scale to >100 processors and terabytes of RAM in one system. Yes, you can build systems with similar specs and capabilities with clusters of commodity hardware, but then you have the complexity of managing a distributed system. With a mainframe, you have a single beefy machine. You'll also have a support contract with the manufacturer to call when things break, so they can be responsible for doing any complicated maintenance. On the downside, of course, they're expensive in the "Q: how much does it cost? A: how much do you have?" way that enterprise pricing works.
yk 14y ago
I am not a mainframe guy, but AFAIK mainframes are very special beasts. Especially they guarentee very high aviability and have special hardware features to support this guarentees. So you do not use them in the first place if you are not more scared of downtime, than of hardware costs. And with this comes a specific very conservative style of software development. If it ain't broken, don't fix it. So a lot of the mainframe code is very old and will only be replaced, if the company is replaced by a competitor. And therefor compatible hardware will also stick around until the end of business operations.
Nick_C 14y ago
As well as the other reasons given here, the cost of conversion is much higher than you might otherwise think. Especially for banks, you have to prove that the new software meets with compliance regulations, not only for the financial regulators but also for the auditors (banking auditing is especially tough). Compliance does not mean just "meets all the unit tests", but also meets specifications like guaranteed uptime, stringent physical security (that alone could rule out many cloud services), tight audit trails, recoverable failures, incorruptible data, and so on. It opens up a whole can of worms that will dwarf the development cost of the software conversion alone. It's easy to see why many banks stick with their current working system.

loganfrederick 14y ago

I work for one of the major banks and all the reasons you listed are true. From talking to coworkers who work with the mainframes, the mainframes still provide fantastic performance that Java and other higher level languages haven't matched on the stack (yet). Also, the applications are so large and so critical to our customers that the process of transitioning to a new stack would be a nightmare for almost zero short-term gain. It should be noted that the industry is trying to make a push for porting the COBOL applications to Java to help resolve issues regarding an aging workforce, hiring, and documentation.

a-priori 14y ago

It's partly historical: these applications already exist on mainframes, and it would be very expensive to change, so they don't. But mainframes have a lot of advantages because they are integrated systems designed for exactly the sort of high-throughput tasks that businesses use them for. Their (single-threaded) processing power is good but not outstanding; where they really shine is parallel I/O performance which lets you execute large numbers of operations per second, or distribute workloads across large numbers of processors with extremely high bandwidth inter-processor communication. They're also designed to be highly reliable, redundant and modular. You can do things like upgrade and replace processors, RAM, and disk drives without interrupting applications. And speaking of processors and RAM, modern mainframes can scale to >100 processors and terabytes of RAM in one system. Yes, you can build systems with similar specs and capabilities with clusters of commodity hardware, but then you have the complexity of managing a distributed system. With a mainframe, you have a single beefy machine. You'll also have a support contract with the manufacturer to call when things break, so they can be responsible for doing any complicated maintenance. On the downside, of course, they're expensive in the "Q: how much does it cost? A: how much do you have?" way that enterprise pricing works.

yk 14y ago

I am not a mainframe guy, but AFAIK mainframes are very special beasts. Especially they guarentee very high aviability and have special hardware features to support this guarentees. So you do not use them in the first place if you are not more scared of downtime, than of hardware costs. And with this comes a specific very conservative style of software development. If it ain't broken, don't fix it. So a lot of the mainframe code is very old and will only be replaced, if the company is replaced by a competitor. And therefor compatible hardware will also stick around until the end of business operations.

Nick_C 14y ago

As well as the other reasons given here, the cost of conversion is much higher than you might otherwise think. Especially for banks, you have to prove that the new software meets with compliance regulations, not only for the financial regulators but also for the auditors (banking auditing is especially tough). Compliance does not mean just "meets all the unit tests", but also meets specifications like guaranteed uptime, stringent physical security (that alone could rule out many cloud services), tight audit trails, recoverable failures, incorruptible data, and so on. It opens up a whole can of worms that will dwarf the development cost of the software conversion alone. It's easy to see why many banks stick with their current working system.