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…
Google Cloud Bigtable and DynamoDB both appear to have ACID -- I don't see why mainframes would be better for this than cloud. Bitcoin is slow because of the many servers not in spite of it. Because of the design of the network, all servers need to receive every transaction and servers need to be able to be pretty small, which limits the transaction rate.
Ask HN: Why hasn't the cloud killed the mainframe?
41–50 of 88 posts
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#42The maintenance budget the central administrative system at IBM in 1985 was $4B or (about $9.6B in current dollars.) The idea of moving something like this to the cloud is hard to comprehend. Even if it could be done it would take years and cost maybe $100B. And what would be the ROI versus building new applications or businesses. These are business critical systems built to run in a specific environment, it is very…
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#43Google and Amazon don't use "the cloud" in the normal sense of a third-party public offering. They own the infrastructure that is also used by other customers as a cloud so in one sense it is private cloud but closer to on-prem than anything else.
Many other large businesses run on-prem instead of "the cloud" because the cost savings of a op-ex cloud system start to diminish when you already have your own infrastructure/networks/specialist staff as these large businesses have. Again, this is often a mix of traditional on-prem infrastructure and private clouds that offer some sharing of resources to applications that do not need an entire physical server.
Netflix, I think is a mixture of on-prem and public cloud but not sure.
So I'm not sure if you are asking "why mainframes instead of distributed e.g. microservices systems" or "why on-prem instead of using the cloud".
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#44I used the phrase "quiver of mainframes" as the compute tasks are best served by having a cluster of architectures - dedicated RAM in the tens of terrabytes, dedicated fast local storage in the petabytes, large custers of computer nodes optimised for pipelined throughput, others optimised for hyper cubed deep mesh computations, other architures again purely for graphical representations, etc.
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#45Earlier quoted context omitted.
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…
Google internally announced a while back that Bigtable (which powers Spanner etc.) hit 1B queries/second -- there definitely exist systems with far larger scale (though admittedly this is with lower atomicity requirements and probably includes reads etc.).
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#46Re: Ask HN: Why hasn't the cloud killed the mainframe?
#47First 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…
Simplicity. Because instead of having an enormous team to maintain their multi-million line Kubernetes configuration files that automatically spawns thousands of servers, having an enormous team that tries to fix the CAP problem, you go grab IBM, you tell them "this mainframe goes down, you're dead, here's half a billion in cash" and you run all of your software on a single, massive machine.
Sure, it adds other problems, but to be fair I'd rather deal with a mainframe than yet another microservice that doesn't work because Omega Star doesn't handle ISO timestamps and it blocks Galactus
>Does any company founded in the last 10-15-20 years use mainframes?
The biggest issue with mainframes are:
- High initial costs (although that's been changing)
- Nobody knows how to work on IBM Z mainframes
- The current zeitgeist about having a billion servers spread throughout the world because it's really important to have an edge CDN server for your cat trading card game
These industries didn't care about that because they could absorb these high initial costs, had the knowledge of the people building the mainframes, and were already highly centralized. Decentralization just adds more problems, it doesn't fix anything.
>I think it's much more in the inertia-point, the cost of rewriting these enormous applications is simply too large.
Rewriting just because it's not following the latest trend is garbage. These applications work. They're not going to work better because you're using Spanner now.
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#48First 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…
Rewriting your system to a mainframe architecture is equally as expensive.
Lets say that you save a hundred megabucks per year by going cloud (I am really not convinced, that you save any money at all, but lets say). That is what 1500 man-years of work? No way you can rewrite even a simple "banking" system in that amount of work, and the second problem is that you need to feature-freeze the old system (and hence your business) while you convert. So maybe 5 to 10 years of lost competitive power on top of that..
Also, remember these are not "begin work; select * from table where id = 123; commit;" transactions. These have maybe 50 to 200 queries (selects and updates) in each transaction (has the paying party the funds, is the receiving party blacklisted (terror organisation for example), does this look like money laundring.... etc... and a very detailed logging requirement by law). All of these MUST usually be in the same "snapshot" (in the RDBMS definition).
It makes no sense to talk about "transaction rates" without an intimate knowledge of what it does, as especially marketing departments have a tendency to use the simplest possible "transactions" to get a large number..
And in the end, it is only "money" the might loose, and any choice you make makes some other choices in the future easier (and some harder). That is called path dependency.
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#49You statement and question are different things. Its also worth pointing out that a mainframe can mean different things. Here I will use the definition of a large central machine (or cluster) designed for HPC. > Why hasnt cloud killed the mainframe A mainframe is typically a very powerful machine/cluster. You may be able to get those in the cloud (although I doubt you can get a single machine with >32TB RAM, for exam…
No, the questions are related. I am asking does the mainframe really deliver better cost/performance than the cloud (some of the mainframe prices are quite huge without even accounting for maintenance and recruitment costs)? Is this the reason why it is still a significant market?
It is irrelevant because those companies don't care about cost/performance.
They care about risks e.g. operational, security, regulatory etc.
And I would trust a mainframe over the cloud for those criteria any day of the week.
Re: Ask HN: Why hasn't the cloud killed the mainframe?
#50Earlier quoted context omitted.
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…
I've worked at three banks and it's not about cost. It's because they aren't stupid. 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…