5 ms·

I'd read this article and something about it bothered me, took a while to put my finger on it. To me creating a back end banking system using a load of softwar

I'd read this article and something about it bothered me, took a while to put my finger on it. To me creating a back end banking system using a load of software that's very new and still very much developing is a risky move. Once they're in production bank back ends tend to be around for a LONG time (in my experience in UK FS there were a load of old back-end systems that were maintained out of necessity as they were too expensive to re-write and the product they supported was still in use) To me banking back-end systems should be boring from a tech perspective. Use well known components where the limitations and downsides are well known, and also if it were me I'd use components that I could get a support contract for. You don't want to be relying on open source support at 3am on a Sunday when you hit some bug or other and the FCA is breathing down your neck to get your transactions processed in a timely manner.

mataug 10y ago
Or have some kid discover a memory allocation bug and fake a couple of thousand pounds into an account.
- MichaelBurge 10y ago
  I'm not saying it can't happen, but double-entry accounting will usually detect it and the ACH system* will usually let you reverse it. * Or whatever the UK equivalent is.
collyw 10y ago
"Large internet companies like Amazon, Netflix, and Twitter have shown that single monolithic codebases do not scale to large numbers of users". Strange that because banks have been using relational database technologies for that task for years.
- threeseed 10y ago
  Yes and many are trying to move away from them because of the cost. You are aware that Teradata servers cost in the order of 30K per node and support costs god knows how much. Any internet company wouldn't even make it past day one if they need to sink a few hundred thousand just to get started.
