Finance IT: The future of microservices, DevOps and the cloud in banking systems
Java Champion and JAX Finance advisory board member Peter Lawrey talks about what programming trends are penetrating the Finance IT sector, and shares his opinion on the speed of streams and Java’s development under Oracle.
JAXenter: What sort of changes are you witnessing in finance IT right now – and do you see buzzwords like cloud, microservices and DevOps playing a large role in this area in future?
Peter Lawrey: The buzz in fintech is still around performance and efficiency. In particular, IT developers are interested in cool new technologies but are looking to find way to justify their use to their managers. Many would like to migrate from Java 6 or 7 to Java 8 and see this as a big enough challenge.
While I don’t see financial institutions using external clouds like AWS as much as other industries, I believe they should be making more use of private clouds. Deploying services to new systems and even downsizing legacy systems is staggeringly harder than it should be. Clouds would be really helpful. A Bank can run their own cloud and still control the machines in use.
In the low latency space, virtual machines make your life much harder, but most services don’t need to have dedicated hardware.
I see the techniques developed around microservices really helping in Finance IT. I don’t see microservices as a way to kill your monolithic programs but rather a way to bring best practices to distributed systems. Most of the microservices solution come from the web space which are not as latency sensitive, but that doesn’t mean these techniques won’t help. It means you need microservices built on low latency infrastructure to reduce overhead. For this reason we see microservices in the micro-second space as our key push next year as a solution provider.
I see DevOps providing a greater role in the support of Big Data systems. In the past, the business development would talk business analysts who would talk to IT developers and they would hand over the system to operations staff. However, in the BigData space, the business is more likely to develop the algorithms and strategies using largely existing software, using very large qualities of data and they need a more direct relationship with the operations teams who manage the servers and data. These operations team need to have more development skills which is where DevOps staff are a good fit. In short, I expect to see a closer relationship between the business development and DevOps, without as much need for BAs or IT developers to write new code.
We are looking to offer a low latency microservice architecture where you can fork a running topology or system and upgrade or alter just a portion of it while your main system fork is still running. i.e. you have two copies of the system running in production but only one main fork is in use for talking to external systems. This would allow you to see how a new system will behave before committing to using it and let the code warm up. When you are ready, switch to this new fork as the main fork, leaving the old one running just in case. This allows you to do A/B testing, but with a trading or risk system with production data on production systems. We have much of the low latency infrastructure in place, and we are looking to develop the tools to do this in Java early next year.
Do you think the speed at which fintech startups are innovating is influencing the pace at which IT in larger banks is being developed?
Larger banks have a habit of developing IT systems from scratch, some times more than once. Higher management have long recognized this is as wasteful and expensive, however there hasn’t been much competition in vendors, meaning that an in-house solution could still be cheaper but also more focused on their specific requirements.
SEE ALSO: Agile banking needs a new core
Having more competition in the fintech market will not only provide more innovative solutions, but drive down costs to the point where it is more compelling to outsource software systems. This should not only save banks a lot of money but allow them to be more innovative in offering new services to their clients.
As both a Java and a StackOverflow champion, how would you see the difficulties of Lambdas – are they inherently confusing, as Heinz Kabutz argues?
For someone migrating from Java 7, they are at first very confusing. They are less confusing if you come from C# as they work very similarly. Lambdas and Streams are hard enough to read but even harder to get them to compile. The main problem is Type Inference.
This is both magical when it works, and frustrating when it doesn’t. If you haven’t found them confusing yet, you haven’t used them enough. Use them for a while, say 6 to 12 months, and you should feel you wouldn’t want to go back. In terms of adoption, I find they are easier than generics to really get your head around. In fact, one of the most common sources of confusion is how lambdas work with generics. Note: Generics in Java are eleven years old and they can still confuse.
A trick we have used to get lambdas to compile is to either write an anonymous class, or use the IDE to convert the lambda to an anonymous class, get the code to work before using the IDE to switch it back.
There’s also been some debate about the speed of Java 8 streams. Care to comment?
I have a whole talk on the subject: Low Latency in Java 8 at JavaZone In short, they can be a little slower to write, and to run, but not always. There are examples where it was either easier or faster. In one project we developed which went into production Nov 2014, we wrote 26,000 lines of code, 2,500 uses of
stream(), however only 3 uses of
parallelStream(). The latter was enough to use all the CPUs of the server.
When it comes to performance and low latency, it’s not how easy it is add code, but how easy it is to remove something which doesn’t need to be done which matters.
In terms of testing with
parallelStream(), it was easy to try it out with very little investment, when mean when we quickly tested it and it didn’t help we could remove it very easily. Too often there is so much invested in making code parallel, there isn’t enough time to test it and even if the tests are inconclusive, there has been too much invested to remove the parallel code.
Escape Analysis in Java 8 is very cool and will help you a lot of the time with little effort. It can place an object which would have been on the heap on the stack reducing the garbage produced. It is not very reliable and can take a long time to warm up. In our APIs we started relying on Escape Analysis and this was fine for simple examples, however it could easily fail as well. For this reason we ended up changing many of our APIs to use non-capturing lambdas which don’t create garbage in the first place. Note: There was Escape Analysis in previous versions but it didn’t do very much.
Do you think any of the features coming in Java 9 will be particularly helpful for programmers working on finance systems?
The feature I find more exciting is user defined intrinsics. This may or may not be in Java 9 and I hope with the delay this means it will be.
An intrinsic is a method which can be replaced with machine code inlined. This has a much lower overhead than using JNI. One of the reasons Unsafe was used so much is that many of it’s method are intrinsics and more efficient than what you could achieve using JNI to do the same thing. i.e. there was no other option. With user defined intrinsics, not only you won’t need to use Unsafe in many case, but you will be able to use machine code instructions previously not available. e.g. PAUSE, and XMM instructions.
Finally, the Java 9 release delay – are you unsurprised? Indifferent? Disappointed?
I wasn’t surprised. For me, the modules system made some sense for certain use cases, but most systems these days don’t mind “wasting” 100 MB of disk space. The module system will be useful, but no so existing. Even though Java 8 is pretty exciting there is still a lot of systems which haven’t migrated to it. I would prefer to see more features in Java 9 even if it takes a little longer.