As the state of digital technology advanced, Multitude sought to preserve its legacy as a financial technology (Fintech) pioneer by building a solid technological foundation to meet rapidly changing customer and market demands. To turn its vision into reality, Multitude embarked on a two-year journey to transition from its legacy infrastructure to a cloud-native Kubernetes platform. 

“Given the scale of what we do, pretty much the only way to make this successful is going for and embracing the best practices and CNCF-guided cloud-native mindset,” said David Kalosi, Director of Technology at Multitude. 

“Once there was a solid strategy,” continued Kalosi, “we needed a reliable partner that would take care of our Kubernetes operations, while avoiding deep vendor lock-in.”

Multitude chose D2iQ to replace an existing Red Hat OpenShift implementation because of the openness of the D2iQ Kubernetes Platform (DKP). 

“We always need to have flexibility because things change and the world is changing,” explained Kalosi. “The overall strategy and goal is to spare us from these unpleasant situations when you are pushed to the wall because of these constraints.”

D2iQ helped Multitude create an open, flexible, extensible, and easily manageable infrastructure that gave the company the business and developer agility it was seeking, along with improved stability and resiliency. 

As Kalosi notes, “We are one of the few in this region, if not the only one, that can say that basically we are running completely microservice-driven core banking within Kubernetes.”

Before deploying DKP, Multitude was using Red Hat OpenShift as their cloud-native Kubernetes solution. However, Red Hat OpenShift products rely on proprietary APIs and CLIs, which creates lock-in. “We like to keep things open-ended,” explained Kalosi. “A vendor-specific implementation is something we definitely don’t want to go into because there is no easy way out.”

To add to the complexity, Multitude had to manually install their virtual machines and Kubernetes clusters, which was incredibly time-consuming. Provisioning a new cluster would take a number of days, or even weeks. Cluster stability and resilience were also thorny problems.

“We were performing maybe 1,000 cluster installs and upgrades. It became a routine operation where we’d install a cluster and pray that it didn’t fall apart,” said Kalosi.

The Multitude DevOps team also faced challenges meeting financial service regulations. Some of the regulatory restrictions placed on the company had led to the initial deployment of the new Kubernetes infrastructure having to be on-premises rather than in the cloud. This led to conflicting demands that lacked the flexibility required for Kubernetes modernization. 

 

As Kalosi explained, “The legacy team was basically saying, ‘We need you to do this completely new thing, but you have to do it exactly the same way we’ve always done things.’ I was throwing deployments over a brick wall.”

When searching for the foundation of its new platform, Multitude was looking for a combination of flexibility and ease of use. “We wanted something built on top of open-source components, but also comes preinstalled in a user-friendly package,” said Kalosi. “DKP gave us a very good baseline that is easy to set up and works out of the box. There are a lot of things that are already there and you don’t need to think about it and build them. It comes at a high level of production readiness.”

The support provided by D2iQ’s service and support specialists also played a role in the company’s decision to adopt DKP. 

DKP’s automation enabled Multitude to dramatically reduce the provisioning of a new cluster from what was a number of days, or even weeks, to mere hours. 

In addition, the stability, resilience, and automated management capabilities of the DKP platform gave Multitude the solid Kubernetes foundation it was seeking as the basis for accelerating its business. 

As Kalosi explained, “The only thing I have to deal with is a uniform worker node, which, when I lose one, I just provision another one. I don’t need to write tons of custom Ansible. I don’t need to do this and that. Our product, in terms of production, is rock solid.” 

With a stable production-ready platform in place, Kalosi sees vast new possibilities. “Now we are able to use the cluster to its full potential. We are at a stage where we are able to unlock new features and start implementing things that were impossible before.”

Kalosi looks forward to increasing the self-service aspect of cluster provisioning, to provide even better service to his organization’s developers. 

“We are in the early stages of shifting these responsibilities from a central team to the actual engineering teams that are building those applications,” he explains. “We are able to give them more power and more tools in order to develop, manage, and deploy their applications for themselves.”

There have been personal benefits for Kalosi, too, from the combined strength of D2iQ’s product and support team. “For me, I can have this peace of mind I didn’t have before, that, first of all, most product things won’t go south, and even if they do, we can correct them quickly.”