Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why hasn't the cloud killed the mainframe?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#51

Post by filleokus »

eastern wrote: post #45
why_only_15 wrote: post #31

Earlier quoted context omitted.

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

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.

Spanner does over 1B queries per SECOND (but your other point still stands of course)

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#53

Post by jbergens »

taubek wrote: post #2

I would says "vendor lock-in or even legacy code". It seems to me that the systems that use mainframes have business continuity and stability as main goal. If it works there is not sense in migration. I think that for systems that use mainframes money is not the issue and on top of that migration costs would be huge.

I know that some of them tried to rewrite large systems but failed. You are right that it is not just a money issue since they could spend hundreds of millions of dollars on the rewrite and then basically scrapping it.

It shows that they did want to switch but it was harder than they thought.

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#54

Post by ohgodplsno »

ak_111 wrote: post #50
threeseed wrote: post #40

Earlier quoted context omitted.

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…

Not so sure, experienced tech managers are also very wary of vendor lock-in and tech debt which mainframes give you in spades.

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.

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#55

Post by [deleted] »

filleokus wrote: post #21
svennek wrote: post #3

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…

[deleted]

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#56

Post by why_only_15 »

guidedlight wrote: post #41
why_only_15 wrote: post #27

Earlier quoted context omitted.

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.

Both BigTable and DynamoDB only support eventual consistency. That is a big asterisk in ACID for those technologies.

I don't think that's true?

Bigtable: https://cloud.google.com/bigtable/docs/replication-overview

> When using replication, reads and writes to the same cluster are consistent, and between different clusters, reads and writes are eventually consistent. If an instance does not use replication, Bigtable provides strong consistency, because all reads and writes are sent to the same cluster.

DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

> Both tables and LSIs provide two read consistency options: eventually consistent (default) and strongly consistent reads > Eventually consistent reads are half the cost of strongly consistent reads

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#57

Post by homeslike »

dusted wrote: post #46

I can't think of any valid arguments for moving anything important away from a well understood and proven-reliable system.

in the case of mainframes the main reason would be that nobody wants to learn cobol anymore and maintainers of legacy code are litarally dying out.

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#58

Post by smokefoot »

supermatt wrote: post #15

You 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…

The word mainframe is often used ambiguously. In my experience it could mean:

System Z - as I understand it, this is descendant from IBMs earliest computers like System 360. Typically apps are written in COBOL, PL1, tied together with JCL. “Newer” apps use DB2, but there are older non-relational databases as well.

System P - an IBM alternative server architecture based on the Power chipset. I think these mostly run UNIX, but I’ve never been hands on.

AS400 - technically an IBM minicomputer, but similarly esoteric with a bespoke OS and some nifty functionality for business apps (very SQL centric).

HP Tandem - traditionally used in high availability transaction processing applications.

Others? I think most of the other surviving old stuff is basically UNIX

Typically people are thinking of System Z. I think both the inertia and scalable ACID explanations are relevant. That said, I’m not sure how DB2 on System Z compares to say Oracle RAC.

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#59

Post by threeseed »

ak_111 wrote: post #50
threeseed wrote: post #40

Earlier quoted context omitted.

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…

Not so sure, experienced tech managers are also very wary of vendor lock-in and tech debt which mainframes give you in spades.

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 ?

Re: Ask HN: Why hasn't the cloud killed the mainframe?

#60

Post by svennek »

filleokus wrote: post #51
eastern wrote: post #45

Earlier quoted context omitted.

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.

Spanner does over 1B queries per SECOND (but your other point still stands of course)

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

Post reply on HN