[HN Gopher] The Mainframe Is a Modern Platform
___________________________________________________________________
The Mainframe Is a Modern Platform
Author : rbanffy
Score : 16 points
Date : 2020-05-19 21:34 UTC (1 hours ago)
(HTM) web link (www.enterprisesystemsmedia.com)
(TXT) w3m dump (www.enterprisesystemsmedia.com)
| wmf wrote:
| This doesn't really matter. Legacy apps need to be modernized but
| their owners can't afford/aren't willing to. It's not the
| mainframe holding these apps back... the problem is much much
| worse.
|
| Also, mainframes are the most expensive way to run modern code so
| the fact that it's possible is not interesting.
| [deleted]
| kstrauser wrote:
| No, it's not. A mainframe is awesome for certain classes of
| problems, but I don't generally think of those classes as modern.
| Yes, you _can_ run ML on a mainframe, but its performance isn 't
| going to scale as broadly as throwing a thousand ephemeral
| virtual hosts at the problem (why virtual? because I'm not
| running ML 24/7 and don't want to pay for the cluster while
| everyone is at home asleep). Sure, maybe it can handle 12 million
| web requests per second - I'm skeptical about the complexity of
| those requests but let's roll with it - but now the computing
| resource is more robust than the network connections you have
| plugged into it. Are the pipes into your data center truly more
| reliable than a multi-AZ, multi-region AWS deployment?
|
| To put it bluntly, mainframes are wonderful solutions to problems
| that I don't personally find interesting. (Note: personally. It's
| not like I don't think there's a legitimate need for the
| financial systems that mainframes power, it's just that I'm glad
| I'm not the one who has to run them.) The problems I enjoy
| involve horizontal scaling at levels that a mainframe just isn't
| going to reach, and those are the kinds of problems that most
| people would describe as "modern". And as I don't think
| mainframes are a good solution to what I consider to be modern
| problems, neither do I consider them to be a modern platform.
|
| Again, not that this makes them less valuable for the problems
| they _do_ solve. I don 't want to run a stock exchange with its
| gazillion transactions (as in the database _and_ financial kind)
| per second on a cluster of x86 VMs.
|
| Edit: But you want to make them modern, make it easier to play
| with the damn things. I can get almost any other kind of
| computing tech into my house for under $1,000, but it's freaking
| impossible to experiment on a mainframe without selling a kidney
| or signing a contract in blood. If your platform's "learn more"
| link goes to a form read by a salesperson, you've already lost
| me. If I have to pull out a credit card to tinker with it, you've
| already lost me. Contrast with AWS, for example, which
| practically throws free resources at you to get you interested
| and invested in the platform. Where are my free IBM resources
| that get me a mainframe login and access to developer-useful
| documentation? As it stands today, if I want to learn how to
| operate Big Iron, I pretty much have to take a job doing it full-
| time. Make it easy for me to poke at one at night and on weekends
| if you want me to tell my boss about this cool thing you're
| trying to sell.
| zozbot234 wrote:
| Except that mainframe-like platforms are all about vertical as
| opposed to horizontal scaling, particularly for transactional
| workloads where this kind of scaling is highly relevant. You
| can't horizontally scale a database (beyond trivial sharding of
| logically-independent partitions, perhaps with some further
| dependency on rarely-changing data that can thus be
| replicated/cached locally) without severe tradeoffs in both
| latency and reliability.
| marktangotango wrote:
| Given all the attention COBOL has gotten lately, I still haven't
| seen any discussion of its characteristics that make it
| relatively "safe", secure, and fast. These are; all memory is
| statically allocated, no dynamic memory allocation. No user
| defined functions and no stack. Of course I'm referring to the 85
| standard here and later versions added these things but 85 is
| very common on mainframes (my understanding please correct if
| wrong).
|
| These two things disallow entire classes of exploits and errors.
|
| Edit to add, rather than put out these puff pieces, ibm needs to
| figure out how to get mainframe access for developers, only then
| will they see usage increase.
| voldacar wrote:
| Those things also disallow entire classes of program. Good luck
| writing a webserver or game engine without heap allocation
| shoo wrote:
| While not addressing the comment of writing programs without
| heap allocation, a lot of programs can be compiled to execute
| using the only mov instructions:
| https://github.com/xoreaxeaxeax/movfuscator
|
| Yes, it can run doom: https://github.com/xoreaxeaxeax/movfusc
| ator/tree/master/vali...
|
| It just doesn't run doom terribly fast.
| bashook wrote:
| Is ASLR a capable solution to those weaknesses? ASLR is
| supported by the operating system. Though a system
| administrator would have to turn it on by following these
| instructions:
| https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com...
| timwaagh wrote:
| I would say developing for java that ultimately will run on
| mainframe is worse than developing for java for another platform
| (because deploying to your development websphere is slow and not
| so reliable). The other problem is that Java is the most 'modern'
| programming language available. Nobody wants to write a web app
| in COBOL or C. But Java isn't that good at it either (even
| without websphere, java does not deploy as fast as python, ruby,
| php, go). The only misconception is that its 20 years out of date
| instead of 50. The best reason to stay well clear of it is cost,
| though. Not just increased development cost but those things are
| expensive. But for a developer it can be good. Mainframe orgs
| tend to be stable and pay above average.
| Multicomp wrote:
| If nobody but a business can afford a computing platform, it is
| doomed long-term. Everything was on mainframes until PCS were
| good enough and now 'everything' is on a PC, on prem or in the
| cloud. Even the serverless things are run on someone's PC
| somewhere. With the exception of the bleeding edge of high-speed
| computing with large amounts of data or old legacy banks that
| couldn't support a 10 character password if their lives depended
| on it, x86 or amd64 rule the world.
|
| IBM does not get to boss us around anymore with their industry-
| specific terms that they refuse to use standard industry jargon
| instead.
|
| > have you ever tried to run a Windows 3 app on Windows 10
|
| Yes. It is called cardfile and it runs fine even though Windows
| 10 tries its best to never work on anything that isn't a
| telemetry laid in uwp social sharing app. No expensive mainframe
| needed.
|
| (Windows experts will note that card file has 32-bit versions and
| not just 16-bit versions but hop back even one version of Windows
| and it can run 16-bit stuff as well so well my example wasn't
| perfect my point stands)
| akersten wrote:
| Yep. The article is pretty comical too - somehow, being able to
| write a C or Java app that runs on the mainframe, and having
| mobile access to the mainframe terminal, means that the
| platform is modern!
| _jal wrote:
| Reads like a book report written by someone who was trying
| but eventually conceded to an utter lack of interest.
| lol768 wrote:
| > Everything was on mainframes until PCS were good enough and
| now 'everything' is on a PC, on prem or in the cloud
|
| 100% agree with this - as a business, why would you want to pay
| the IBM support contract costs? As a developer, why would you
| want to waste your time learning about this sort of tech (I
| can't think of a more risky ecosystem to invest your time into
| learning in terms of chance of the skillset becoming obsolete)?
|
| I've yet to hear about any legitimate usecases that couldn't be
| accomplished using x86/amd64 VMs/machines. Monzo has clearly
| shown it's not required in banking (and frankly, have shown how
| slow and generally useless the other legacy banks have been
| when it comes to innovating on top of these mainframe-based
| platforms).
| hinkley wrote:
| If we are going to think of history as a wheel and try to learn
| from that history, I think you have to factor minicomputers
| into your timeline. There were a gateway to PCs, which lead to
| laptops and smart phones.
|
| Administratively, you could argue that AWS is a time-shared
| mainframe. Or, perhaps, a time-share company in possession of a
| handful of mainframes. That opens the door for IBM to walk
| through and claim that they were here the whole time. Frankly,
| I'm not sure we want to be there, for reasons you already
| referenced.
|
| My suspicion and, dare I say, proposal, is that Brian
| Cantrell's group is currently trying to reinvent the mini
| computer with open source software and 95% COTS hardware.
___________________________________________________________________
(page generated 2020-05-19 23:00 UTC)