dsr_ 10y ago
At 3 AM on a Sunday, you discover a critical bug in a library provided by a third party. Commercial support: send email. You get an automated message back with a ticket number. Around 6:30 AM you get a call from Delhi that satisfies the 4 hour response SLA, and the support analyst says that they will look into it. At 11 AM you get a request for a dump and certain logs, some of which you had already sent them... Open source support: after getting zero google results, you look through the source code while running a debugger. It takes you two hours to find the place where it makes an assumption that a signed variable will never be negative, an hour to test your fix, and five minutes to send a patch to the mailing list. It is coming up on 6:30 AM, and you conference in the two people who need to approve emergency changes in order to get that approval. (This is a bank. You can't unilaterally make a production code change.) Everything is deployed before 8 AM.
- ebiester 10y ago
  It all depends on how much you are willing to pay for that support. From friends' experiences, Microsoft and IBM support can be very very good for the right price. That said, I know at least some financial institutions use their fair share of open source tools. They're often best of breed.
- saiya-jin 10y ago
  while it may be true in some banking places, in others you would hit many walls with this kind of argumentation, or even bugfixing. many banks are very conservative in decisions, and IT department is no exception
- afarrell 10y ago
  Your open source support case is 100% true if you know the language it is written in and the debugging tools. If not, 3am is not a good time to learn it. So for something at the heart of your business, choose a tech which has a community you trust behind it, whether that community is a longstanding FOSS community like Postgres, a company earning money through a closed-source embargo, or a well-developed internal team.
- threeseed 10y ago
  I have quite a bit of experience with commercial database support. You are missing a few steps. Normally it goes for India for a few hours where they rattle off something that is in the knowledge base. Then when that doesn't work it goes to the next tier which is some support person in the US who does exactly the same thing. Then finally you end up with a support engineer who is finally technical and will usually do a screen share to walk through a solution. But if it's a bug you will have to wait for an actual product engineer who will finally start looking through code. I've seen this process take days. And yet people are acting as though the big RDBMS vendors are somehow a good fit ? Crazy.
jessedhillon 10y ago
Because the article talks about all these technologies on a basis that appeals to engineering sensibilities -- ease of development, tolerance to failure, latest hotness, etc. Many fewer words are spent explaining these technical decisions from a perspective that considers the bank's strategic interests. Without much relating it specifically to the needs of a bank, there's not much to separate it from any other company's explanation of their tech stack.
jomamaxx 10y ago
I have to concur with this. Starting with a 'team of 3' and building a fairly fancy system with a lot of open-source 3rd party solutions ... making all kinds of assumptions about cost, scale etc. - this is worrying. In finance and banking, I think that 'simplicity' 'reliability' etc. are the key issues, and it probably should feel boring. I can't imagine that the 'cost of servers' is going to be the key issue, especially since these things are pretty cheap these days. When you look at how much a startup invests in various things ... I'm not sure that server cost is an issue for anything but entities like Netflix etc. wherein you have serious scale. Messaging startups like Kik have 200M users and I don't think they are that fancy, granted, it's not messaging.

mataug 10y ago

Or have some kid discover a memory allocation bug and fake a couple of thousand pounds into an account.

MichaelBurge 10y ago
I'm not saying it can't happen, but double-entry accounting will usually detect it and the ACH system* will usually let you reverse it. * Or whatever the UK equivalent is.

collyw 10y ago

"Large internet companies like Amazon, Netflix, and Twitter have shown that single monolithic codebases do not scale to large numbers of users". Strange that because banks have been using relational database technologies for that task for years.

threeseed 10y ago
Yes and many are trying to move away from them because of the cost. You are aware that Teradata servers cost in the order of 30K per node and support costs god knows how much. Any internet company wouldn't even make it past day one if they need to sink a few hundred thousand just to get started.

dsr_ 10y ago

At 3 AM on a Sunday, you discover a critical bug in a library provided by a third party. Commercial support: send email. You get an automated message back with a ticket number. Around 6:30 AM you get a call from Delhi that satisfies the 4 hour response SLA, and the support analyst says that they will look into it. At 11 AM you get a request for a dump and certain logs, some of which you had already sent them... Open source support: after getting zero google results, you look through the source code while running a debugger. It takes you two hours to find the place where it makes an assumption that a signed variable will never be negative, an hour to test your fix, and five minutes to send a patch to the mailing list. It is coming up on 6:30 AM, and you conference in the two people who need to approve emergency changes in order to get that approval. (This is a bank. You can't unilaterally make a production code change.) Everything is deployed before 8 AM.

ebiester 10y ago
It all depends on how much you are willing to pay for that support. From friends' experiences, Microsoft and IBM support can be very very good for the right price. That said, I know at least some financial institutions use their fair share of open source tools. They're often best of breed.
saiya-jin 10y ago
while it may be true in some banking places, in others you would hit many walls with this kind of argumentation, or even bugfixing. many banks are very conservative in decisions, and IT department is no exception
afarrell 10y ago
Your open source support case is 100% true if you know the language it is written in and the debugging tools. If not, 3am is not a good time to learn it. So for something at the heart of your business, choose a tech which has a community you trust behind it, whether that community is a longstanding FOSS community like Postgres, a company earning money through a closed-source embargo, or a well-developed internal team.
threeseed 10y ago
I have quite a bit of experience with commercial database support. You are missing a few steps. Normally it goes for India for a few hours where they rattle off something that is in the knowledge base. Then when that doesn't work it goes to the next tier which is some support person in the US who does exactly the same thing. Then finally you end up with a support engineer who is finally technical and will usually do a screen share to walk through a solution. But if it's a bug you will have to wait for an actual product engineer who will finally start looking through code. I've seen this process take days. And yet people are acting as though the big RDBMS vendors are somehow a good fit ? Crazy.

jessedhillon 10y ago

Because the article talks about all these technologies on a basis that appeals to engineering sensibilities -- ease of development, tolerance to failure, latest hotness, etc. Many fewer words are spent explaining these technical decisions from a perspective that considers the bank's strategic interests. Without much relating it specifically to the needs of a bank, there's not much to separate it from any other company's explanation of their tech stack.

jomamaxx 10y ago

I have to concur with this. Starting with a 'team of 3' and building a fairly fancy system with a lot of open-source 3rd party solutions ... making all kinds of assumptions about cost, scale etc. - this is worrying. In finance and banking, I think that 'simplicity' 'reliability' etc. are the key issues, and it probably should feel boring. I can't imagine that the 'cost of servers' is going to be the key issue, especially since these things are pretty cheap these days. When you look at how much a startup invests in various things ... I'm not sure that server cost is an issue for anything but entities like Netflix etc. wherein you have serious scale. Messaging startups like Kik have 200M users and I don't think they are that fancy, granted, it's not messaging.