Migrating to Spring Boot in an investment bank

In this interview, Robert Kapała and Piotr Gwiazda recount how GFT Poland successfully conducted a migration of legacy systems to Spring Boot for a top-tier investment bank – a major success for the team. The software and java experts discuss the benefits of using Spring Boot, share best practices for teams to introduce and explain what it takes to develop systems in the financial sector.

You’ve successfully conducted a migration to Spring Boot for a major investment bank?

Robert Kapała: Indeed, we have transformed a system that used multiple different, inconsistent application servers into a simple solution based on independent modules, built on basis of Spring Boot and Java 8.

Piotr Gwiazda: Overall, the migration took nearly 15 months, but this was not our main goal for the project. We were in the process of delivering a new part of the system and in the meantime, the migration became a necessity. However, it turned out to be a major success, which allowed working on both the old and the new system simultaneously. It involved transferring two parts of the system into a Java 8 environment and components based on Spring Boot. The first part ran on Java 6 and a WebLogic server. The second one – on Java 7 and a JBoss server.

Robert: This opened a world of possibilities: it simplified our entire infrastructure and accelerated deployment in production – from several hours to one.

Piotr: Exactly, although let’s note that what you mean here is the entire release process – deploying itself now takes only a few minutes.

Robert: It accelerated our local deployment: on WebLogic, we were not able to deploy applications locally – on Spring Boot it is possible. Thanks to this migration, our regular, everyday work became significantly quicker.

What was the reason behind choosing Spring Boot?

Robert: Spring Boot enables us to easily create independent, self-sufficient microservices. They can be deployed as a single executable .jar file. It eliminates the need to maintain application servers as a runtime environment – the web server is an integral part (you can choose between Jetty, Tomcat or Undertow). The server is updated exactly like any other dependency.

Thanks to these functionalities, Spring Boot allows us to focus on the application itself, rather than on everything else around it.

Piotr: The main aspect of Spring Boot that determined our decision to implement it was its flexibility. We faced the following challenge: we were given code that dates back even to 2002, and, at the same time, we have completely new modules created by us – how do you run all of this on a single platform? We analyzed existing dependencies, libraries and frameworks, as well as the acquired elements of code. Some solutions were based on very old or even exotic frameworks. Their migration was out of the question, as somebody was still using them. Moreover, it was impossible to launch these frameworks on a modern JEE container. We came to a conclusion that Spring Boot was flexible enough to let us replace the default components and hide the whole level of complexity of these legacy applications under a certain layer of abstraction. The number of available starters for Spring Boot made this very easy.

Robert: At that point, Piotr asked the entire team: “What direction do we want to take? What platform should we choose?” Personally, I began researching Spring Boot and watched several presentations by Josh Long – you really need to watch them to understand how useful they are. So one could say that there was a certain degree of hype in here. Therefore, in order to avoid making hasty technical decisions, we decided to prepare demo versions, in order to see how Spring Boot worked on a smaller, showcase example. Another step for the entire team was to try questioning this decision – everyone tried to find weak points. And if such were encountered – we would read more, learn more and make sure that we had a proper understanding of this technology. This way, the list of doubts was cleared completely and we were certain that it was the correct approach.

Piotr: We eliminated application servers very quickly – for three main reasons:

• An application server is a piece of middleware that you need to support. In an ideal world, application servers will be delivered and supported, while the development team will only run
  code on them. But we do not live in an ideal world and nobody wants to support them – they become a sort of mutual, unclear responsibility. This in turn leads to disagreements between operations and development teams. And if nobody wants to support them, why not get rid of them altogether?
• Significant increase in the amount of work — the task could turn out to be impossible in terms of costs – e.g. due to running certain libraries on JBoss. I’m speaking about this from experience with different versions of JBoss and application servers.
• And finally, the obvious reason – licensing costs. And this is non-trivial, both in the case of WebLogic and JBoss. Naturally, this was an argument that was important for the client.

The migration you completed took place in a large investment bank. In terms of software development, this is certainly a very specific environment.

Piotr: Correct, it was not a 1:1 migration that would amount to: “Let’s remove the code from the server and launch it on Spring Boot”. The system had to be divided into smaller modules and migrated piece by piece. This is the fundamental challenge when working for an investment bank – we cannot say: “listen, we’re stopping the world, halting development and doing the migration”. We often work on critical applications – but on the other hand, we cannot afford stagnation in development. If a certain functionality is needed, it must be introduced. This is why smooth operations are of the essence – everything must take place without a longer halt in the system itself.

Robert: Investment banks are certainly a distinctive environment. And although it is often the case that the software is not really the latest, on the other hand it tends to be free from errors, being used long enough to eliminate all bugs. Hence when migrating a given application, we must be certain that it will continue working – that we will not alter its behavior. Its functioning may be critical for the bank.

