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

While Kubernetes is not yet in production in most companies, the largest bank in Italy shows the way forward.


Image: shansekala, Getty Images / iStockphoto

has become a standard infrastructure API with a gravitational attraction from which providers such as Red Hat, Mesosphere (now D2IQ) and Pivotal have not been able to escape. If you are in the business of allowing companies to create applications, you must support Kubernetes. Period.

For those application creation companies, the adoption of Kubernetes has remained somewhat aspirational, with a 2018 CNCF survey that found that 40% of companies run Kubernetes in production. Among the 60% who are not yet on the Kubernetes train, I would expect to find banks with risk aversion. As an industry vertical, unlike its hedge fund and commercial cousins ​​that constantly push for an advantage, traditional banks do not like to cross the technological chasms unless they have to. These are people who still run their ATM networks in 30-year mainframe technologies.

SEE: How to build a successful career as a DevOps engineer (free PDF) (TechRepublic)

Kubernetes is changing that. I had heard of ING hugging Kubernetes, but that use case followed other first users between
and orchestration can be excellent for improving CI / CD, but would a traditional bank conduct its real business with such young technology? As a sign of how hot Kubernetes has become, Italy's largest bank would not only do it, but it is.

It is fascinating to see why and the cultural change that Kubernetes demands.

Digital transformation in 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 capitalization of $ 34 billion market. Based in Turin, the bank has more than 5,000 branches and serves some 19 million customers in a dozen countries in Europe and the Middle East, in addition to supporting an international presence in more than 25 countries worldwide.

In 2018, the bank launched a strategic digital transformation initiative that it called Digital Architecture Reengineering Jobs through Innovation. The strategy was to adopt an architecture of microservices and containers, and to migrate from monolithic applications to multiple levels. The objective was to accelerate development cycles, reduce application footprints for greater flexibility and improve scalability and reliability. The bank's IT group was transforming into a software company based on modern CI / CD practices.

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

SEE: Digital transformation: a CXO guide (special feature ZDNet / TechRepublic) | Download the free PDF version (TechRepublic)

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

This did not promise to be a trivial decision, since bare metal and Kubernetes generally means DIY. Instead of building from scratch, Banca Intesa Sanpaolo turned to a device approach developed by Diamanti. The Diamanti system was a basic x86 server device preloaded with Linux and simple Kubernetes, but with added cards to overcome the I / O challenges in networks and storage that can paralyze Kubernetes implementations in production.

Strangling old-school applications [19659022] From a software perspective, this approach meant that the bank could stay focused on a Kubernetes and container strategy. At the same time, the underlying infrastructure layer could also meet all of its network storage and virtualization requirements with high performance levels to meet the business unit's SLAs. Diamanti administration software gave the bank high availability in 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 these, more than 120 are now running in production using the new microservice architecture, including two of the 10 most critical businesses for the bank.

SEE: Hybrid cloud: a guide for IT professionals (free PDF) (TechRepublic)

What kind of applications did the bank want to run in microservices? From the beginning, the team focused on two kinds of applications: new and monolithic applications. All new applications were created immediately with a microservice approach.

For existing, monolithic applications, the bank followed the so-called throttle application pattern. As new functionality was added to any legacy application, each new feature was added as a new microservice mini application. The legacy and microservice applications were run in parallel until they were finally migrated to a new application, at which time the old monolith was "strangled" at the end of its useful life.

The software development moved from a scenario in which all the actors insisted on a single pipe, and where a single compromise could fail in a construction and stop the development, testing and deployment process. That process changed to one where each actor had their own development flow for each dedicated component.

This change facilitated the life of operations by escalating the needs of the application equipment for your specific infrastructure. It was an elegant solution. Each component of the application was based on a dedicated container that could be scaled horizontally. By avoiding the domino effect of the failure, reliability improved dramatically. The new approach also simplified automation, eliminating many manual steps in both
and the operator side of implementing a new application. This led to a much better code quality overall.

SEE: To be a microservice: how smaller parts of larger applications could remake IT (ZDNet)

Dealing with residual challenges

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

  • Sizing: The first challenge came with accurately sizing the underlying infrastructure required to run the microservice architecture, as it was based on a new paradigm. The rules that 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 do not 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 applications and provided resources to the underlying infrastructure. The team discovered that using a container platform together with Diamanti technology was extremely useful in this process, but from the point of view of the application, the new paradigm, however simple for new applications, will require a lot of work for thousands of applications that 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 the creation and implementation of applications.

It is this last point that is the easiest to overlook but the most difficult for any company to do the job in practice. Banca Intesa Sanpaolo is on its way, but it is a journey that will take time and patience to navigate successfully.

See also

For More Updates Check out Blog, Windows Softwares Drivers, Antivirus, Ms Office, Graphic Design Don’t Forget to Look Our Facebook Page Get Into Pc like us & follow on Twitter- @getinpc

Please Note: This content is provided and hosted by a 3rd party server. Sometimes these servers may include advertisements. does not host or upload this material and is not responsible for the content.