This article is based on reporting originally published by TechRepublic (2019). The Banca Intesa Sanpaolo case study is attributed to that source.
Kubernetes Becomes the Unavoidable Infrastructure Standard
Kubernetes has evolved from an ambitious Google open-source project into the dominant infrastructure API for container orchestration. Its gravitational pull proved so strong that major platform vendors—Red Hat, Mesosphere (now D2IQ), and Pivotal—were each compelled to build Kubernetes support into the core of their offerings. If your business helps enterprises build and run applications, supporting Kubernetes is no longer optional.
For enterprises themselves, adoption has accelerated sharply. A 2018 CNCF survey found that 40% of enterprises were already running Kubernetes in production—a figure that seemed remarkable at the time. Among the remaining 60%, you would reasonably expect to find traditional banks. As an industry vertical, retail and commercial banks are notoriously conservative about technology risk. These are institutions that still run ATM networks on mainframe architectures that date back decades.
Yet Kubernetes is changing even that calculus. ING had already made headlines with its Kubernetes adoption, but its DevOps-forward culture made it an outlier. The more telling proof of Kubernetes’ maturity came when Italy’s largest bank—one of the most traditional financial institutions in Europe—decided not just to pilot containers and Kubernetes, but to run its most business-critical systems on them.
Digital Transformation the Italian Way: Banca Intesa Sanpaolo
Banca Intesa Sanpaolo was formed in 2007 through the merger of Banca Intesa and Sanpaolo IMI. It is the largest bank in Italy and one of the largest in Europe, with a reported market capitalization of approximately $34 billion at the time of this case study. Headquartered in Turin, the bank operates more than 5,000 branch offices and serves around 19 million customers across a dozen European and Middle Eastern countries, with an international presence spanning more than 25 countries worldwide.
In 2018, the bank launched a strategic initiative it called Digital Architecture Reengineering Works Through Innovation. The strategy had a clear technical direction: embrace a microservices and container architecture, and migrate away from monolithic applications toward multi-tier, independently deployable services. The stated goals were to:
- Accelerate software development and release cycles
- Reduce application footprints for greater flexibility and resource efficiency
- Improve scalability and reliability across business-critical systems
- Transform the IT group into a software-oriented organization built on modern CI/CD practices
At the center of this initiative was Kubernetes, chosen as the container orchestration layer to make all of it work in production.
Bare Metal Over VMs: A Deliberate Infrastructure Choice
The bank began by running pilot container workloads on its existing virtual machine (VM) infrastructure. Those pilots succeeded, but the team wanted to evaluate whether running Kubernetes on bare metal could unlock additional performance and eliminate the operational overhead and licensing costs associated with the VM layer.
Running Kubernetes on bare metal typically means building and managing a significant amount of infrastructure plumbing yourself—particularly around networking and persistent storage, two areas where Kubernetes can be difficult to harden for production use. Rather than build that from scratch, Banca Intesa Sanpaolo adopted an appliance-based approach from Diamanti. The Diamanti system combined commodity x86 server hardware with plain Linux and Kubernetes, augmented by purpose-built hardware cards designed to address the I/O performance bottlenecks in networking and storage that often prevent Kubernetes from meeting enterprise production SLAs.
Strangling Old-School Monoliths
From a software architecture perspective, the Diamanti infrastructure allowed the bank’s teams to stay focused on Kubernetes and containers without getting buried in low-level infrastructure problems. The underlying platform met the bank’s requirements for storage and network virtualization with the performance levels needed to satisfy business unit SLAs. Diamanti’s management layer also provided high availability across multi-zone and multi-site cluster configurations, with quality-of-service controls to differentiate between applications with varying degrees of business criticality.
By the time this case study was published, the bank ran more than 3,000 applications in total. Of those, more than 120 were running in production on the new microservices architecture—including two of the bank’s ten most business-critical applications.
Two Categories of Applications: New and Legacy
The team organized applications into two tracks:
- New applications were built from the ground up using a microservices architecture. No monoliths were allowed to be started.
- Existing monolithic applications were migrated incrementally using the Strangler Application pattern.
The Strangler pattern works as follows: rather than attempting a risky big-bang rewrite of a legacy system, each new feature added to an existing application is built as a standalone microservice. The legacy monolith and the new microservices run in parallel. Over time, as more features are replaced by microservices, the monolith shrinks until it can be decommissioned entirely—effectively “strangled” out of existence.
This approach had measurable effects on development workflow. Previously, all development teams shared a single pipeline. A single bad commit could fail the entire build and stall the development, test, and deployment process for everyone. Under the new architecture, each team owned its own pipeline for its own component. Failures became isolated. Development velocity increased. Horizontal scaling of individual components became straightforward—each component lived in its own container and could be scaled independently without affecting the rest of the application. The domino-effect failure scenario was effectively eliminated.
The shift also simplified automation. Manual steps in the release process—on both the developer and operations side—were reduced significantly, and the improvement in isolation and testability contributed to better overall code quality.
Dealing with Residual Challenges
The improvements in scalability, reliability, and delivery speed were substantial, but the bank also encountered real and significant challenges in the transition. Three stand out:
1. Infrastructure Sizing
Accurately sizing the infrastructure for a microservices workload is fundamentally different from sizing for traditional monolithic applications. Microservices do not consume resources in the same patterns as monoliths—they tend to be smaller individually but more numerous, and their resource profiles can be harder to predict during initial planning. The bank’s existing capacity planning models needed to be rebuilt from scratch for the new paradigm. This represented a meaningful learning curve for both infrastructure and application teams.
2. Process Reengineering
Integrating a Kubernetes and microservices platform into the existing data center ecosystem required fundamentally rethinking how applications are built, deployed, and provisioned. The container platform and Diamanti technology helped, but the application-level transformation—particularly for the thousands of legacy applications the bank intended to eventually rewrite as microservices—represented a multi-year body of work, not a one-time migration event.
3. Cultural Change
This is the challenge most frequently understated in technology transformation narratives, and the hardest to solve with tooling alone. Adopting DevOps principles means changing the relationship between development and operations teams—how they communicate, how they share responsibility, and how they think about ownership of systems in production. In a traditional bank with deeply entrenched organizational structures, this kind of cultural shift requires sustained executive support, clear incentives, and patience measured in years rather than quarters.
Banca Intesa Sanpaolo was well into this journey at the time of this reporting, but the bank’s leadership acknowledged it as an ongoing process rather than a solved problem.
What This Means for Enterprise Kubernetes Adoption
The significance of this case study is not just technical—it is a signal about where enterprise software infrastructure was heading. If one of Europe’s most conservative financial institutions could migrate its most critical production systems to Kubernetes and microservices, the “it’s too immature for regulated industries” objection to Kubernetes had effectively expired.
The broader lessons from the Banca Intesa Sanpaolo experience apply to any large organization considering a similar path:
- Start with pilots, but plan for production from the beginning. Running containers on VMs first gave the bank confidence before committing to bare metal.
- The Strangler pattern works at scale. Incremental migration of monoliths, rather than big-bang rewrites, reduces risk and allows value to be delivered continuously during the transition.
- Infrastructure appliances can accelerate adoption. Using a pre-integrated Kubernetes appliance avoided a lengthy DIY infrastructure build and let teams stay focused on application modernization.
- Cultural transformation is the longest pole in the tent. Technology choices matter, but the organizational change required to make DevOps work in practice outlasts any single platform decision.
Kubernetes has moved well past the early-adopter phase. For enterprises still treating it as a future-state aspiration, the question is no longer whether to adopt it—it is how quickly they can afford not to.