It’s an insular world in large part because of the pricing model that IBM/SAS doesn’t want to give up. No amount of claimed benefits can make adopting the mainframe a sane decision.
It’s an insular world in large part because of the pricing model that IBM/SAS doesn’t want to give up. No amount of claimed benefits can make adopting the mainframe a sane decision.
As opposed to more modern platforms, like the cloud!
The problem as I see it is IBM wants to have its cake and eat it too. Typically a Mainframe is leased and then setup onsite. Under this model, it would seem that you would get unlimited use out of it because you’re paying for the power, and it’s literally on site. However by charging per CPU usage, even though you’re using it on site, you still treat it as a “cloud” appliance in terms of pricing
If I spin up something in AWS for example, it’s metered yes but that comes to be at the benefit of not having the machine on site and therefore not having to worry about it’s power, upkeep, etc.
It would be like a car company selling you a car and then charging you to drive it per mile.
I think your comparing apples to oranges here.
I feel like engineering teams in payment and finance tech would like a word about this.
There are always extreme use cases that demand unconventional techniques. The stability of global financial networks is a fairly tough constraint to argue with.
Go and Rust can compile for Linux on s390x (64-bit zArch). Support for the proprietary zOS platform might be more of a challenge.