The Mainframe Is a Modern Platform
enterprisesystemsmedia.com
enterprisesystemsmedia.com
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)
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).
Because you want to avoid the churn associated with modern development?
You can choose boring technology like a sqlite backend accessed over the web via PHP and cgi without needing to learn an entirely different paradigm like the shift required for learning mainframes.
A mainframe is just a distributed system in a box, presenting similarly simplified APIs.
You realize that mainframes aren't just for running 40-year-old COBOL applications, right?
Pretty much any code you might write, including that written in the hippest, trendiest, fad-of-the-week language, will run on top of this "risky ecosystem".
Sure, you can run lots of Linux VMs on a mainframe. But now you need the skills for both --very different-- systems.
Some time ago, I was involved in a project to replace a mainframe and one important reason for it was that they could not find anyone willing to replace the retiring mainframe operators. Learn about Linux and you can work in fields ranging from tiny embedded devices to high performance computing. Learn about MVS and you are stuck in a shrinking niche.
> Pretty much any code you might write, including that written in the hippest, trendiest, fad-of-the-week language, will run on top of this "risky ecosystem".
Nobody has presented any compelling arguments as to why a business would want to do this. Why would I ever want to learn about z/OS as a developer? And if we're not using z/OS, and we're using Linux on IBM Z instead (which doesn't work without virtualization), why would I not just deploy to VMs/Kubernetes/other x86-64 or ARM based machines? It'd certainly save on the licensing costs!
S390 (IBM mainframe arch) is first-class citizen for RHEL, Ubuntu as well as languages like Java and golang.
Mainframes provide the largest single-image machines available today. A single z15 can have ~190 cores and 40 terabytes of memory and can be networked into a single-image group of sixteen machines to form a ~3000 core, 640 TB beast.
So, in essence, it allows one to program today your laptop of 2050. That's a pretty cool superpower.
Remember when 8 CPU 64-bit RISC machines running Unix were cutting-edge? There is one in my pocket right now.
The same will apply to a hypothetical 2050 laptop. There will be Some Hardware but the software around it will be almost unrecognisably different - assuming we still have laptops in 2050, which I doubt.
If, in 1990, I were asked to say what my laptop would look like, I'd say it'd use a microkernel OS like QNX and an intelligent assistant not unlike Sun's Starfire film.
So if we assume similar rates of technology development (doubtful), the Apple LapBook of 2050 would have 4PB RAM.
It's not required, but it's much easier to scale up than out. There is a point where managing the complexities of a distributed infrastructure of unreliable systems surpass its benefits and it starts to become interesting to consolidate your workloads inside a single extremely reliable environment.
But maybe the major mainframe using industry is banking. Processing many transactions does require scale, but not so much that the complexities of scaling out (ditributed Linux based system) are worse than the cost of scaling up (renting a mainframe).
I'm experiencing this on a daily base; you "only" need 100's of servers (not 1000's or more) to process banking data (let's say 100-150 transactions per second on average, with peaks of 500).
https://www.visa.com/blogarchives/us/2013/10/10/stress-test-...
- Read a line from a file?
- Insert a transaction into a database?
- Call an API using the transaction data?
- Fully process the transaction (a combination of the above and then some)?
Yes, mainframes are very fast, especially for some specific tasks. But they’re still just computers.
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.
That’s a pretty big exception, don’t you think?
BTW, Nvidia sells mainframes: https://www.nvidia.com/en-us/data-center/dgx-saturnv/
Read the whole comment, I guess.
And quite big business at that. Everybody starts their tiny startup with AWS and Heroku, because it literally costs nothing - and if you eventually scale up, you won't switch stacks in a such a radical way.
Mainframe will continue to be obscure until there is a downscaled option. The Z-series equivalent of Raspberry Pi.
Little reflection: The Cloud (PaaS & SaaS) is nothing else than the new Mainframe 2.0.
Same staff, different time.
- Mainframes provides you HA by hardware redundancy, The Cloud do the same using distributed consensus and virtualization.
- Mainframes offer a way to scale your infrastructure through vertical scaling. The Cloud does the same through horizontal scaling.
- Mainframes jail its users through proprietary software stack (COBOL&IBM), the Cloud do exactly the same through proprietary APIs & services (SQS, lambda, Aurora).
- Mainframes make you jailed financially to an hardware provider (support contract). The Cloud make you jailed financially to a service provider (BW, $/h).
- Mainframes were provided by Big-Corps in close to duopoly situation. Same for Cloud providers today.
Until you use Cloud Spanner or SQS or any other cloud specific technology.
https://www.redbooks.ibm.com/abstracts/sg248205.html
(Edit: poorly phrased the first time around...)
(Yes, yes, leaving aside IBM z/OS licensing restrictions which preclude use under Hercules)
IBM doesn't exactly hand out VSE or z/OS licenses for peanuts...
Unless your core business specifically targets the capabilities of chosen cloud specific tech, you can get away with developing on a supplemental solution and rely on CI plus staging environments to uncover and fix the edge cases that you miss this way.
This is especially true with low-level stuff like databases and queues. I've worked like this for years and never had to worry much about it.
Mainframes on the other hand are next to impossible to get in hardware and pretty much useless when emulated (what good is Hercules if you still can't get z/OS or VSE for it?).
Meaning, I can't run DynamoDB locally but PostgreSQL is close enough for most tasks, so sure I can kinda run that workload locally, but I won't learn any implementation-specific issues about how it would behave in AWS.
Similarly, I might have a hard time running DB2 for Z/OS, but I can also run it on Windows or Linux, and in this case I'm far closer to the actual development environment. Same is true for most of the dev tools and services commonly found in Z series environments.
I would argue the commenter above you is flat-out wrong: for most core AWS and Azure services, it's far easier to put together a home, single-desktop-PC-based dev environment for mainframe than it would be for cloud if you don't have the ability to actually use the cloud directly.
- Where with Mainframes, you had to be part of a medium corp / university to be able to touch one. With the Cloud, anyone worldwide with a laptop and 15$ in its wallet can learn how to use it.
That's a big difference and explain (partially) the exponential development of the Cloud.
Howevet in this world nothing is free. And we traded this accessibility for our confidentiality
- Where IBM had pretty low control on the usage of the hardware they were selling to you, Amazon now physically own both of your data and your software, and could technically know the color of the underwear of your CEO if they want to.
It's possible you see it this way because you've grown into your position before there was a cloud, or perhaps you had more free money to spend on things (pocket money or so on).
When I was younger, I was poor. The kind of poor I was (not starving, but no disposable income of any kind and certainly no personal money) is enough to kill the premise of learning a cloud provider dead.
What I mean is: if you need a credit card, it's probably not going to work. There's no way I could attach a credit card to something, there's no way I could spend $5/mo on learning, I didn't have $5 to my name, much less a credit card. And the risk of overspending even if you do have some spare income is fucking -scary- as a person who is poor. The idea that I could not have money for food because I forgot to delete something is stifling.
I learned nearly everything I know on 10 year old hardware that I picked up for free or near free. That is accessibility.
As it stands today I'm pretty flush with cash, but I -still- worry about unexpected cloud costs. Mostly because I work with it every day and know concretely how easy it is for the costs to balloon.
So, no, I think it's the same level of accessibility as mainframes, you can't work against an "old" cloud provider that you picked up for almost nothing. You have to put your money where your mouth is, and experimentation has a financial cost.
Only people who can help you foot the bill (university, employer) or who can clean down environments properly (tutorial labs) are going to make it even remotely more accessible, but it still wont be as accessible even then.
Accessibility of running things at home is why many of us are able to do this job, I think the majority of people my age spun up a PHP/MYSQL pairing and started messing with things, it was easy, and it was "free" if you already had a PC, and it could be exposed to the internet.. you learned a lot, incrementally.
This is the fundamental reason why certain tech prevails for so long.
I don't agree at all with this. You cannot simply buy an hold mainframe. And even if you did, transport costs alone would be higher than the cost of a free(!!!) cloud account. Plus you likely wouldn't have access to the required documentation.
You're basically comparing old PC hardware with cloud accessibility, which is something else entirely from mainframe computing (I can tell from first hand experience as I worked with mainframes for many years).
> Only people who can help you foot the bill (university, employer) or who can clean down environments properly (tutorial labs) are going to make it even remotely more accessible, but it still wont be as accessible even then.
WTH are you even talking about? You can limit the potential costs of cloud computing by sticking to the free offers (every major provider has them). I'd argue that if you can foot the bill for buying, transporting, and powering a used mainframe, you can easily afford a few bucks extra if you accidentally went over the free limit with a cloud service.
The only point I agree with you on is the credit card requirement. The rest is ramblings about a completely different topic - i.e. not related to mainframes at all.
I am equating the "accessibility" of cloud with the "accessibility" of mainframes in relation to PC hardware.
I do not refute the notion that mainframes are not accessible,
I am asserting the point that our lurch towards cloud hosted solutions with no on-prem replacement is the same lurch towards lack of accessibility that stifled the innovation and adoption of mainframes.
EDIT: also, Spanner and co often don't have free tiers, you're pretty limited in the amount of cloud services you can learn, and the danger of accidentally charging is inherent to the platform. The new budgeting features (which, are new btw) are good though, you have to be aware of them and know how to configure them though.
By the way how many of you planning on moving from Nodejs to Deno.
In mainframe there is a language Rexx, no change for last 10yrs.
The biggest lessons the mainframe has to teach software engineers is not around vertical scaling, uptime, backward compatibility or IO throughput but how software quickly becomes a liability and a risk rather than an asset or an advantage when it is not developed in a thoughtful disciplined way.
It's not broken. They need to hire an expert to fix that.
Also factor in the unkown risks and costs that will add up in the new solution. There are abundant horror stories of migrations that went bad and had to either be aborted and reversed, or that cost much more than originally expected, to the point of making the move a bad financial decision.
> when it is not developed in a thoughtful disciplined way
Most organizations don't allocate the budget for that and, if they did, they'd think the hardware is not expensive at all. Any hardware.
Their shiny app that they built a few years ago and is deployed succesfully into a companies systems, it will be maintained for a few years. Then some people will leave.
Then documentation (if there was any) will be lost.
A few rookie developers will be brought in and will try to learn the system and add a few widgets or features on.
Then in 20 years time, the app will be like the COBOL programs running on dusty mainframes.
History repeats itself
As someone who is maintaining products written (by me) 15 to 25 years ago, I know that I was absolutely wrong about that assumption. A company will not touch software if it works, no matter what the latest or greatest is and no matter if it looks like crap. I shudder to think, with JS projects breaking between minor versions of libraries, what happens if there is an issue 20 years from now... Egotistical really to use 'the latest and the greatest' and then just let 'the next person' live the pain of supporting that. You can say whatever about php and java but 20 year old code works fine with very minor changes; I have Node/JS code from 2 years ago that doesn't work anymore at all after security updates.
Doesn't that also depend on any libraries used? Java and the core framework have been stable but the rest of the ecosystem not so much.
I do think we have a stability crises in "modern" tooling, if your a company that wants to upgrade your old COBOL code to something that will run for another 30 years of little to no maintenance then there are very few options. C, C++, maybe java and PHP are the only mainstream options that have shown any long term stability and even with those you have to be very careful about dependencies.
Take the classic unicorn triad of finance/sales/development, and make a plan to exit as close to the peak of the revenue curve as possible. After all, the instantaneous value of peak income at the inflection point is pretty high. If all goes well (and it almost never does), you could be earning billion of dollars per second, at least if you ignore the burn rate.
It turns out that some 99% of the money to be made is under the curve between the initial peak and the end of the long tail -- and the end is not yet in sight for many mainframe applications. They're busy earning billions of dollars a year.
Recently the team learnt that no, those mainframes are not on-premises, they are in IBM cloud.
Also, mainframes are the most expensive way to run modern code so the fact that it's possible is not interesting.
I've been thinking about this a lot. I don't think many businesses have the margin to pay for the vast cost of a rewrite off of legacy. So maybe it's simply an evolution of business. Old businesses die and young businesses take their place with more efficient technology.
Unfortunately, it does not happen in industries that are heavily regulated, and probably where we need it most.
In a business context, the outcomes that your software enable are the things that matter. If your legacy platform still works and your business can still accomplish the things it wants to accomplish, why add a huge expensive distraction?
IBM still makes mainframes. You can still buy OpenVMS systems. There is no reason to believe that you will wake up one day and your technology will no longer exist. Don't hire people from Stanford or MIT. Recruit at 2nd tier schools and get them a year or two before you need them. They can learn all they need on the job, and they cost less, too.
> payments taking over a day to go through
That's due to the protocol. https://en.wikipedia.org/wiki/ACH_Network "when a real-time transfer is required, a wire transfer using a system such as the Federal Reserve's Fedwire is employed instead".
> people not being able to receive unemployment
That's probably not due to the mainframes. https://slate.com/technology/2020/04/new-jersey-unemployment... That's probably an administration issue. https://www.citylab.com/equity/2020/04/unemployment-benefits...
and
http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf
Should pretty much cover it :)
Edit: missed http
Consider that when you swipe your credit card and get payment approved in a store, that’s a round trip to the mainframe back at Visa HQ. Or when you withdraw cash from an ATM. Mainframes are perfectly capable of near-real-time operations at massive scale. The problems you mention are not technological.
The worst part is that a clean, entire rewrite isn't necessary: while everyone's familiar with a gradual refactor (module-by-module), fewer people seem to be aware of how better a proxied gradual rewrite is: where a single module/area in the old system is rewritten in the new system, but the old system's exposed interfaces remain the same and simply proxy or pass-through to the new system (to support existing clients and use-cases) while new clients can access the new system directly.
It's an approach I used for a rewrite of an old ASP.NET WebForms application to ASP.NET Core (famously the two are very incompatible: old WebForms *.aspx markup and stateful Page classes (don't forget `__VIEWSTATE`!) simply cannot even be refactored to work in ASP.NET Core: the only way forward is a total rewrite: but when an old .aspx is replaced, there's an `IHttpHandler` that takes its place and proxies the request to the new ASP.NET Core system and end-users are none-the-wiser (and by "proxy" I don't necessarily mean like a HTTP reverse-proxy - 90% of the time the new .NET Core code was running in-proc and invoked as a normal library reference because it targeted .NET Standard and so ran on .NET Framework 4.x instead of only the .NET Core runtime).
Now I know I can't compare a line-of-business web-application to a billion-dollar IBM-powered banking/insurance/public-sector - but I believe the same principles apply. Provided the original application _can_ be decoupled internally (thus to allow that proxying in the first place), then a gradual in-situ rewrite should be doable.
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.
Yes, it can run doom: https://github.com/xoreaxeaxeax/movfuscator/tree/master/vali...
It just doesn't run doom terribly fast.
Malloc isn't particularly more special than any libc function. It simply supports the fantasy that the memory is unlimited in scale. It was always of a static size, you were just handing off the chore of dividing it up. You can usefully implement dynamic sizing in languages with static memory allocation by pre-allocating large arrays and then maintaining handles and liveness flags. This is, in fact, how every console game used to do it until available memory sizes got into the hundreds of megabytes. Fragmentation and the subsequent crashes from OOM presented too much of a concern before then.
To be fair, z/OS is technically a Unix these days.
They already did, but seem to have a pathological aversion to actually publicizing it:
https://www-01.ibm.com/events/wwe/ast/mtm/audit.nsf/enrollal...
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.
My point wasn't that mainframes aren't useful - they are! - but that they're not good solutions for a lot of the new problems people are trying to solve lately. For instance, a huge portion of fun challenges are perfectly fine with eventually consistent solutions that optimize for availability, where one single piece of reliable hardware behind a couple of redundant peering connections simply can't compete with 1,000 reasonably reliable nodes distributed globally.
Obviously, nobody cares if the data that makes up your FB/Twitter timeline or Google search results page is less than completely reliable. The new problems people are trying to solve with horizontal scaling and distributed computing may well be "fun" for users and developers alike, but fun is quite different from generally worthwhile.
Financial transactions aren't the only "real" work out there, and there are lots of "fun" projects that are deadly serious.
Even today, reading the specs for the unit mentioned in the linked article, I’d have a hard time imagining running the Amazon.com website off a single mainframe. The shopping cart? Sure. The funny matching like “pjama wih ft” showing me “pajamas with feet”? I’d hate to be the one who had to power a million of those per second.
https://www-01.ibm.com/events/wwe/ast/mtm/audit.nsf/enrollal...
All z/OS docs are freely accessible online:
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pag...
That's just the base OS docs. Middleware and compiler docs are also free from other places at ibm.com.
IBM really need to pull their finger out and hype this.
(If you need more than a year btw, you can re-apply for a new ID in subsequent years. I've done it myself twice)
I remember playing with neural networks on my home Amiga way back when, and that was a fun toy. Now we say “here’s a petabyte of epidemic records. See anything unexpected?”
Or one time someone really wished they could do math even faster than the GPU would allow, and happened to glance at their graphics card, and now we have Dogecoin.
I think our industry has a great record of figuring out new ways to use things that was wholly unlike what the inventors had expected, and that’s probably what makes predicting our future directions so difficult. Like, we have ideas about problems we’d like to solve with quantum computers, but once they’re widely available I guarantee someone will realize they can also be used to make better Spotify playlists or such.
(Side note: the custom keyboard I bought last week has Amiga caps for the command keys).
One is data integration. Hopefully, https://www.categoricaldata.net/ will make a dent into this.
Another is RAD. Modern trend is to use Turing-complete languages such as Java, while in the past, a mix of application-oriented languages (COBOL on the MF) and system-oriented languages (assembler on the MF) was used.
I think there is some value in having a high-level language that is more domain specific for certain applications. For example like SAS, but SAS is old. Yet I don't see anything (at least anything open source or popular enough) that would be able to replace it. SQL can do some things, but it is also getting a bit old.
I will not comment much on the "modern" thing, I think the hardware is actually plenty modern (for example, IIRC z/Series processors were the first that had hardware transactional memory, and they have amazing hardware tracing capabilities), and as far as the software - I find that the older software is usually more performant, for whatever reason. There is also difference between Unix and mainframe philosophy about how to approach stuff (Unix is more permissive, mainframe is more tight), which I think has its merits as well.
That sounds interesting, any examples? The usual complaint about Unix is lack of fine-grain control over filesystem, but in practice this does not seem to be a problem, there are ACLs, selinux, etc. Is the situation better on mainframes?
I don't know if there is anything you can't do on Linux, except perhaps pervasive encryption, which allows to have some file operations (such as backups) running on encrypted files that the user (under which the backup or restore is running) cannot read.
There are also some really old things that would be considered unsafe today, but IBM is gradually fixing and deprecating them. This is pretty much because historically, z/OS was quite customizable, and lot of user space programs (utilities and middleware, not applications) had pretty intimate hooks into the operating system.
Also the auditing (not only in security) is excellent. The visibility into what the mainframe system is doing is unmatched on any other platform, I think.
Anyone who spent more time with emulating MVS (and possibly with weird accent emulating z/OS ;) ) probably encountered things like the assembly routine that you can link into every MVS version since 3.8 (all the way to recent z/OS) which hijacks tape mount requests before they are sent to operator, enabling you to connect whatever kind of tape-switching you want - in this case, doing special Hercules magic to change the tape image based on one of the parameters.
Why do they "need" this? What's wrong with a TUI? Must every single piece of software have a "modern web" interface?
If the option is between a TUI that's instant, and a React/Vue/whatever app that takes 15 seconds to load and breaks the back button... maybe the TUI ain't so bad?
That said, I do think that companies are running into serious issues trying to maintain and integrate legacy mainframe systems without fully or properly considering the maintenance costs.
Take the US airlines. My understanding is that these airlines are largely running on legacy booking and inventory systems that have been duct-taped together over the course of decades due to mergers and acquisitions, etc. Several large airlines have suffered major outages that were blamed on internal IT failures, sometimes resulting in grounded planes.
I’d love to hear more detail around this problem for those who have the context, but my understanding is that these companies have have many old systems that are costing a fortune to maintain and becoming less and less stable. I’d bet that you could find some pretty serious architecture flaws without digging too deeply into those systems, and I’d argue that those would be issues worth addressing above a UI.
Problem is that management can see and grasp a new UI far easier than architecture changes.
The issues you've heard are often related to intersection points between different systems handling different areas, for example the main passenger-handling system is usually outsourced to Amadeus (especially in EU it seems) or Sabre, then you might have onboarding software that can sometimes introduce you to mainframes most people never heard of (I know that at least one airline used Unisys). Some have in-house components that integrate with the rest. There's integration with airport baggage handling. There's plane monitoring and maintenance (which might include "cloud" services from vendors of the plane and separately of the engine), etc. etc.
Some of those systems are very new - KLM/AF have recently made a large enough development on z/TPF that they call it actually a new system. I know that I was VERY impressed with how fast a trained clerk worked using it, getting me a new flight after volcano grounded everyone, adding frequent flyer program etc. along the way. You know all those stories about expert ViM users? A typical trained user of one of those systems is at least as fast as them.
Quite often, the finger for failures is pointed (often for good reason) at outsourcing companies. Interestingly, it tends to not be Amadeus or Sabre that are pointed at, but well known companies like TCS, Wipro, Infosys...
Decent SPAs don’t take 15 seconds to load and they don’t break the back button. Stop spreading FUD.
It’s like the HN myth of how there’s supposedly all these old devs writing COBOL for the government and in reality the government can’t find any developers to maintain their ancient apps
Exactly. I worked at a private, multi-billion dollar organization a few years ago. There were plenty of "old devs" working on their COBOL software, but they also got paid more than 6 figures to do so. And they hired recent grads to work on those same systems. New grads typically started around 60k, more if you negotiated better. Whereas these gov't jobs only pay around 35k - 75k for the same work. For someone with years of experience.
Also, in mainframe-using orgs, there's often this weird idea of giving people training. Sometimes it's over a month of training where you have to sign a loyalty contract that you're going to work at least X months or repay them before you're allowed to take job with competition.
These aren't public facing apps you have to entice people to use, it's part of their job, if someone hits the back button and refuses to use it they're fired. Modern user friendly versions typically have half the functionality and take longer to do anything, they're universally reviled by people that took the time to learn the old green screen versions.
> Decent SPAs don’t take 15 seconds to load and they don’t break the back button. Stop spreading FUD.
Decent SPA's are few and far between, they take extra work to get this functionality that was free before SPA's.
The reality is, when it comes to transactions per second, reliability, security and vertical scaling - nothing beats them.
Also, it worked out about 60% less expensive to run a z-series for three years than it would've been to use a third party cloud solution.
So, yeah. Mainframes rock. And that's the reality of it.
It's uncommon to find people that have worked across both mainframes and commodity h/w and can make direct comparisons.
Edit: typo
In terms of security, z-series can be configured to meet the common criteria EAL 5 and beyond. Which is pretty d*mn secure and I don't believe can be matched by commodity hardware.
In terms of transactions per second, which is one of the most important metrics here, the z-series can cope with up to 1.1 millions per second. I believe the chunkiest single AWS instance maxes out at 10,000 tps.
Then there's reliability... a lot of these mainframe beasts have years, if not decades of up-time in a lot of cases.
On the downside, developing on them is clunky and there's a severe shortage of expertise. College graduates barely even know mainframes exist.
How much do these people get paid?
One of Google’s differentiating products is the TPU, to train neural networks in hardware. Meanwhile, the mainframe has specialized hardware for TLS, gzip compression and encrypted storage.
Low-latency networking is obviously relevant to anyone who might want to achieve similar levels of throughput+reliability by scaling out towards datacenter-scale computing. But modern mainframes are typically single systems - perhaps with a secondary system in an off-site data center for automated failover, but nothing much beyond that.
The difficulty is that doing this requires building a full vertical around the idea, and it's so hard to sell new big scary ideas to the business. So, the entire space is now fractured into 10000 vendors trying to sell you various nuanced aspects of the big picture. Combine with the cloud hysteria, and there's virtually zero chance you get to even experiment with this idea unless you take it up as a hobby and/or build a company around it.
To do this right for commodity x86 - that is, make it as or more reliable than a Z15 mainframe with equivalent performance - you have to do it on-prem and in a datacenter designed around the topology of the cluster. You cannot run something like this inside AWS/Azure/et.al. and expect it to perform well. You need direct fiber links between nodes without switches in the middle. Minimum of 5 nodes for N+2 redundancy. N+1 paths between every node. 2N+1 power/cooling. There is zero compromise you can take on the aspects of such a solution if you want to meet or beat IBM's insane numbers. On top of this, you would have to develop a software platform that is directly aware of your physical topology in order to properly leverage it. This implies writing new business software against your new platform. This is risky business. No reasonable shop would sign up for that ride unless you had 2-3 success stories and living, breathing clients to testify to the same effect.
For some carefully chosen, possibly hypothetical value of cluster,x86,server, reliable and performance.
To go from a hypothetical to a concrete would require an investment of time and money of sufficient magnitude to make the purchase/lease of an extant mainframe a compelling choice.
IOW, if my grandmother had wheels, she'd be a horse trailer.
As another commenter mentioned, Oxide Computer seems to be going for something not unlike this. People might compare their system-design target to the minicomputer (or the "supermini") as opposed to the mainframe, but that's just semantics at this point.
As for cobol, cobol will be running long after we are dead. It's a testament to cobol's resilience.
That being said, I am not a mainframe guy and I don't plan to be. The cloud, linux and container does what need and quickly. (Mainframers can add their snark here.)
A 4-socked Dell with 8 TB of RAM will cost you almost 400 thousand dollars and, in order to get 5 nines out of it, you'd better buy a bunch of them. You also won't be able to match the single thread performance of the z15 CPUs and almost a gigabyte of L4 cache.
Also, benchmarking these machines is not a simple thing when each machine is custom built to its owner's needs.
So, here's the thing: for mainframes we only have marketing data; the actual performance figures are secret. Which looks a bit suspicious, don't you think?
As for "custom-built" - nope, not such thing. You can choose the configuration, but it's all pre-made, nothing custom there.
At what cost? How much will you pay for a 4 socket Dell that has 8 TB of redundant memory? How much cheaper than a similarly capable z15 will it be?
> As for "custom-built" - nope, not such thing
How many configurations are available?
For the last decade or so IBM had been selling pretty much all mainframes with hot-swap FT cpu books, and the standard purchase model is very cloudy - you lease them (so it's all OPEX, instead of CAPEX), and in fact IBM will happily sell you "on-demand usage based pricing" for that lease. It's just that you can order that machine to be in your datacenter, but many clients simply use IBM's lesser-known cloud offering.
However. Seriously. Who the heck needs 5 9s? Who are dependent on only being able to hold their breaths for 60 milliseconds per week?
We are looking into, at best, many minutes of unscheduled downtime. Depending on your business model, that lost revenue could have paid for a lot of metal in the first place.
Our new APIs and web UIs are nice and all and offer a number of advantages for today's users/admins, but sometimes it feels they take more babysitting and fuss (updating deps, etc.) than the old mainframe code did - I'm not confident that an Angular SPA running for 20+ years would still work the same, so we have tried to take that into consideration while designing replacements.
I'm not complaining about one or the other but rather I feel lucky to have experienced tradeoffs and learned about how some of these problems were solved 20-30 years ago, while I was still in grade school.
I'm wondering if the same software can be deployed to mainframes and non-mainframes easily. Is the hardware sufficiently abstracted away so that it's like running a Docker file?
I do realize that virtual machines were invented in the mainframe era, but I'm wondering how it's done nowadays.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com...
I guess there'd be nothing to stop you eg. including a s390x Linux on Hercules into your build pipeline to produce z-ready images?
Pretty much any "modern" software you can write can run on these machines, if that's what you're wondering.
They simply dont like IBM. Or Mainframes from IBM.
Personally I love those ideals, 7 nines reliabilities, vertical scaling to the max rather than super horizontal scaling ( Conceptually simpler ). I just wish they were more accessible.
So, while the mainframe CAN be a modern platform, it may not be used as such.
If this were true, we'd see a massive uptick in the sales of mainframes.
Mainframes don't scale. Nor do the apps you build into them. Unless you have very deep engineering pockets. Most places though won't invest in this due to the high initial upfront cost.
This fact obviously isn't lost on the IBM, because they even market scaled down mainframe hardware as "kubernetes cluster in a box".
eg I want to run code on a mainframe and pay for the equivalent of a VM (or an actual VM)... who does this for a z15?
Others exist, but you might need to be looking for/googling a 'service bureau' (what cloud providers were called in the olden days)
Can you have it globally distributed? Cross datacenters? Blue/green deployments? Canary?
I saw a couple real world cases where banks went out of service due to an electricity outage, they could not switch the mainframes to another datacenter.
If you put a fault-tolerant multi/az app on AWS, the spinning disk or ssd may not have the 9s of mainframes, but the end users won’t notice if one stops work ring.
https://ibmsystemsmag.com/IBM-Z/07/2019/resiliency-gdps-solu...
Don't know enough about current mainframe development practices to answer the last two sorry, but I don't see why not.
(Edit: missing word)
The company I work for runs a few mainframes. The DCs have 2 circuits for power, batteries, and diesel generators. I’ve seen them run the tests on the generators.
Our “main” mainframe does not run 9s it runs 100% of the time or someone from IBM is getting on a plane...
Read a few pages into this where they talk about x86 cores.
https://www.datacenterknowledge.com/hardware/why-mainframes-...
It’s a sole source legacy platform with little or no new investment.
Just asking.
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.
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.
Clarification: Are you saying that Java is actually 50 years out of date?
https://developer.ibm.com/swift/2018/07/06/using-swift-creat...
https://www.rocketsoftware.com/product-categories/mainframe/...
https://developer.ibm.com/mainframe/2018/01/19/reasons-host-...