Kubernetes meets Open Bank Project

Kubernetes offers a further abstraction by allowing you to express the services which your software provides. This might be a simple database service or it might be the APIs that you’re offering to your customers.

For example, the Open Bank Project offers over 550 APIs specific to the banking industry, and by bringing OBP to Kubernetes, this increases the adoption possibilities of these Open Banking APIs.

We are already starting to see the benefits of Enterprise partners using the Kubernetes solution as a faster way to deploy and become familiar with the Open Bank Project and its APIs. It makes deployment quicker, repeatable, and to a certain extent the deployment is self-documenting.

Just like any software system, banking systems need to scale depending on load rising and falling over a given period. For banking software this is especially important for managing cost and customer experience.

Of course, managing cost is a major influence for any of these systems and the ability to provision only the resources that are required has been the goal of cloud computing systems since its inception. Scaling back these nodes automatically brings the system cost back down.

With Kubernetes, we can scale up for deployment based on CPU utilisation. This takes advantage of the auto scaling capabilities built into Kubernetes, keeping in mind it is made possible by cloud provider implementations. Thus, for example the ability to deploy more API instances as the load increases and scale back down when it decreases. This allows cost to be managed as well, only deploying the resources which are required.

It’s also possible to account for spikes in traffic while having a reserved number of nodes always available. This, for example is useful as a buffer for responding to a spike in traffic and increasing nodes just before the system reaches capacity.

Then there’s data. People care if you lose their data, especially bank related data.

Kubernetes has the concept of PersistentVolumes, and PersistentVolumeclaims. Blob storage, Network filesystem providers have written drivers conforming to the Kubernetes PersistentVolume specification.

Persistent volumes often reside outside of the Kubernetes deployment, this means if you delete your deployment or if your pods fail you can safely be assured that your persistent data is still there.

Implementations vary however so do check that your cloud provider operates in this way as you may need to modify settings to make sure that the persistent volumes are not deleted when your deployments are deleted.

Persistent volumes are tied to PersistentVolumeclaims, this is another way by which persistent volumes may get deleted depending on your cloud configuration. The best day to durability of course check this configuration and verify.

Remember, if you don’t have a tested backup, you don’t have a backup!

Would you like support in deploying the Open Bank Project on Kubernetes? If you’re a financial institution or governmental organisation and are looking to innovate faster with open banking technologies, TESOBE can support you in your open banking deployments.

If you’re looking to build an integration with your core banking system and would like to experiment with Kubernetes deployment configuration please contact us here.