The Bank Had 3,000 Applications. The Shortcut Was a Different Floor.

At a large bank, the most dangerous sentence may be “we can move it later.” Intesa Sanpaolo had more than 3,000 in-house applications when it began a strategic modernization effort in 2018. The aim was familiar: replace unwieldy monoliths with smaller services and release software more often. The overlooked question was where those services would live, how they would find their data, and what would happen when a machine failed.

The bank first tried Kubernetes on its existing virtualized infrastructure. Those pilots worked. But a pilot is permitted to be charming; production has to be boring. The bank wanted bare-metal compute, high availability across sites and predictable service for applications with very different levels of importance. That meant joining storage and networks to a new application architecture without making every team build its own bridge.

Diamanti was the bridge. The company’s platform brought container networking, persistent storage and cluster operations into a more integrated package. In the bank’s account, two of its ten most business-critical applications were among the more than 120 already running in the new microservices architecture. The number matters because this was not a laboratory demonstration dressed up for a sales meeting. It was a gradual move into production, beside thousands of applications that still had to function.

The container is the easy part

Kubernetes is good at placing and replacing containers. The trouble begins when a container cannot simply disappear. A bank account, an invoice queue or a PostgreSQL database has a history. When a workload moves, its state must move with it; when a node fails, the records must remain available. The application also needs an address, bandwidth and a way to recover across zones or sites. Those requirements tend to arrive in separate product brochures and on the same operations team’s desk.

Diamanti’s original bet was to take that work seriously enough to design around it. Founded by engineers including Jeff Chou, Gopal Sharma and Amitava Guha, the company emerged publicly in 2016 with a container appliance. Its founders had worked on enterprise infrastructure before Kubernetes became a boardroom word. Diamanti says it contributed a FlexVolume plugin and storage and network scheduler extensions to the open-source Kubernetes community that year. It was selling a commercial system, but it also wanted the underlying orchestration to understand data and network needs.

“Change processes now take weeks to release a new build versus months under the old system.”Intesa Sanpaolo case study

That line is more revealing than an IOPS benchmark. The bank changed the software itself, using a “strangler” approach: new features were built as services beside old applications until the old structure could be retired. Development streams became parallel rather than one shared pipeline in which a single commit could stall everyone. Diamanti did not write the bank’s applications. It supplied infrastructure that could support the new rhythm, including storage and network services, multi-zone clustering and quality-of-service controls. The speed came from the combination of architecture, process and machinery.

Figures reflect Diamanti’s published Intesa Sanpaolo case study, not a current count.

Three products for one awkward question

Diamanti now divides its answer into two principal layers. Spektra is the management plane: a console for multiple Kubernetes clusters, application catalogs, access controls, observability, migration and disaster recovery policies. Ultima is the data plane, providing container-native storage and networking, persistent volumes, replication and backup. Ultima Enterprise is software; Ultima Accelerator adds a hardware appliance with I/O offload for workloads where latency and throughput justify it. GroundWork Monitor extends the portfolio into monitoring of physical, virtual and cloud infrastructure.

The division explains Diamanti’s place in a crowded market. AWS, Google and Microsoft offer managed Kubernetes in their clouds. Rancher and other tools manage clusters across environments. Storage specialists address persistent data. Diamanti tries to make those concerns one buying conversation, particularly for enterprises running a mix of on-premises and cloud systems. Its appeal is strongest where a workload is stateful, regulated or performance-sensitive. A simple stateless website may have less reason to pay for such an integrated stack.

There is a commercial logic, too. Spektra has a freemium tier; its enterprise version is sold with a support subscription. The company offers trials for other products and sells hardware appliances through partners including Dell and Lenovo. It says its channel handles sales of its hardware and software portfolio. Public pages describe subscription terms and trials, but a buyer needs a quote for a real deployment. Any cost comparison would have to include infrastructure, licensing, support, staff time and the price of a failure. A lower server count alone is not a bill.

The price of the shortcut

Diamanti raised $12.5 million in a 2016 Series A, $18 million in a 2017 Series B and $35 million in a 2019 Series C. The final round was described as fuel for global sales and a hybrid-cloud roadmap. That is a substantial bet on a stubborn problem: enterprises do not merely need containers; they need systems that let ordinary teams run containers on a Tuesday, survive a Thursday outage and explain the architecture to an auditor on Friday.

What did the bank pay? Its case study does not disclose a contract value or total migration cost. What it does show is what failed first conceptually: the old model for sizing and operating monolithic applications did not fit microservices. The bank had to learn new resource patterns, change development processes and handle the cultural friction between developers and operations. Virtualized pilots got the project moving, but the production target called for different infrastructure. That sequence is worth more than a neat before-and-after chart because it leaves the difficult work in view.

Diamanti’s own examples should be read with similar care. Its website describes an international banking deployment that went from 15 servers to three, and it advertises more than one million I/O operations per second per node in certain configurations. Those figures are interesting, but they describe particular workloads and test conditions, not a universal outcome. The company’s genuine distinction is architectural: storage, network and operational controls are treated as parts of the Kubernetes decision rather than chores delegated to the next meeting.

What another team can borrow

A reader does not need to buy Diamanti to learn from the bank. The useful pattern is to begin with one real application, map every dependency it has on storage and networks, and measure its behavior in production-like conditions. Then migrate incrementally: add new functions as services beside the old application, keep data protection explicit, and make each team’s release path as independent as the system permits. Test a failure before calling a design resilient.

1. Pick a stateful workload, not the friendliest demo.
2. Record latency, recovery time and operating effort before changing platforms.
3. Decide who owns data movement, access policy and support across sites.
4. Expand only when the next application can repeat the process without heroics.

The method has limits. A small team with one cloud and mostly stateless software may be better served by a managed Kubernetes service and a conventional database. A company unwilling to change release practices will not become faster because its servers are faster. And no integrated platform makes a legacy application portable by decree. The bank’s lesson is quieter and more useful: changing the floor made a new working rhythm possible, but people still had to learn how to walk on it.