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

Building a Bank with Kubernetes [slides]

community.monzo.com

Post reply on HN
Print view View original

101–106 of 106 posts

Re: Building a Bank with Kubernetes [slides]

#101

Post by riskable »

kchoudhu wrote: post #79
riskable wrote: post #58

Earlier quoted context omitted.

Man, it's like people think banks are special when it comes to IT. They're not! You have lots of extra regulations for sure but most of them are about retention of financial records . If a system isn't processing/storing financial records or "privileged" information nobody gives a damn. The "technology plan" is 99.5% about making or saving money. That remaining .5%? Yeah, that's compliance. Because that's all it cost…

If it's a computer in a bank and it touches risk, trading or treasury, it's fair game for the Fed auditor. So you tell me: what computer system of any import in a bank doesn't touch one of these three things?

Actually all systems are fair game to the auditors. If an auditor wants to see something they get to see it 99% of the time. End of story.

They really don't care about systems that don't process financial information! They don't care about your dev or qa environments. They don't care about your DNS servers or your switches or much else for that matter.

Regulators are 100% laser-focused on financial information and transactions. They want to see ledgers and logs and they want to see evidence that your systems prevent tampering. That's it.

There's no financial regulators that actually audit IT stuff. We probably should have them but we don't. The closest is the FFIEC but they only publish non-binding guidelines.

If you think the PCI-DSS matters to banks you're mistaken. Every year we audit ourselves and put the results in a filing cabinet somewhere. We have no obligation to show it to anyone and no one would hold us accountable for failing to be PCI compliant anyway.

Re: Building a Bank with Kubernetes [slides]

#102

Post by kchoudhu »

riskable wrote: post #101
kchoudhu wrote: post #79

Earlier quoted context omitted.

If it's a computer in a bank and it touches risk, trading or treasury, it's fair game for the Fed auditor. So you tell me: what computer system of any import in a bank doesn't touch one of these three things?

Actually all systems are fair game to the auditors. If an auditor wants to see something they get to see it 99% of the time. End of story. They really don't care about systems that don't process financial information! They don't care about your dev or qa environments. They don't care about your DNS servers or your switches or much else for that matter. Regulators are 100% laser-focused on financial information and tr…

My department's annual budget was in the 100MM+ region -- and this doesn't count surge resourcing used to deal with capricious requests from the feds. I have been asked about my dev and qa environments (and how they are firewalled from production systems) repeatedly. And yes, I have been asked about network architecture too. Penalties for non-compliance came in the form of significant financial penalties. It only got worse once Dodd Frank hit. Once securities of any kind are involved, shit gets real fast.

Re: Building a Bank with Kubernetes [slides]

#103

Post by pjbster »

riskable wrote: post #58
kchoudhu wrote: post #34

Earlier quoted context omitted.

>what really limits most financial institutions from embracing a lot more modern tech is their core systems of record AND the acceptance of said systems by their governing agencies. Let me put this even more bluntly: if your bank's technology plan isn't 99.5% about dealing with government regulation and maintaining core record integrity and auditability, you are not a serious player in the space.

Man, it's like people think banks are special when it comes to IT. They're not! You have lots of extra regulations for sure but most of them are about retention of financial records . If a system isn't processing/storing financial records or "privileged" information nobody gives a damn. The "technology plan" is 99.5% about making or saving money. That remaining .5%? Yeah, that's compliance. Because that's all it cost…

You know, it's strange: when I worked for an insurance IT dept. we were informed that strict adherence to an ITIL-certified release process was essential to keep us "within compliance with FSA regulations - we need to do this in order to continue trading".

From experience, said process cost waaaay more than 0.5% of the budget. Time and cost overruns, massive overhead in personnel and a drain on mental resources which should have been spent on actual release quality rather than an audit trail meant to convey "Certified" quality. All in all, I'd say 50% of the costs of IT delivery were spent in plodding through the checkpoints with much of the other half being consumed by the interest on 20 years of technical debt accrued as a result of those very same resources being misdirected in such regulatory endeavours.

I recognise than I'm far too cynical to see regulation as anything other than a shield against liability. It's simply too obstructive to contribute to actual quality improvement. On the plus side, it does keep about 50% of IT personnel in a job.

So I guess you can count me in with the lovers :-)

Re: Building a Bank with Kubernetes [slides]

#104

Post by agibsonccc »

elsonrodriguez wrote: post #94
agibsonccc wrote: post #7

Earlier quoted context omitted.

Disclosure: I mainly use DC/OS mesos myself. I've evaluated k8s for our use case and didn't find it was quite what we were looking for. Our customers and stack are mainly JVM based. We do on prem deployments not cloud where GCE is already doing pretty well. We also mainly work with the microsoft side of things (azure,enterprise stuff) Not convinced of this. Direct mesos and yarn integration with spark (not to mention…

> Many startups don't actually have big data stacks and prefer to use go based stuff (mainly because it's simpler). In that case k8s makes sense for that. Something to keep in mind is that golang's simplicity and performance is going drive an increase in big data tools written in go.

If those tools are around in 10 years I will pay attention.

Go has momentum. Hadoop has lasted longer than most startups currently using go.

Re: Building a Bank with Kubernetes [slides]

#105

Post by [deleted] »

alexandre_m wrote: post #60
agibsonccc wrote: post #7

Earlier quoted context omitted.

Disclosure: I mainly use DC/OS mesos myself. I've evaluated k8s for our use case and didn't find it was quite what we were looking for. Our customers and stack are mainly JVM based. We do on prem deployments not cloud where GCE is already doing pretty well. We also mainly work with the microsoft side of things (azure,enterprise stuff) Not convinced of this. Direct mesos and yarn integration with spark (not to mention…

What about running K8s on top of DC/OS? I find the idea of using Mesos as the resources scheduler much more interesting, especially for multi-tenancy where each tenant launch their own k8s cluster on shared infrastructure.

[deleted]

Re: Building a Bank with Kubernetes [slides]

#106

Post by agibsonccc »

alexandre_m wrote: post #60
agibsonccc wrote: post #7

Earlier quoted context omitted.

Disclosure: I mainly use DC/OS mesos myself. I've evaluated k8s for our use case and didn't find it was quite what we were looking for. Our customers and stack are mainly JVM based. We do on prem deployments not cloud where GCE is already doing pretty well. We also mainly work with the microsoft side of things (azure,enterprise stuff) Not convinced of this. Direct mesos and yarn integration with spark (not to mention…

What about running K8s on top of DC/OS? I find the idea of using Mesos as the resources scheduler much more interesting, especially for multi-tenancy where each tenant launch their own k8s cluster on shared infrastructure.

Yeah that is a great poin and something I want to look into if k8s is supported by our customers. Hence why I said I would be interested in seeing it evolve.
Post reply on HN