4 ms·

Oh man, we not only get to use COBOL on mainframes, we get to use modern languages like Java and C too! When your idea of modern is a language created in 1995 a

by smabie 6y ago

Oh man, we not only get to use COBOL on mainframes, we get to use modern languages like Java and C too! When your idea of modern is a language created in 1995 and 1972, you know you're out of touch. Let's face it, everybody knows that mainframes are dying. IBM knows it, these Enterprise System Media guys know it (whoever they are), and most importantly, every one of these big fortune 500 companies stuck with COBOL apps know it. How many new projects are started each year that target mainframes? Or, alternatively, how many companies who don't have any mainframes are thinking about purchasing some for their new service? I'm guessing close to zero, or maybe even actually zero. The insane premium (in cost, in difficulty to learn, in everything) that you're paying for those bazillion 9s of reliability aren't worth it. Anyone who actually needs that kind of reliability has the technical knowledge to make it themselves using x86_64. According to his talking points, big tech should be loving mainframes and exclusively use them. But in fact, it's the opposite. The most savvy and powerful tech companies use commodity x86_64 while the not so savvy are stuck with their 1980s mainframes. In Emmanual Derman's "My Life as a Quant", he talks about developing a new bond analytics platform at Goldman Sachs. His team decided to build it on Unix (though Genera was floated around as an idea as well), because it was the modern choice and mainframes were legacy. And this was in the early 80s! This article is so unenthusiastic, it's kind of sad. It's like the author knows what he's saying is total bullshit. I predict that in the next 10 years, IBM is going to stop selling hardware (I'm not even sure why they haven't already, but then again, the company isn't exactly a paragon of good management) and just release some virtualization package that can run all the legacy crap on x86_64. Or maybe this has already happened, finding any information on what IBM an product actually does is quite difficult. I get the impression that no one actually calls IBM to inquire about a product. Instead, I'm sure some middle management guy sells out his company for a $60 steak and some wine.

pulse7 6y ago
"everybody knows that mainframes are dying" Please name a single modern machine which can reliably handle billions of financial transactions on December 31 every year, when everybody is shopping? I know you can handle this with cloud, but it's not so reliable and you need many servers... On the other hand, you have a single machine with decades of up-time...
- Qasaur 6y ago
  It is not impossible to build a system that can handle this on x86_64, it's more a question of software architecture rather than hardware architecture - modern computers are insanely powerful.
  - pulse7 6y ago
    They are powerful, but show me a x86_64 that has a decades long up-time and no failures...
    - smabie 6y ago
      The point is that it's unnecessary. The cost of such a reliable machine is far too high. It's better to have a bunch of cheap machines and program some failover system. It's like the actor model. It's better for an actor to just fail instead of trying and recovering. Just make sure another actor can take its place and that the failures are isolated from each other. By using this method, you avoid the enormous cost it takes to make something very reliable. It's the 80/20 problem. Let's say we have a service than whenever it handles a requests has a 80% chance of succeeding and a 20% chance of dying. The easy way to lower the chance of failing is to just have two services that handle the same request. If one fails, the other one might succeed. Using this strategy, we've now just lowered our failure rate to 4%, instead of 20%, with very little additional work. The cost of making only one service have a 4% failure rate (instead of 20%) is so much higher than a service that has a 20% failure rate. This is the perfect analogy, imo, for mainframes. So much effort and cost has gone into making these things super reliable. But it turns out, we don't actually need a super reliable system. For example, NYSE ditched it's mainframes a long time ago, because just using x86_64 and Linux to achieve the reliability needed is much cheaper and easier. And you would be hard pressed to find a company that needs as much reliability as a security exchange. If mainframes aren't worth it for NYSE (the mainframe apologists would say that NYSE is exactly the kind of company that needs mainframes the most), then they probably aren't worth it for anyone at all.
      - pulse7 6y ago

by smabie 6y ago

pulse7 6y ago

"everybody knows that mainframes are dying" Please name a single modern machine which can reliably handle billions of financial transactions on December 31 every year, when everybody is shopping? I know you can handle this with cloud, but it's not so reliable and you need many servers... On the other hand, you have a single machine with decades of up-time...

Qasaur 6y ago
It is not impossible to build a system that can handle this on x86_64, it's more a question of software architecture rather than hardware architecture - modern computers are insanely powerful.
- pulse7 6y ago
  They are powerful, but show me a x86_64 that has a decades long up-time and no failures...
  - smabie 6y ago
    The point is that it's unnecessary. The cost of such a reliable machine is far too high. It's better to have a bunch of cheap machines and program some failover system. It's like the actor model. It's better for an actor to just fail instead of trying and recovering. Just make sure another actor can take its place and that the failures are isolated from each other. By using this method, you avoid the enormous cost it takes to make something very reliable. It's the 80/20 problem. Let's say we have a service than whenever it handles a requests has a 80% chance of succeeding and a 20% chance of dying. The easy way to lower the chance of failing is to just have two services that handle the same request. If one fails, the other one might succeed. Using this strategy, we've now just lowered our failure rate to 4%, instead of 20%, with very little additional work. The cost of making only one service have a 4% failure rate (instead of 20%) is so much higher than a service that has a 20% failure rate. This is the perfect analogy, imo, for mainframes. So much effort and cost has gone into making these things super reliable. But it turns out, we don't actually need a super reliable system. For example, NYSE ditched it's mainframes a long time ago, because just using x86_64 and Linux to achieve the reliability needed is much cheaper and easier. And you would be hard pressed to find a company that needs as much reliability as a security exchange. If mainframes aren't worth it for NYSE (the mainframe apologists would say that NYSE is exactly the kind of company that needs mainframes the most), then they probably aren't worth it for anyone at all.
    - pulse7 6y ago