First of all, I find I kinda funny that you call banking, retail and insurance "legacy industries". I would rather be without Netflix and Google, than banking and food ... but each to their own.. While some is inertia (mostly doing to rewriting truly large applications are hard and expensive), there is also the the point that most of those industries cannot easily handle "eventually consistent" data.. Not all transac…
I have no expertise in this area, but two counter arguments pop'ed in my head: 1: I wonder how many transactions the largest e.g Postgres clusters (or other classic RDBMS) handles per day. 500M+/day doesn't seem that incredibly high? 2: Google Spanner, which I would classify as cloudy, promises ACID guarantees at a global distributed scale. Couldn't that be used? I've listened to a Swedish developer podcast where the…
Ask HN: Why hasn't the cloud killed the mainframe?
31–40 of 88 posts
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#32First of all, I find I kinda funny that you call banking, retail and insurance "legacy industries". I would rather be without Netflix and Google, than banking and food ... but each to their own.. While some is inertia (mostly doing to rewriting truly large applications are hard and expensive), there is also the the point that most of those industries cannot easily handle "eventually consistent" data.. Not all transac…
legacy industry is sort of standard term not sure why you found it funny. It not meant to say they are less important. From quick google: "Legacy industries are those that have been around for a long time. These industries dominate a specific market and have not always had a positive approach to innovative ideas."
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#33Re: Ask HN: Why hasn't the cloud killed the mainframe?
#34"""
Many factors from cost to regulatory requirements to cryptography and other security requirements play a role in making a decision to run a core banking platform in the cloud. Whilst the cloud is good for managing certain services (which we indeed use), it becomes a challenge to manage a bank’s core banking platform.
Once infrastructure is in a cloud, it is outsourced to that cloud provider. That means that the business is bound by those agreements covering aspects such as scalability, usage, capacity-on-demand and disaster recovery. These costs could grow exponentially as volumes grow. By using our own infrastructure for our core banking platform, we have full control over these factors.
Our chosen mainframe solution provides the ability for us to grow exponentially, while controlling all factors (CPU, Memory, Disk, Network, DR, Remote capability, etc) allowing us to manage the environment efficiently and effectively.
"""
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#35When you have reliability/continuity as a top business requirement and ACID transactions (e.g. billing) must be processed at scale, then mainframes shine.
The argument "Never change a running system." is not a wrong one, but it does not on its own explain the existence of mainframes; there are non-legacy scenarios where using a mainframe is the most reasonably choice. Finally, "cloud" as a term denoting outsourced compute/storage capacity can also apply to mainframes, see e.g. IBM's pricing brief at https://www.ibm.com/downloads/cas/YM94KV6N - some own their mainframe, some rent it - like a prive or public (internal or external) cloud.
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#36No business in their right mind would want to be on out of date, proprietary technology with hard to source skills, but the cost and effort of migration is enormous. There are scare stories of SAP migrations costing $billions and I assume a mainframe migration could be multiples of this.
What would be interesting is if they let actual enlightened techies size up and run these projects, rather than giving to Accenture and the like. Maybe it wouldn’t be insurmountable then?
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#37Re: Ask HN: Why hasn't the cloud killed the mainframe?
#38It is simply about a wholly different level of reliability that mainframes provide. They are not at all a trash or a product of corruption or nepotism as many tend to think. That stuff works all the time, and did since ~1960, while we serfs spend our lives fixing bugs resulting from never-ending updates in that hodgepodge of javascript libraries our "efficient", "cheap", "FOSS-based" products are made of. We all don'…
Not just because of the expensive hardware, but also because it's all but impossible to get your hands on them as a developer. With Java, JS, Python, .NET, whatever companies have an insanely large pool of people to choose from... quite a few self-taught, some who went to university and studied CS, some who went to more or less decent bootcamps, some who "grew into" programming from other roles. On top of that, last I heard (admittedly a decade ago) the tooling to work on mainframe systems is just as old as the code they're running, so no modern IDEs, debuggers and whatnot.
With mainframes however, companies have to spend their own money, and quite a lot of it, to get trained developers, and on top of that pay a hefty premium for those who submit to fossilized tooling willingly.
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#39Re: Ask HN: Why hasn't the cloud killed the mainframe?
#40First of all, I find I kinda funny that you call banking, retail and insurance "legacy industries". I would rather be without Netflix and Google, than banking and food ... but each to their own.. While some is inertia (mostly doing to rewriting truly large applications are hard and expensive), there is also the the point that most of those industries cannot easily handle "eventually consistent" data.. Not all transac…
I have no expertise in this area, but two counter arguments pop'ed in my head: 1: I wonder how many transactions the largest e.g Postgres clusters (or other classic RDBMS) handles per day. 500M+/day doesn't seem that incredibly high? 2: Google Spanner, which I would classify as cloudy, promises ACID guarantees at a global distributed scale. Couldn't that be used? I've listened to a Swedish developer podcast where the…
Young developers often think that banks, insurance companies etc. should just rewrite these "legacy" systems because it will bring all of these magical benefits with no risk. Whereas older developers who have worked on (a) mission-critical applications, (b) major re-platforming efforts and (c) projects in a highly regulated industry know the score.
Doing just one is hard. Doing all three at the same time is suicidal. The chance of project success is basically in the single digits. And the risk of failure is billions in lost revenue and your future prospects in the company and within the broader industry ruined.