5 ms·

> It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossibl

> It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossible to migrate functionality off the mainframe. It is never technical or pratical reasons, always economic reasons. To use contemporary vocabulary, you "just" need to replicate a "multi tenant HA cloud environment" to migrate from a mainframe at great cost. > And now we are in a situation where their long held beliefs have become true because nobody is around that understands how or why the software works the way it does. Statistically unlikely, most of the business software that goes onto said mainframe is in fact very simple and straightforward and can be easly ported out, however, the real deal is all the integration and high availability logic built-in into "the mainframe platform". You're not porting that out without replicating said "multi tenant HA cloud environment" at great cost.

ojhughes 3y ago
I'm not sure how much water the multi tenant HA argument holds, these institutions are already doing that on AWS / Azure / k8s for the more modern apps. Rewriting all the old crusty COBOL code might be a different story.
- dralley 3y ago
  Getting the same performance out of AWS as a local mainframe is neither trivial nor cheap for a lot of the workloads these systems are running.
  - jeffbee 3y ago
    Getting stupefying amounts of I/O on AWS is as simple as turning a knob and getting out your credit card. The kind of throughput quoted in the article—48GB/s—is achievable on AWS for $250k/year, list price.
    - ElectricalUnion 3y ago
      I thought such throughput would cost around 30 274 560 USD/year (60 * 60 * 24 * 365 * 48 * 0.02) on data transit fees alone.
      - jeffbee 3y ago
        Obviously it would be very foolish to use an AWS storage backend for an application that was not also in AWS. That said, it is not at all clear to me that the TCO of a maxed-out IBM DS8900F is less than $30 million/year.
    - dralley 3y ago
      But let's say you want that data compressed and/or encrypted, you're going to need an awful lot of compute to exploit that 48GB/s if it's possible at all. Whereas on mainframe the service processors can deal with it transparently to the CPU using specialized hardware. And let's say it's financial transactions - fixed-point decimal arithmetic. On mainframe, that can be hardware accelerated too.
      - jeffbee 3y ago
        Yes, and it's interesting how Intel is moving in that direction with their Xeon line, integrating the QAT peripheral for compression and encryption offloading. Unfortunately these things are unicorns and that aren't generally available in the cloud, either.
        ghaff 3y ago
        Well, the general approach over the past 30 years or so has just been to mostly go with generic x86 hardware which would get predictably faster year-over-year and software could be written pretty generically for those platforms. With performance growth slowing, one of the answers has been to have more heterogenous and special function hardware and the software people will just have to deal with it.
    - shrubble 3y ago
      That is one channel of throughput, and a mainframe can have many channels, though.
  - WJW 3y ago
    Getting (and maintaining) a local mainframe in the first place is also not cheap though. I won't hazard a guess to which one might be easier to keep up and running, but at least in my bubble it would be 100x easier to hire more k8s admins than to hire qualified mainframe admins.
Zigurd 3y ago
The risk in a reengineering project that comprehensively replaces the mainframe is enough to discourage most people making that decision. It could be a $3M project that pays pack in 4 years after scrapping the mainframe and running out the maintenance contract, or it could go over budget and take forever to pay back. Your IBM rep has undoubtedly run the numbers.
wredue 3y ago
>most of the business software that goes into said mainframe is in fact very simple and straightforward Yeah no. I worked on mainframe code for 15 years of the last 20 and can tell you that you’re wrong. Even reasonably simple business lines have cobbled together insane cobol, batch and cics screens that would make spaghetti blush. When you open up a 100,000 line batch program that’s just 1 of 30 cobol programs in that run which is a mess of gotos, global mutable state and basically every single other generally frowned upon software practice we know about, you start to understand the issues. Moving off of mainframe is practically impossible because of it. That other person being voted down is actually correct, nobody in the organization actually knows how any of it works. When organizations try to transition away, what ends up happening is they get these insane promises of “5 years” from vendors (like IBM. Ask me how I know!), but then it takes 10 years to transition single systems. Nothing is documented. So you have business people who have no clue how anything works providing high level work flows. But then there’s always 50 random edge cases or interactions they never considered cause the 40 year old code just does it. IT contains most of the business knowledge, but the mainframe grey beards are… stubborn. The business hangs on to these people because they’re seen as insanely valuable, not realizing that the grey beards have actually been actively suppressing knowledge to only their hidden documents, and they’ve got 8 years till retirement and are going to make sure that their job exists at least until then by actively sabotaging efforts to change. But also, for some reason, the business manager love the saboteurs. It’s insane to watch.
- pmontra 3y ago
  What happens when there are new requirements? An example, fiscal legislation changes and programs dealing with money have to adapt. Of course a way out is to lobby for changes that don't touch the software, but what happens when the software must be touched?
  - wredue 3y ago
    The estimate for carbon tax legislation was 700 hours and it took 1600 hours and didn’t work correctly for 9 months following. Edit: and for the record, at that point, we were already splitting off carbon transactions for their own processing because, surprise, energy has lots of regulation.
TheRealDunkirk 3y ago
>> It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossible to migrate functionality off the mainframe. > It is never technical or pratical reasons, always economic reasons. To use contemporary vocabulary, you "just" need to replicate a "multi tenant HA cloud environment" to migrate from a mainframe at great cost. When your business processes are so ossified by a mainframe that you have, say, groups preparing Excel spreadsheets -- with data formatted from one mainframe screen in 3 columns -- for use by another group to input back into the mainframe -- with the data reformatted in 4 columns -- you know you're never escaping the gravity well of the black hole at the center of IT that is "The Mainframe." This is just how it's going to be until the company is so technically irrelevant that the remains are picked up in a fire sale by some PE to sell off to some other, tangentially-related company, solely for the IP assets.

