Traditional banks who still run their ATM networks on 30-year-old mainframe technologies are changing the way it runs the business. But would a traditional bank run its real business on such a young technology? Yes, Kubernetes is changing that.
Kubernetes has become a standard infrastructure API for vendors like Red Hat, Mesosphere (now D2IQ), and Pivotal. If you’re in the business of enabling enterprises to build applications, you’ve got to support Kubernetes. Period.
We would take a case study of digital transformation of an Italian bank
One of the largest banks in Italy and one of the largest in Europe with a $34 billion market cap. It has more than 5,000 branch offices and it serves 19 million customers across Europe and the Middle East, as well as an international presence in more than 25 countries worldwide.
In 2018, the bank launched a strategic digital transformation initiative to re-engineer its architecture through innovation. The strategy was to migrate from monolithic to multi-tier applications by using microservices and container architecture. At the center of the initiative was the challenge of running containers managed by Kubernetes.
The goal was to accelerate development cycles, shrink application footprints for more flexibility, and improve scalability and reliability.
The bank wanted to know if it could take advantage of performance benefits by implementing Kubernetes and containers and escape the overhead of paying for VM licenses?
Ditching the old-school apps
From a software approach, the bank embraced Kubernetes and containers strategy backed by an underlying infrastructure layer that could meet all of its requirements for storage and network virtualization with high-performance levels to satisfy the SLA of business.
The bank turned to an appliance approach, Today the bank runs more than 3,000 applications. Of those, more than 120 are now running in production using the new microservices architecture, including two of the 10 most business-critical for the bank.
All new applications were immediately built with a microservices approach.
For existing, monolithic applications, the bank followed the so-called Strangler Application pattern. As new functionality was added to any legacy application, each new feature was added as a new microservices mini-application. The legacy and the microservices applications ran in parallel until eventually they were migrated into one new application at which point the old monolith was “strangled” at its end of life.
With this solution, each component of the application relied on a dedicated container that could be scaled horizontally. The new approach simplified automation, eliminating a lot of manual steps on both the developer and operator side of rolling out a new application. This led to much better code quality overall.
Even though there were advantages the bank had to go through challenges in adjusting to the new learning curve, defining the infrastructure, and even the cultural changes done through DevOps.
The advantages
The shift to containers, Kubernetes, and a microservices architecture led to improvements in scalability, reliability, and speed of development and deployment.
Microservice applications don’t consume the same amount of resources as monolithic and banks could save heavily omg onion on the underlying infrastructure.
When microservices was made to work with the existing data center ecosystem, there came a fundamental change in the processes the way the bank built and implemented the applications. With DevOps came a cultural change as well
Urolime and Kubernetes
Looking for Kubernetes Consulting?
Urolime provides the right Kubernetes consulting services for better quality and efficiency of software development and infrastructure management. Leave your worries to us; we’ve got the best & cost-effective solution for you.
