Why Fiserv Turned to Microservices for API Development

For fintech and payments company Fiserv, delivering on goals got complicated as more applications filled its wheelhouse, driving a move to microservices to be more proactive and nimbler. That was a central theme of a keynote at this week’s API World / AI Dev World conference, delivered by Clint Myers, vice president of architecture and CTO of account processing for Fiserv.

Fiserv’s diverse portfolio of banking products presented a number of challenges, he said, because there is no single predominant application that speaks to core banking tasks such as account management. “There could be as many as 20 of these particular types of applications in the portfolio,” Myers said. “Some of [the apps] might focus more on the smaller community banks, some on larger banks, some may be better products for credit unions.”

The challenge of building a retail banking application can mean focusing on optimal user experience, but the application would also need to work with a wide variety of different banking platforms that each function fundamentally different, he said. “They’re different hardware and software; they have different histories and different interfaces.” Attempting a point-to-point type of integration for the application could lead to a troublesome, spider web problem. “It would greatly become cost-prohibitive at the end of the day,” Myers said.

In the old days when dealing with such integrations, he said, a very monolithic approach to architecture meant organizations would have to slow the infrequency of deployment, especially when stability was a key concern. That can be detrimental in a business where time to market is a key priority. “We ended up having to deploy less, which decreased the probability that something would go wrong,” Myers said. The reduced frequency approach, however, was not ideal for customers.

Fiserv turned to a microservice architecture for the system, which let the company deploy small components many times with confidence, he said. “Moving to a cloud-native architecture, a Kubernetes fabric for example, allowed us to take a different type of approach.” That moved Fiserv from a reactive posture to a proactive strategy, he said. Instead of focusing on having the best monitoring in the world, where team members get phone calls late at night to straighten out situations, Myers said Fiserv relies on the Kubernetes fabric, which allows for the detection of unhealthy instances of Docker containers. It also lets the fabric deal with certain issues all on its own.

“There is a relationship between scalability and stability,” he said. “You could become unstable if you can’t scale but there is also a relationship between scalability and cost.” It was attractive to Fiserv to autoscale through microservices, Myers said, and support the dynamic addition of component instances as the load increases or scale down as the load reduces. “It directly translates into cost savings.”

Leveraging microservices can add up such savings, he said, when looking at a cloud-based architecture and maximizing application density. It also let Fiserv develop APIs much more quickly, Myers said, and helped his company solve talent needs in IT. “It opened up a new community and talent pool that allowed us to effectively staff and accomplish our goals.”

Some of the business segments that were transferred microservice domains included account management, parties affiliated with an account, payments, and cards, he said. Migrating to the Spring Framework and open source allowed for the development of simpler APIs. “The lightweight nature of the stack allowed us, by the elimination of technical debt and moving to a framework such as Spring, to reduce our footprint by almost 100%,” Myers said. “That’s just total insanity.”

Related Content:

PayPal CEO Discusses Responsible Innovation at DC Fintech

DC Fintech Week Tackles Financial Inclusivity

What to Know When Migrating DevOps to Microservice Architectures