July 18, 2017
How do you fit a core banking system into a few containers, Part 2: The how
By: Jose Quaresma

In Part 1 of this series, my co-writer (Amine Boudali) and I introduced the Core Banking Program (CBP) at Nordea and shared the motivations behind the start of our journey to getting Temenos’ core banking application into a containerized platform, Red Hat OpenShift.

In Part 2, we’ll explore easing the pain points discussed in Part 1, how we did it and new challenges that arose.

#DevOps enables the #DigitalBank of future – Our @josequaresma details guiding principles in a new blog post.

How did we do it

CBP was one of the pioneers in using and establishing the proof of concept for the usage of the Red Hat OpenShift platform at Nordea, originally called dPaaS for “development Platform-as-a-Service”.

This proof-of-concept started in summer of 2016. We joined because we saw the opportunity to test how the Core Banking Application would behave in a containerized environment, which we hypothesized could provide us with the ability to increase speed, flexibility and scalability of the platform.

Five people, divided into two teams, worked for six months, one focused on setting up the infrastructure, the other on fitting the Core Banking Application in the platform.

During this period, we focused on getting the application up and running in the containerized platform without big changes to the architecture nor the technology stack. We believed this approach would be enough to ease the pain points (see below).

A CBA project (or environment) in OpenShift is composed of three containers: Oracle Database, Oracle WebLogic, and Oracle Service Bus. The Oracle Database container includes the persisted Core Banking data. The Oracle WebLogic container is where the T24 application runs and it is connected to the Oracle Database container.

In the final container, we have the OSB services that provide (most of) the integrations between T24 and the external systems. In the OpenShift environments, that integration to external systems is, in fact, using Service Virtualization, enabling us to provide integrations from and to the Core Banking application without the need of the real systems.

Easing the pain

As we discussed in Part 1, there are pain points to address before starting our journey into a containerized platform.

Below you can see the outcomes resulting from coupling the T24 Core Banking Application and the OpenShift container platform.

Pain points Easing the pain
Long environment provisioning time Environment provisioned in 1 hour
High number of short-lived environments Easier to provision/delete environments.
Better lifecycle management
Complex deployment orchestration requiring downtime Simpler deployment (only one container)
Live deployment
Lack of full control over all environment configuration Infrastructure as code
All in same repository
Integration to a high number of development and test environments Service Virtualization
Feedback time to developers and testers needed to be shortened More frequent deployments
Time Travel capabilities in test environments

New Challenges

One of the main lessons we took from this transition to a containerized platform is the mindset shift from, to borrow Bill Baker’s analogy, treating your servers like “pets” to treating them like “cattle.”

One of the advantages with this new mindset is that it further motivates both the development and operations teams to have the infrastructure configuration as code.

If it is not under version control and it requires some manual setup (something we want to avoid), then the teams end up with an unsustainable amount of manual work every time a new container is created.

As you might imagine having an application server or a database in a container can make it pretty heavy. 

They do perform adequately, but having such heavy containers means that it takes more time to build and load them than one would like, not allowing us to take full advantage of a containerized platform. This is something that we will be looking to improve in the near future.

Another challenge that we have faced in this initial phase of the journey relates to the fact that making such a transformation involves changes connected to people, processes and tools.

We have experienced firsthand how challenging it is to balance these and to know which ones to focus on at different phases.

For example, we successfully got the Core Banking Application up and running in OpenShift, but then not all the teams in the program were aware of the platform. For those who started using the platform, we should have made it clearer from the start the strengths and limitations of such a setup.


What’s next

One of the next steps in this exciting journey will be to further improve the environment provisioning time (with a special focus on the database load time) and to work with teams to raise their knowledge of the platform and to incentivize them to contribute with any necessary changes to the infrastructure configuration.

We will also start experimenting with some alternative infrastructure solutions: T24 is also supported in JBoss, so it might be worth exploring that alternative and see what kind of results we get; we will also experiment with running the database in other middleware rather than Oracle Database.

We will continue to push the containerized Core Banking application further and will now be focusing on its performance, stability and compliance. We are happy with the journey so far and excited to continue on this path. We promise to keep you updated!

If you want to watch the talk, you can find it on YouTube here:


Popular Tags

    More blogs on this topic



        COMMENTS (0)




        Your Data Privacy

        By providing your e-mail address, you agree to the terms
        outlined in our privacy statement associated with
        commenting on the site. Your e-mail address will not be
        used for promotional marketing purposes.

        Change the CAPTCHA codeSpeak the CAPTCHA code