Java in the cloud for financial services

More than 50% of enterprise application are written in Java

When Accenture announced the winners of its FinTech Innovation Lab London at the beginning of the year, most of the entries were what have become familiar at innovation-oriented events – totally new ways to integrate social media into retail online banking services, for instance.

Only one firm of the seven isn’t working on a bank-to-customer product or service .

Dublin-based Waratek describes itself as “a Java virtualisation company”, with a product called Cloud VM for Java. At this stage there are proof of concept installations at “a couple” of different banks.

And it reckons it has a solution for one of the problems facing Java applications – how to continue using the myriad Java applications that are scattered throughout firms, in the modern computing environment of virtualised servers and cloud architectures.

Firms are in a difficult situation with this: with so many applications, rewriting the code is not an option, but neither is continuing to throw expensive hardware at the problem in order to get more capacity.

Going back to basics, Java is a 17 year old language, originally developed by Sun Microsystems, and now owned by Oracle. It is pretty much the most ubiquitous programming language in use. “There is no other language in which so many enterprise applications are written – somewhere above 50% of enterprise apps are actually written in Java, ” says Howard Tolman, director of Waratek’s UK operation.

Being 17 years old isn’t really the problem: the issue is that in those days, compute power was relatively inexpensive. “It was one server for one app,” says Tolman. “In these days of virtualisation and cloud you are talking about running lots of different Java apps on multiple servers. Java will take memory from other applications, and if they are written by different programmers they may have unpredictable issues.”

The end result is that people tend to put java apps in containers, isolating them, but this is a far from ideal solution.

“In reality, there are still some gaping holes in the server virtualisation story, and one of them is Java-shaped,” wrote John Abbot in a 451 Research report last year. “You still can’t run multiple Java apps on top of a single Java virtual machine, and that leads to some gross inefficiencies.”

The isolation capability exists in environments like VMWare and Azul, but each Java app is still running in isolation, which leads to the second half of the problem: the lack of dynamic configurability.

It is a reasonable solution, but if you are running, for example one application in one virtual container, it is not the most efficient. When you set the parameters of the JVM, you have to allow for all of that, and you can’t’ then optimise the server. “You have to set it up at the extreme level, not the optimum level, so that it doesn’t degrade,” says Tolman.

An application or routine that uses variable resources over time – perhaps only a fraction of the system for most of the time, but half the available resources at particular times – will have to be set up with the resources that it uses at the maximum period.

What the Waratek approach does is to allow multiple Java Virtual Containers to work within a single JVM. That means instead of having one JVM with one application on it, you can have, say, 16 applications in individual Java Virtual Containers, all isolated from each other and completely discreet on a single JVM”, says Tolman.

“This brings a further degree of integrity to the applications and on top of that you only need one version of Java to drive the whole set of applications. If, example, those applications had Apache Tomcat, or WebSphere or WebLogic supporting them as an application server, you could have just one instance of it. What this does is massively increase the application density. Whereas before you had to set memory capacity with a view to the maximum, you can now plan, knowing that not all of the 16 applications are going to be at maximum at the same time.”

This also leads to a considerable reduction in maintenance cost, claims Tolman. “Within a traditional JVM you can’t do that on the fly, so if you have to change the parameters of an application you have shut the whole production system down, which is why you are sending teams of people in at the weekend, because that’s the only way to do it,” he says.

A lot of this comes down to a concept called multitenant elasticity. The first part is easy – multiple different applications hosted on the same server, or sharing the same resources, and is a common characteristic of cloud environments. While multitenant has become a feature of mainstream cloud and enterprise computing solutions, existing Java application servers don’t deliver multitenant support to cloud-based applications, for the reasons outlined above.

The elasticity part comes from being able to use dynamic configuration, with applications being able to demand resources as and when they are needed.

With multitenant elasticity, you can manage individual containers dynamically. “You can increase or decrease memory, for instance, without having to shut things down, you can allow for bursting, and all sorts of things,” says Tolman.

With this approach, IT managers can now square the circle – preserving investment in existing code, increasing application density on existing hardware, and removing the need to shut down the production systems for maintenance are all good things in themselves.

And because the applications are running natively, it is possible to migrate relatively easily. “You can shift an application from its existing environment into a Java Virtual Container and it will boot up and run without any changes,” says Tolman. “There will, of course, be configuration issues, but the cost savings justify that interim work.”

“The actual cost savings are very dramatic,” he says. “The management problems of running these systems are difficult enough on their own, so you save in management overhead, but if you look at it in terms of where you can save, you are exploiting massively underutilised server capacity. The more you can drive up server utilisation the more you can see in direct operating cost saving for IT.”

Moreover, it means that IT services can be more quickly provisioned, which is another benefit arising from the same capability.

“Banks have huge Java estates, generally speaking, that they can’t really get rid of – we are talking about a reduction by a massive percentage. If you look at the money that is being spent on hardware, third party software licences, electricity and carbon footprints – costs are increasing across the board,” says Tolman.

“At the end of the day this is what it comes down to – no-one is going to use a bank because it uses particular JVM, but they are going to use a bank that charges them less because they have lower IT costs.”