About the client:
Our client is a mid-sized commercial bank with an on-premise mobile banking platform. The bank operates in one of the CEE countries, servicing individuals, SMEs, and corporates. It has half a million customers.
Mobile banking channel overview:
Among bank’s digital channels, the most crucial one is mobile banking due to the following:
- rapidly growing number of active mobile clients (>300 thousand),
- high number of user log-on (~30 per month, ~3x more than to Internet Banking),
- critical importance for payments (mobile payments and 3D secure approvals for card transactions).
By the market, the bank’s mobile application is considered innovative, can serve retail and company users, and supports various types of payments, including instantaneous interbank transfers, e-commerce payments, Apple Pay / Google Pay, 3D Secure authorizations, and non-card ATM withdrawals.
The mobile banking platform was built and launched a few years ago with a modern technology stack (native mobile apps in Kotlin & Swift), microservice architecture, Oracle database, and managed with OpenShift.
The platform is installed on-premise, and hardware infrastructure must be ready to cope with monthly usage peaks (end-of-month payment days) and seasonal peaks (like Black Friday, post-Christmas Sales, and Summer Sales).
Bank’s CTO identified the following challenges of mobile platform maintenance:
Challenge: oversized infrastructure and high maintenance costs.
Costs of expanding infrastructure
On-premise infrastructure must be ready to handle the rapid growth of users and several usage peaks during the year.
Also, it needs to be highly reliable as it’s crucial for payments. Therefore, it requires the necessary capacity reserve consumed only several times a year.
Costs of maintenance of resources for various environments
With on-premise infrastructure, the bank has to invest in and maintain other various hardware environments.
Examples are development, staging, UAT, pre-production, production, and reference (copy of production to replicate errors) environments.
Each environment comprises hardware that must be maintained, refurbished periodically, and/or purchased to support new initiatives.
Cost of the database license
A significant cost for the IT budget is an annual license fee for database software vendor. Bank is considering migrating it to an open source alternative.
Solution:
The remedy for the challenges described above was migrating the platform to the cloud equipped with scalable and high-availability database provided as a service and charged for the actual use of computing power.
An additional benefit would be the out-of-the-box access to automated tools allowing building automated CI/CD processes. Due to the lack of internal experts in this field, the bank sought an experienced advisor to help the banking team with the platform migration and make necessary code tuning.
After analyzing prices and benefits, the bank selected Google Cloud as its provider and hired us as their certified Google Cloud partner, requesting us to:
Our goal: to advise, lead, and implement the migration process.
provide advisory services to IT Department
act as implementation partner
lead the whole migration process
We identified the following tasks to perform the mobile banking platform cloud migration:
use Google Kubernetes Engine
as replacement for currently used OpenShift
use the native Google Cloud database service Cloud SQL for PostgreSQL
to reduce costs related to database license
plan of data migration to PostgreSQL
Cloud migration step by step:
To migrate to GKE, we had to tune the application and run the necessary tests:
- Adaptation of the mobile banking back-end to Kubernetes
- Integration with Google Cloud native services like Pub/Sub
- First test run launch of the mobile banking platform on Kubernetes
- Development and configuration of mature CI/CD pipeline
- Preparation of the required environments in Google Cloud (test, stage, production)
- Test launch of mobile banking on GKE with E2E tests, performance tests, and dimensioning for production
- Configuration of secured ingress/egress traffic and integration with 3rd services outside the public cloud
- Switching traffic from the on-premise environment to Google Cloud
To start using Cloud SQL for PostgreSQL, we performed the following tasks:
- Preparation and verification of Liquibase changesets
- Test launch of the system on a local environment with a local PostgreSQL database
- Specify dimensioning for Cloud SQL
- Data migration from Oracle to Cloud SQL for PostgreSQL on test environment
- Performance tests and database tuning
- Test migration of production database
- Migration of production database
To start using Cloud SQL for PostgreSQL, we performed the following tasks:
- Configuring Cloud SQL for a preproduction environment
- Data migration and then validation of the migration results
- Test launch of mobile banking with Cloud SQL database
- Performance testing and KPI verification
- Test configuration of backup policies, recovery tests
After positive test results, we repeated the migration on the production environment with the actual data:
- Configuring Cloud SQL for the production environment
- Data migration and then validation of the migration results
- Performance testing and KPI verification
- Configuration of backup policies, recovery tests
- Switching traffic of the system to Cloud SQL database.
After the GO decision of the CTO, we built a joint team with the bank’s specialists and started to follow the prepared plan. It took us took three months to implement the cloud successfully.
Result:
Bank now has total flexibility on the infrastructure capacity usage
- maintaining its high availability
- limiting costs of maintenance of numerous environments
Google Cloud is responsible for services linked with
- database (SQL Cloud)
- Kubernetes cluster (GKE)
- asynchronous communications
- security patches
Fully automated release management and entire CI/CD
In addition, decreased potential of human error risks and improved software development quality
