3 ms·

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 cl

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 they interviewed an old school mainframe developer in the banking sector. He brought up similar points about the scale and correctness of database transactions, and it didn't feel convincing to me. What does Paypal, Klarna, or even maybe Amazon give up by not using mainframes? Does any company founded in the last 10-15-20 years use mainframes? If not, does that mean that "modern" companies can't compete in these high-demand industries like retail or insurance? I think it's much more in the inertia-point, the cost of rewriting these enormous applications is simply too large.

andomggazzz662 3y ago
Amazon does use mainframes. They aren't a payment processor and don't handle that part of the processing. That's why the likes of VISA get to charge their fee.
why_only_15 3y ago
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.).
- eastern 3y ago
  VISA does 500m+ transactions per day and Spanner does 1B queries per day, but it's quite unlikely that what a transaction means on VISA is the same as what a query means on Spanner.
  - filleokus 3y ago
    Spanner does over 1B queries per SECOND (but your other point still stands of course)
    - svennek 3y ago
      If it is readonly shared-nothing queries, I am sure the hardware I have in my flat can do that as well.. The hard parts are updates in a shared system with a single consistent "view" requirement..
      - why_only_15 3y ago
        The hardware in your flat definitely cannot do 1 billion queries per second -- that requires a massive, global system, which can probably also support a shared system with ~100,000x less queries.
- rstuart4133 3y ago
  That sounds so impressive I googled it. It's actually 6 billion queries per second: https://id.cloud-ace.com/how-youtube-uses-bigtable-to-power-one-of-the-worlds-largest-streaming-services/ https://id.cloud-ace.com/how-youtube-uses-bigtable-to-power-... But then I mulled over it for a while, and it occurred to me it's likely Sqlite does orders of magnitude more than that planet wide. Spanner's 1 billion per second is more impressive: https://cloud.google.com/blog/topics/developers-practitioners/how-spanner-and-bigquery-work-together-handle-transactional-and-analytical-workloads https://cloud.google.com/blog/topics/developers-practitioner..., assuming it's returning a consistent view across many tables. But the Sqlite comparison still stands. Visa claims 24,000 TPS, but in reality runs at a 10'th of that. It would be interesting to see if Spanner could process the same 2,000 transactions per second. Sqlite definitely can't.
threeseed 3y ago
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 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.
- ak_111 3y ago
  Not so sure, experienced tech managers are also very wary of vendor lock-in and tech debt which mainframes give you in spades.
  - ohgodplsno 3y ago
    The vendor lock-in is a feature to them. They're not a tech company. They're banks. They're insurances. Lock-in means they can send a lot of cash to someone and the problem gets fixed, which is the only thing they care about. And in good news, cash is also a thing they have a lot of. The cost of their tech infrastructure is a blip on the radar compared to payroll, to the cost of their physical spaces.
  - threeseed 3y ago
    I assume from this comment that you've never worked in the enterprise. Because (a) major decisions like choosing a mainframe are not made by tech managers and (b) every company is built around vendor lock-in. Who do you think companies like Atlassian, Oracle, Salesforce etc sell to ?
    - paleotrope 3y ago
      It's a little off to think that a mainframe was "chosen". Software and the companies that write it and support it "chose" the hardware for you.
ohgodplsno 3y ago
>What does Paypal, Klarna, or even maybe Amazon give up by not using mainframes? 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.
svennek 3y ago
Remember inertia goes both ways. As soon as you have a large system "in the cloud" or otherwise "distributed" (also only in your shed). 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.
- filleokus 3y ago
  I agree, it's obviously very hard to compare transaction rates, and I also agree that I have hard time seeing companies currently using mainframes recouping the cost of migrating. If it works, it works. But. > Rewriting your system to a mainframe architecture is equally as expensive. There was a new bank mentioned in this thread that actually started using mainframes from scratch, but other than that I've never heard of any "modern" fintech (or really any) company introducing mainframes. Organisations actually rewriting functioning systems TO mainframe must be almost never heard of (in the last 10-20 years at least). If System Z, Cobol and DB2 are so obviously superior, why are so many successful new competitors in industries where they are the norm in older companies choosing to not use them? I'm not saying banks should rewrite their stuff in node.js (or deno - even better of course), it makes sense for them to stay. I just have a hard time believing that mainframe systems are so technically impressive, to the point where some people claim it's almost impossible to build a similar system on non-mainframe technologies.
