How hot is Kubernetes? Even traditional banks are transforming to embrace it

Source: techrepublic.com

Kubernetes has become a standard infrastructure API with a gravitational pull that vendors like Red Hat, Mesosphere (now D2IQ), and Pivotal have been unable to escape. If you’re in the business of enabling enterprises to build applications, you’ve got to support Kubernetes. Period

For those application-building enterprises, Kubernetes adoption has remained somewhat aspirational, with a 2018 CNCF survey finding 40% of enterprises running Kubernetes in production. Among those 60% not yet on the Kubernetes train you’d expect to find risk-averse banks. As an industry vertical, unlike their hedge fund and trading cousins who constantly push for an edge, traditional banks don’t like crossing technology chasms unless they have to. These are people who still run their ATM networks on 30-year-old mainframe technologies.

Kubernetes is changing that. I had heard about ING embracing Kubernetes, but that use case followed other early adopters among the DevOps community. Containers and orchestration can be great for improving CI/CD, but would a traditional bank run its real business on such a young technology? As a sign of just how hot Kubernetes has become, Italy’s biggest bank not only would, but is.

It’s fascinating to see why, and the cultural change that Kubernetes demands.

Digital transformation the Italian way

Banca Intesa Sanpaolo, formed in 2007 through the merger of Banca Intesa and Sanpaolo IMI, is the largest bank in Italy and one of the largest in Europe with a $34 billion market cap. Based in Turin, the bank has more than 5,000 branch offices and serves some 19 million customers in a dozen countries across Europe and the Middle East, as well as supporting an international presence in more than 25 countries worldwide.
 
In 2018, the bank launched a strategic digital transformation initiative it called Digital Architecture Reengineering Works Through Innovation. The strategy was to embrace a microservices and container architecture, and migrate from monolithic to multi-tier applications. The goal was to accelerate development cycles, shrink application footprints for more flexibility, and improve scalability and reliability. The bank’s IT group was transforming itself into a software company based on modern CI/CD practices. 

At the center of the initiative was the challenge of running containers managed by Kubernetes.

The bank first tested pilot container projects by running them on its legacy virtual machine (VM) infrastructure. Those pilots were successful, but the bank wanted to see if it could run Kubernetes and containers on bare metal. Could it take advantage of performance benefits and escape the overhead of paying for VM licenses too?

This didn’t promise to be a trivial decision, as bare metal and Kubernetes usually means DIY. Rather than build from scratch, Banca Intesa Sanpaolo turned to an appliance approach developed by Diamanti. The Diamanti system was a commodity x86 server appliance pre-loaded with plain vanilla Linux and Kubernetes but with cards added to overcome I/O challenges in networking and storage that can cripple Kubernetes deployments into production.

Strangling old-school apps

From a software perspective, this approach meant that the bank could stay focused on a Kubernetes and containers strategy. At the same time, the underlying infrastructure layer could also meet all of its requirements for storage and network virtualization with high performance levels to satisfy business unit SLAs. Diamanti’s management software gave the bank high availability across multi-zone and multi-site clusters with quality of service guarantees for different applications with different levels of business criticality.
 
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.
 
What kinds of applications did the bank want to run on microservices? From the start the team focused on two classes of applications: New and monolithic applications. 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.
 
Software development moved from a scenario where all actors insisted on a single pipeline, and where a single commit could fail a build and stall the development, test, and deployment process. That process shifted to one where each actor had its own stream of development for each dedicated component.
 
This change made life easier for operations in scaling the needs of the application team for their specific infrastructure. It was an elegant solution. Each component of the application relied on a dedicated container that could be scaled horizontally. By avoiding the domino effect of failure, reliability dramatically improved. The new approach also 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.

Dealing with residual challenges

While the shift to containers, Kubernetes, and a microservices architecture led to order of magnitude improvements in scalability, reliability, and speed of development and deployment, there were also substantial challenges for the bank to manage.

• Sizing: The first challenge came with accurately sizing the underlying infrastructure required to run the microservices architecture since it was based on a new paradigm. The rules the bank used in the past for traditional monolithic applications needed to be refined and changed. Microservice applications do not behave in the same way as monoliths, and they don’t consume the same amount of resources. There was a new learning curve that must be mastered.
• Processes: Making microservices work with the existing data center ecosystem is a fundamental change in the way the bank built and implemented the applications and provided the underlying infrastructure with resources. The team found that using a container platform together with the Diamanti technology was extremely useful in this process, but from the application point of view the new paradigm, however simple for greenfield applications, will require a lot of work for the thousands of applications that the bank intends to rewrite as microservices.
• Cultural challenges: The concept of DevOps and differences in mentality between developers and operations required a new way of thinking about creating and deploying applications. 

It’s this last point that is easiest to gloss over but hardest for any enterprise to make work in practice. Banca Intesa Sanpaolo is well on its way, but it’s a journey that will take time and patience to successfully navigate.