Piotr: Generally speaking, you must have an open mind. The fact that a given system operates in an unusual way may actually result from the fact that another, equally old, and equally peculiar application has worked with it perfectly – and for many years. Not everything that looks suspicious will necessarily turn out faulty – it is very likely that someone is simply using a given solution in a specific manner.

When it comes to software, there is a widespread conviction that huge banks are full of archaic, inefficient solutions, and that they remain reluctant towards adoption of new technologies.

Piotr: Here I’d like to disprove a certain stereotype. There are obviously many legacy systems in an investment bank. However, these systems earn money, and regardless whether someone enjoys new technologies, the main goal behind these systems is to earn money, not to play with new technologies. That is why we need to switch to the following mindset: for an investment bank, software means cost, not value. Like your electricity bill. You must pay for it in order to do your job – you will not make it without electricity, just like you will not make it without software. The goal for software is to satisfy business needs – and if we find arguments in favor of reducing these costs, they will always be good arguments.

This is why the notion of “efficiency” works so well in an investment bank. I’m not just talking about efficiency of systems, but about smooth introduction of changes, as well as cost-effective delivery of new functionalities. And this is the stereotype that I’d like to challenge – even though the banking industry is not a sector that will ask us to introduce the latest technologies (although it has some areas in which it will), it is certainly not opposed to them. You must simply provide good arguments and prove that these new technologies deliver authentic gains.

In this perspective, was it difficult to convince the client to migrate to Spring Boot?

Piotr: Actually no, because we presented strong arguments. The client was aware that certain applied technologies were out of date, or even on the brink of unsustainability. Some licensing problems appeared at the same time and it was clear that a solution was needed. Our role was to push it even further – instead 4 of moving from one legacy technology to another legacy technology – and face the same problems in the near future – we proposed a solution that would allow active development of the acquired application as a living piece of software, rather than a relic of the past.

Robert: The key was to gain the client’s trust. And as we know, trust is of fundamental significance in this industry. As Piotr mentioned, the entire migration process was conducted piece by piece. We moved a single fragment of the system, established that it worked, and only then we moved on. In order to gain the bank’s trust, we had to make sure that the entire process was supported from the beginning to the end. A situation where in the case of an error, developers would not deal with it anymore was absolutely out of the question. We needed to make sure that the new version would function properly in production.

• Go step by step
  First of all, make sure that a given module is migrated as a whole, and avoid conducting other operations during this stage – this may end up really badly. If we are migrating a given fragment, we always make sure that everything runs properly, and only then we proceed to the next step.
• Migration is priority
  During migration, when examining a given module, we might be tempted to introduce some changes or improvements. Let’s avoid this: we should do the minimum work necessary for migration. Improvements should be done during a later stage – when we are already operating on Spring Boot and the first module is in production. Introducing changes becomes both easier and safer.
• Risk
  Always remember about risk. This notion is as important as profit. When conducting a migration, we not only should, but we must separate infrastructure releases from functionality releases! Hence when delivering infrastructure migration – we do not introduce any functional changes. When adding functionalities in a given version – we do not tackle infrastructure. Confusing these processes is a recipe for disaster.
• Rollback
  A good rollback plan is always worthwhile. It may turn out that – especially in a place like an investment bank – the systems are interwoven tightly, that they are numerous, and that we must be ready for a situation in which one of them refuses to cooperate – even if everything looked fine at the beginning.
• Testing
  Developing automatic tests should also be a priority. For example: we had to work on a module that had no such tests at all. Before the migration, we decided that the first step would be to write tests. It turned out we hit the bull’s eye. The same technology used in a new runtime environment produced slightly different results. Thanks to our tests, we were able to track all problems and make sure that the module operated exactly like it did before the migration.
• Difficult beginnings
  You should realize that migrating the first module will take a bit more time than the rest – we must deal with a certain learning curve: we learn new technologies, discover the entire infrastructure and so on. However, completing the initial stages thoroughly will pay off quickly, and migrating subsequent modules is far easier.
• Cherish your success!
  When you introduce a new functionality that is visible on the screen, the users will say: “Yeah, we’re happy with that, this makes our work easier, we like it” and so on. Unfortunately, in the case of infrastructural changes, nobody pays attention to that. This is because good changes in this area are transparent. The development team should however celebrate its success in a visible way. If I remember correctly, we had a photo of our success cake appear on Twitter, with a decoration saying “Goodbye WebLogic & Java 6!” – this was a nice way of showing the world that we actually moved forward, that something was changed for the better.

8 month of hard work and finally we migrated 3 servises to Java8 and springboot #gft #springboot pic.twitter.com/3UcwFOlGz1

— Robert Kapala (@robertkapala) 1. September 2016

Here we’d like to thank everyone in our team – because it was not only our work, but of the entire team. Even if someone did not contribute to changes in the code aimed at the migration, the rest of the team handled functional changes. Many thanks to: Piotr Kosmowski, Bartek Stasikowski, Paweł Możdżonek, Paweł Korus and Michał Wasiak!

Piotr Gwiazda & Robert Kapała