Presentation: Building a Reliable Cloud Based Bank in Java

Yes, absolutely. Our aim and focus are much more long-term than many startups, and because of that, we are prioritizing the aspect of reliability. This goes to the heart of my talk. We want to guarantee stability because we will be around in years to come.

There were two key reasons that we chose Java.

Java is well-known and well-maintained. We're seeing a lot of problems currently in government and banking IT, where programs were written ages ago, back in the 70s and 80s, in languages that no one uses or maintains anymore. The people who work with those languages are retiring or dying off, and it's getting more and more difficult for these institutions to maintain their systems. When it comes to banking, we've got to think not only about where we're going to be in a year's time or five years' time, we've got to work out where the bank is going to be in decades' time. We’re thinking over these time scales because banking tends to move more slowly than other fields. So you need reliability to be there; you need to make sure that the bank is going to be there in the far future, which is what customers and regulators require. Customers want a guarantee that their bank will be there in five, 10, 15 years, and so on. So we need to know that we're going to have a pool of developers to maintain and improve the system in 'X' years' time. And Java looks like a good bet for that because it's been around for 20 years, so we have more confidence that it will be around in 20 years more than some other languages.

The other reason we use Java is that Java is very noisy when it comes to exception handling. You can easily generate exceptions and generate noise. We quite like that because it helps us monitor what's going on and helps us quickly identify where there's a problem so we can go in and fix it. That speaks again to reliability as the goal.

The main message of the talk is that you can build a system that is as reliable as banking requires which at the same time allows you to regularly push out new features to customers and deliver what they need.

The key takeaway in SF will be different from what it is in London. In London, you end up talking to financial institutions that really care about reliability. They want to make sure they don't destroy anything and so they're afraid to go forward to deploying many times a day. The message then is that you can deploy once a day while at the same time maintaining that reliability.

Tech companies in SF are more used to be able to deploy hundreds and thousands of times a day to production, you're used to this continual deployment pipeline. But what if you absolutely had to guarantee that everything worked? What if you absolutely had to guarantee that if a customer instructed a payment, it would definitely only go out once—not twice and not zero times? We have this additional challenge, but we still manage to meet it. We still manage to deploy reasonably consistently while at the same time having this increased reliability burden that you need in banking. So emphasizing guaranteed reliability will be more the message of the talk in SF.