5 ms·
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
by svennek 3y ago
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 transactions are created equally, the hardest usually have a set of requirements called ACID.
ACID in the classic RDBMS is not a random choice, but driven by real requirements of their users (the database user, i.e. applications in the business sense - and not the users as people).
The ACID properties are REALLY hard to do in scale in a distributed system with high throughput. Think of the rate of transactions in the bitcoin system (500k/day with many, many "servers") vs. visa (500M+/day) - the latter is basically driven by two (!) large mainframes (with 50ish km distance) the last I heard of any technical details.
None of the companies you mention need to have strict ACID, as nobody will complain if different users see slightly different truths - hence scaling writes is faily easy.
- ak_111 3y agolegacy 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."
- arethuza 3y ago"These industries dominate a specific market and have not always had a positive approach to innovative ideas" Google is itself starting to sound a bit like that!
- saiya-jin 3y agoWell this is Hacker's news, you label something legacy like code, its never a nice thing or showing some respect to product/creators, rather contrary. TBH its also the first time hearing about this term, its simply not common, not even here and much less in general population. And I have to strongly agree with OP, I couldn't care less about fate of FAANGs of these days, but I do care about those 'legacy' businesses tremendously. As for original topic - if it works for 3-4 decades, don't be the stupid guy and change it. Tremendous risk to core business with little to gain.
- ak_111 3y agoYour comment doesn't make sense, why in Hacker News should I show more respect to Walmart and JP Morgan rather than google or apple by calling the former legacy industry and the later big tech, and why are you so worked up about it? Relying on the existence of one vendor with highly unportable and unmaintainable code carries its own risk and my post is asking whether it justifies the cost.
- svennek 3y agoIt also gives you the opportunity to use their mainframes advantages to the very max. Not the "common feature set" but the very "best features" you can get out of your tech choice. I do the same, I have run PosgreSQL for more than 2 decades now and I don't care about portability to any other database, all of which I consider inferior (and yes, I do follow most of their releases).
- svennek 3y agoLegacy is mainly a marketing term for someone wanting a piece of an existing, big market. It also usually implies that you expect it to be closed down and replaced...
- handsclean 3y agoI’m not GP, but I found it funny because the term is misusing the word legacy. It doesn’t fit other usage of the word or the dictionary definition of the word. I didn’t look it up because I didn’t think to, it looks like a normal use of an adjective, not a term.
- deterministic 3y agoLegacy means highly valuable and proven. Non-legacy means unreliable and highly unlikely to ever make money. Legacy software runs the world. Without it western civilisation would collapse.
- filleokus 3y agoI 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.
- why_only_15 3y agoGoogle 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 agoVISA 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 agoSpanner does over 1B queries per SECOND (but your other point still stands of course)
- svennek 3y agoIf 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 agoGoogle 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.
- guidedlight 3y agoBoth BigTable and DynamoDB only support eventual consistency. That is a big asterisk in ACID for those technologies.
- why_only_15 3y agoI don't think that's true? Bigtable: https://cloud.google.com/bigtable/docs/replication-overview 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/developerguide/HowItWorks.ReadConsistency.html 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
- hulitu 3y agoI heard that mainframes have redundancy built-in. /s
- Spooky23 3y agoIt’s not a technical problem. IBM and whomever owns other “undead” platforms aren’t dumb, they price the stuff high enough to print money, but low enough to make it a poor return to migrate. In a big enterprise, the mainframes give CIOs leverage for other stuff too - they sell at high margin and IBM will “give away” or subsidize other services by moving money around in the backend.