deleted 3y ago
[deleted]

andomggazzz662 3y ago

Amazon does use mainframes. They aren't a payment processor and don't handle that part of the processing. That's why the likes of VISA get to charge their fee.

why_only_15 3y ago

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.).

eastern 3y ago
VISA does 500m+ transactions per day and Spanner does 1B queries per day, but it's quite unlikely that what a transaction means on VISA is the same as what a query means on Spanner.
- filleokus 3y ago
  Spanner does over 1B queries per SECOND (but your other point still stands of course)
  - svennek 3y ago
    If it is readonly shared-nothing queries, I am sure the hardware I have in my flat can do that as well.. The hard parts are updates in a shared system with a single consistent "view" requirement..
    - why_only_15 3y ago
      The hardware in your flat definitely cannot do 1 billion queries per second -- that requires a massive, global system, which can probably also support a shared system with ~100,000x less queries.
rstuart4133 3y ago
That sounds so impressive I googled it. It's actually 6 billion queries per second: https://id.cloud-ace.com/how-youtube-uses-bigtable-to-power-one-of-the-worlds-largest-streaming-services/ https://id.cloud-ace.com/how-youtube-uses-bigtable-to-power-... But then I mulled over it for a while, and it occurred to me it's likely Sqlite does orders of magnitude more than that planet wide. Spanner's 1 billion per second is more impressive: https://cloud.google.com/blog/topics/developers-practitioners/how-spanner-and-bigquery-work-together-handle-transactional-and-analytical-workloads https://cloud.google.com/blog/topics/developers-practitioner..., assuming it's returning a consistent view across many tables. But the Sqlite comparison still stands. Visa claims 24,000 TPS, but in reality runs at a 10'th of that. It would be interesting to see if Spanner could process the same 2,000 transactions per second. Sqlite definitely can't.

threeseed 3y ago

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 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.

ak_111 3y ago
Not so sure, experienced tech managers are also very wary of vendor lock-in and tech debt which mainframes give you in spades.
- ohgodplsno 3y ago
  The vendor lock-in is a feature to them. They're not a tech company. They're banks. They're insurances. Lock-in means they can send a lot of cash to someone and the problem gets fixed, which is the only thing they care about. And in good news, cash is also a thing they have a lot of. The cost of their tech infrastructure is a blip on the radar compared to payroll, to the cost of their physical spaces.
- threeseed 3y ago
  I assume from this comment that you've never worked in the enterprise. Because (a) major decisions like choosing a mainframe are not made by tech managers and (b) every company is built around vendor lock-in. Who do you think companies like Atlassian, Oracle, Salesforce etc sell to ?
  - paleotrope 3y ago
    It's a little off to think that a mainframe was "chosen". Software and the companies that write it and support it "chose" the hardware for you.

ohgodplsno 3y ago

>What does Paypal, Klarna, or even maybe Amazon give up by not using mainframes? 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.

svennek 3y ago

Remember inertia goes both ways. As soon as you have a large system "in the cloud" or otherwise "distributed" (also only in your shed). 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.

filleokus 3y ago
I agree, it's obviously very hard to compare transaction rates, and I also agree that I have hard time seeing companies currently using mainframes recouping the cost of migrating. If it works, it works. But. > Rewriting your system to a mainframe architecture is equally as expensive. There was a new bank mentioned in this thread that actually started using mainframes from scratch, but other than that I've never heard of any "modern" fintech (or really any) company introducing mainframes. Organisations actually rewriting functioning systems TO mainframe must be almost never heard of (in the last 10-20 years at least). If System Z, Cobol and DB2 are so obviously superior, why are so many successful new competitors in industries where they are the norm in older companies choosing to not use them? I'm not saying banks should rewrite their stuff in node.js (or deno - even better of course), it makes sense for them to stay. I just have a hard time believing that mainframe systems are so technically impressive, to the point where some people claim it's almost impossible to build a similar system on non-mainframe technologies.

deleted 3y ago

[deleted]