Hacker News Reader

Comment by _Understated_ | Hacker News Reader

I've worked contracts in UK banks for a number of years now. Nothing on the mainframes but I know some of the guys that do work on those and, despite the constant stream of flavour-of-the-month tech that we talk about constantly in places like HN, the mainframes work well and will not be replaced any time soon.

The dev cycle for releases and whatnot is incredibly long due to testing and, lets be honest, fear, in case something breaks but when it comes to battle-tested technology, mainframes and DB2 are right up there.

I do know of some code that's over 40 years old and still runs at the core of one of the big banks...

MongoDB, despite its capabilities, is... an odd choice imo! Not trying to second-guess but if I was in that meeting I would have certainly raised an eyebrow.

Good luck to them.

View on HN

Really depends what apps the databases are supporting. Big banks have thousands of internal apps (as opposed to client facing services) to support workflows, business analysis and management reporting. Might be a fine choice for some of that stuff.

The problem with 40y old code, is where I work we had to pull engineers from retirement to make a regulatory change. In 10y, I am not sure we will have that option.

I’d wager it would cost a whole lot less to train devs up on the existing system than to rewrite. Without understanding the existing code, you’re going to have a tough time replacing it.

I’ve read that in some cases the initial requirements and source code was lost, so making changes to the existing software becomes a reverse engineering problem in addition to a “language proficiency” problem.

This seems like a hiring failure to me, not a tech failure. I've been hired on several occasions to work with a language I had zero prior exposure to, and while there is of course some ramp-up time I managed just fine and eventually became skilled and knowledgable in those languages.

I don't see why COBOL, mainframes, or whatnot would be any different. Perhaps the ramp-up time would be a bit higher, but most skilled programmers will manage. I actually wouldn't really mind working with any of that – I just never had the opportunity.

I work for a large consultancy - we have large teams dedicated to COBOL, and I believe others (e.g. CapGemini, TCS) do too.

I wouldn't claim they are any good, just mentioning that grads are being trained in COBOL.

My prediction is something will go horribly wrong, then they will go "see, we tried modern tech and it fucked us over", and they will commit to seeing their code and tech stack turn a century old before considering any updates.

I read the article and couldn’t figure out what they were actually putting in mongo. If it’s their core processing/ledger then that would be very surprising. But banks have dozens of different systems, some of them would actually almost be suited to Mongo, and some of them have rather loose SLAs. Unless I missed something, the article didn’t really make that clear.

There's another thread on the homepage right now about Crux [0], which is a database designed specifically to be able to operate downstream from multiple legacy systems using bitemporal indexes to stitch everything together. This pattern is very common in banks e.g. for calculating and reporting on risk positions.

I expect you're right that this story is purely about using Mongo for downstream systems.

[0] https://news.ycombinator.com/item?id=23493163

That thought did occur to me as well but, in taking the article at face value it's most certainly some core aspect of their banking systems at the very least...

If they are intent on replacing the mainframe then, imo, MongoDB would be a bad choice but who knows... the new, challenger banks don't use mainframes.

Any ideas what some of the challenger banks are using? I've not seen any examples beyond Nubank (~$10B valuation), who have bet big with Datomic: https://www.youtube.com/watch?v=VYuToviSx5Q

Also: https://www.datomic.com/nubanks-story.html

Oracle has a banking platform that they mostly only succeed in selling to smaller banks. I don't know if that would count as "challenger" though.

Not sure exactly but any job ads I've seen for the likes of Monzo and Starling talk about backend engineers that have a deep knowledge of CI/CD and you don't do that on a mainframe.

Also, Monzo are heavy users of Kubernetes, so again, no mainframe. [0][1]

Starling use AWS and GCP [2]

In addition, the cost of entry of a mainframe system is a high bar when you can spin up a server on Azure in seconds and deploy code to it in a handful more seconds and then scale it to the heavens in yet just a few more seconds... all for less than the hourly cost of the IBM salesman.

I've yet to see any jobs that mention mainframes, Cobol or the like.

[0] - https://monzo.com/blog/2016/09/19/building-a-modern-bank-bac...

[1] - https://www.8bitmen.com/an-insight-into-the-backend-infrastr...

[2] - https://blog.container-solutions.com/starling-how-to-build-a...

> Not sure exactly but any job ads I've seen for the likes of Monzo and Starling talk about backend engineers that have a deep knowledge of CI/CD and you don't do that on a mainframe.

The part of the bank that handles core processing is going to be a very small portion of their engineering team. Kube and DevOps ads don’t provide any hints about how much they might rely on DB2, COBOL, etc...

The article gave me the impression it might have been for some sort of CRM-like system. I don't know if it would be even possible to replace DB2 with Mongo, the consistency guarantees are too weak. Banks are accountable to the central bank in every jurisdiction in which they operate, I wouldn't see them getting that past one single central bank, let alone 60+ of them.

If you remove the specific technical choice from mind (a great engineering team can move mountains with any data layer, something I've also learnt working in numerous contract teams at multi-billion dollar companies) - the simple act of rewriting and consolidating huge amounts of data/infra (and stacks) can yield enormous gains.

I will be tracking their technical reporting more closely over the next year.

"I will be tracking their technical reporting more closely over the next year."

Just curious, but what specifically do you mean? ie. I'd love to keep an eye on this also, but have no idea where to find these types of (public) reports.

> ... the simple act of rewriting and consolidating huge amounts of data/infra (and stacks) can yield enormous gains.

What's a good example of this working out well?

I can also suspect they did it on purpose to loose some data by accident. What could possibly go wrong.

Reply on news.ycombinator.com