Saturday, 1 September 2018

Poll - Biggest risk involve in Cloud Banking

Banks weigh risks, benefits of cloud migration. What is the biggest risk involve in migration from branch banking to cloud banking? Debate!


bike tracks

Wednesday, 18 July 2018

Achieving 100% uptime in sensitive financial services with Linufix containers




Long story short!

For those who are not familiar with the Linux container technologies, I highly recommend to search for LXC and Docker technologies. And for those familiar with chroot concept in Linux, I can give a shortcut: Docker container or LXC technology is the same as chroot in the sense that it provides OS level isolation but in addition it gives mnt, pid, user and network isolation plus dedicated hostname and dedicated shared memory. In fact container technologies enables us to achieve a virtual machine-like isolation at the kernel level and not at the hardware layer traditionally offered by VMs. And in short, it means heaps of opportunities to optimize resource usages and reduce costs. In this post I assume the reader have basic knowledge of Linux but anyhow I will try to discuss the technology through a simple context.

First the problem should be acknowledged though; For anyone who has worked with commercial financial services such as core banking software, payment switch, or CMS systems, it is not that hard to recall the moments that the business undergoes fines for SLA violation ($1000  per minute in a company that I know) or receives frustrating client complaints. In fact this issue is kinda bolder in financial services rather than in other business sectors and the reason is of course obvious.

Anyway, before jumping into the proposed topology and technique, I show you how to make a container out of already running stable Linux host.

Create and build a base docker container from a running Linufix host (applicable to other Linux distros too)

- Open a terminal
- Run following bash commands

$ sudo debootstrap linufix-corebank-container bionic > /dev/null 
$ sudo tar -C linufix-corebank-container -c . | docker import - linufix-corebank-container 

In the above example, you created a container from your already running host Linux in few minutes. Of course you need to first install packages such as debootstrap and docker. Use apt-get to download and install the packages or search for updates in their host repositories.

You can properly test your docker by running "docker run" command. In the following example I show you how you can run a ssl server in your newly created container and connect to it from outside:

- Run the following bash command in your terminal

$ sudo docker run linufix-corebank-container /bin/bash -c "ip addr show && openssl s_server -psk 1234567890 -accept 172.17.0.3:8081 -cipher PSK-AES128-CBC-SHA -nocert"

Now in another machine execute following command:

$ openssl s_client -connect 172.17.0.3:8081 -psk 1234567890 

Note that 172.17.0.3 is the interface IP address of my own Linufix container and in order to confirm it I added a "ip addr show" command as part of the container execution so that one can see what is the docker interface IP address. You can run following command to understand your docker's IP:

$ sudo docker run linufix-corebank-container ip addr show

Problem

Now that we learned how to create a container from our service, let's consider a generic view of our proposed network topology:



As depicted in the illustration above, we often have a dynamic loadbalancer in front of our service stack. But there are plenty of networks out there that even do not deploy a loadbalancer that I highly recommend to do so. There are a few free open source loadbalancers such as HAProxy that comes with plenty of features including dynamic discovery which we need for our solution.

The traditional problem in financial services is that once the system admins are updating a node's software, that node is out of order for a while and so the traffic is distributed between remaining nodes (quality is degraded). Even worst, if the network comes with no loadbalancer and therefore relies on a single point of failure (often we see this even in big banks!) then the system is completely out of order until the node gets updated and comes to the life again.

Solution

Check this out:
As depicted above, the first thing that we do is to create a container for our service and deploy it in node(s). This is called Current Production in the above figure. Then when it comes to transition time, in the same node, we deploy a new container that includes all the updates. Now for a while both old and new containers work in parallel and the loadbalancer balances our the traffic between them. Zero downtime achieved! At the last step of the transition when we already know that the new container works fine, we can bring down the old container and reach to Post Transition as shown above.

All above operational steps are fully supported in Linufix. Linufix ships with all necessary software and components that deliver loadbalancing and container management. 

Conclusion

As we move forward with heaps of next generation technologies, end user customers can't really accept underperforming services in financial sectors. Although it might be cumbersome for banks and financial institution to say goodbye to their COBOL era, but they have to embrace it sooner before it's too late. For many banks around the world, upgrading to the latest technologies can be similar to taking an tasteless painful drug but for them that might be the only significant cure!