ojhughes 3y ago

I'm not sure how much water the multi tenant HA argument holds, these institutions are already doing that on AWS / Azure / k8s for the more modern apps. Rewriting all the old crusty COBOL code might be a different story.

dralley 3y ago
Getting the same performance out of AWS as a local mainframe is neither trivial nor cheap for a lot of the workloads these systems are running.
- jeffbee 3y ago
  Getting stupefying amounts of I/O on AWS is as simple as turning a knob and getting out your credit card. The kind of throughput quoted in the article—48GB/s—is achievable on AWS for $250k/year, list price.
  - ElectricalUnion 3y ago
    I thought such throughput would cost around 30 274 560 USD/year (60 * 60 * 24 * 365 * 48 * 0.02) on data transit fees alone.
    - jeffbee 3y ago
      Obviously it would be very foolish to use an AWS storage backend for an application that was not also in AWS. That said, it is not at all clear to me that the TCO of a maxed-out IBM DS8900F is less than $30 million/year.
  - dralley 3y ago
    But let's say you want that data compressed and/or encrypted, you're going to need an awful lot of compute to exploit that 48GB/s if it's possible at all. Whereas on mainframe the service processors can deal with it transparently to the CPU using specialized hardware. And let's say it's financial transactions - fixed-point decimal arithmetic. On mainframe, that can be hardware accelerated too.
    - jeffbee 3y ago
      Yes, and it's interesting how Intel is moving in that direction with their Xeon line, integrating the QAT peripheral for compression and encryption offloading. Unfortunately these things are unicorns and that aren't generally available in the cloud, either.
      - ghaff 3y ago
        Well, the general approach over the past 30 years or so has just been to mostly go with generic x86 hardware which would get predictably faster year-over-year and software could be written pretty generically for those platforms. With performance growth slowing, one of the answers has been to have more heterogenous and special function hardware and the software people will just have to deal with it.
  - shrubble 3y ago
    That is one channel of throughput, and a mainframe can have many channels, though.
- WJW 3y ago
  Getting (and maintaining) a local mainframe in the first place is also not cheap though. I won't hazard a guess to which one might be easier to keep up and running, but at least in my bubble it would be 100x easier to hire more k8s admins than to hire qualified mainframe admins.

Zigurd 3y ago

The risk in a reengineering project that comprehensively replaces the mainframe is enough to discourage most people making that decision. It could be a $3M project that pays pack in 4 years after scrapping the mainframe and running out the maintenance contract, or it could go over budget and take forever to pay back. Your IBM rep has undoubtedly run the numbers.

wredue 3y ago

>most of the business software that goes into said mainframe is in fact very simple and straightforward Yeah no. I worked on mainframe code for 15 years of the last 20 and can tell you that you’re wrong. Even reasonably simple business lines have cobbled together insane cobol, batch and cics screens that would make spaghetti blush. When you open up a 100,000 line batch program that’s just 1 of 30 cobol programs in that run which is a mess of gotos, global mutable state and basically every single other generally frowned upon software practice we know about, you start to understand the issues. Moving off of mainframe is practically impossible because of it. That other person being voted down is actually correct, nobody in the organization actually knows how any of it works. When organizations try to transition away, what ends up happening is they get these insane promises of “5 years” from vendors (like IBM. Ask me how I know!), but then it takes 10 years to transition single systems. Nothing is documented. So you have business people who have no clue how anything works providing high level work flows. But then there’s always 50 random edge cases or interactions they never considered cause the 40 year old code just does it. IT contains most of the business knowledge, but the mainframe grey beards are… stubborn. The business hangs on to these people because they’re seen as insanely valuable, not realizing that the grey beards have actually been actively suppressing knowledge to only their hidden documents, and they’ve got 8 years till retirement and are going to make sure that their job exists at least until then by actively sabotaging efforts to change. But also, for some reason, the business manager love the saboteurs. It’s insane to watch.

pmontra 3y ago
What happens when there are new requirements? An example, fiscal legislation changes and programs dealing with money have to adapt. Of course a way out is to lobby for changes that don't touch the software, but what happens when the software must be touched?
- wredue 3y ago
  The estimate for carbon tax legislation was 700 hours and it took 1600 hours and didn’t work correctly for 9 months following. Edit: and for the record, at that point, we were already splitting off carbon transactions for their own processing because, surprise, energy has lots of regulation.

TheRealDunkirk 3y ago

>> It persists in many places due to the deeply ingrained belief that, for one reason or another, it would be technically, practically, or economically impossible to migrate functionality off the mainframe. > It is never technical or pratical reasons, always economic reasons. To use contemporary vocabulary, you "just" need to replicate a "multi tenant HA cloud environment" to migrate from a mainframe at great cost. When your business processes are so ossified by a mainframe that you have, say, groups preparing Excel spreadsheets -- with data formatted from one mainframe screen in 3 columns -- for use by another group to input back into the mainframe -- with the data reformatted in 4 columns -- you know you're never escaping the gravity well of the black hole at the center of IT that is "The Mainframe." This is just how it's going to be until the company is so technically irrelevant that the remains are picked up in a fire sale by some PE to sell off to some other, tangentially-related company, solely for the IP assets.