Banks & financial institutions are modernizing platform architectures to accelerate innovation, reduce payment latency & to assist in compliance. Competition from platform banking innovators is forcing established banks to adapt quickly. To compete in this arena, shifting to microservices is essential. In this article we will examine a 3 Tier roadmap for migrating to platform banking.
Clearly, not all banks are facing the same set of innovation challenges. For some, the starting point is a more modern services-based core that can be more readily modernized to offer platform banking services, perhaps with a big-bang approach. Other banks with legacy monolithic core architectures will need to modernize in a more measured fashion, phasing out their core application over time & piece-by-piece.
In Part 2 of our Microservices Series, 4 Ways to Migrate Legacy Apps for Microservices, we discuss several application modernization/migration strategies to phase out parts of monolithic legacy apps, as microservices are added piece-by-piece. Regardless of which approach is taken, financial institutions with legacy monolithic cores will eventually need to re-engineer their core banking architecture to keep up with fast-paced platform banking trends. We offer a 3-tiered roadmap to financial institutions for migrating monolithic legacy applications to platform banking via microservices. This roadmap includes incorporating a service mesh, API gateway & eventual legacy core modernization. (See Figure 1 below.)
Figure 1, 3-Tiered Roadmap to Offering Platform Banking Services
Migrating from legacy platforms to microservices-based solutions has its challenges, even when a phased approach is taken. Managing the increased operational overhead and escalating complexity during the transition is critical. We offer several strategies to help manage this chaotic transition. By adopting the proper strategy, banks can start offering some leading platform banking products & services almost immediately, even those with monolithic legacy platforms. Key to this strategy is the addition of a Service Mesh, combined with an API Gateway.
Near-Term Solution: Deploy a Service Mesh
Although microservices are perfect for most banking applications, there are challenges at scale. By deploying a service mesh early in the app modernization process, dev teams can address increasingly complex communication between services, a strategy that pays off later as the architecture scales.
A service mesh is a configurable, low-latency infrastructure layer that manages the high volume of communication between applications within microservices architectures. In microservices, one service must request data from many other services. As the microservices scale, this can become a challenge to manage. A properly designed service mesh automatically routes requests between services & optimizes the interactions.
As the complexity of microservices-based architectures increases, the root cause of problems can be difficult to pinpoint. A service mesh enhances problem identification & mitigation. Furthermore, service meshes measure service-to-service communication quality, so rules for effective communication between services can be established & proliferated throughout the platform. This increases the efficiency & reliability of the entire platform.
Service meshes also allow multiple software development teams to work in the same infrastructure more independently. Perhaps the biggest downfall of microservices architectures is the continuous need to integrate with many other microservices even when the simplest features are introduced. Service meshes solve this issue by providing a standard format for the communication infrastructure, so developers don’t have to worry about these tedious integration tasks. The code ends up being simplified as well. In a large financial company where there might be dozens (or hundreds) of developers, this advantage is significant.
There are several implementations of a service mesh. The most common involves a sidecar proxy attached to each microservice, which serves as a contact point. Service requests simplify the data path between microservices. (See Figure 2 below.)
Doesn’t Kubernetes already have an integrated service mesh?
To be sure, container orchestration platforms like Kubernetes offer basic management capabilities that are more than adequate for some applications. In a way, they offer primitive service meshes. However, a more robust service mesh in addition to Kubernetes’ services extends these capabilities & offers additional functionality, such as management of security policies & load balancing, which are critical for complex banking/fintech applications.
Adding an API Gateway for Innovation Speed & Security
The combination of an API gateway with a service mesh can provide a powerful blend of speed, security, agility & manageability. As microservices scale, the number of endpoints keep increasing & each endpoint needs to be secured. By using an API gateway, a security proxy level is created allowing threat detection before your applications & data are penetrated. In addition, APIs can be exposed to external partners & developers to enable accelerated development of services.
This does not solve the inherent scalability problem of a legacy monolithic core architecture, but new services & features can be added by internal & external teams using a service mesh & API Gateway. Most importantly, platform banking features can be developed & deployed while still relying on a legacy core, until the timing is right for the complete legacy core modernization.
Keep in mind; if the communication infrastructure is built in a way that every public request must go through the API gateway, you will need to specify these rules. This could pose a serious bottleneck, so the communication must be fluent between your various teams. Most importantly, the team responsible for creating these API rules must be scaled along with the developers introducing new features to the architecture, otherwise, it’s chaos. Resource planning and PM teams need to live up to the task.
Microservices-based Core- A Future Necessity
In the long run, banks will likely move to a next-generation microservices-based core platform in coordination with a service mesh + API Gateway. Competition from innovative fintech startups, along with ever-increasing customer expectations, means established financial services players will adapt & change the way they do business with their customers. Delivering on these new requirements will be most difficult with most legacy systems.
The main goal of converting the banking core application to a microservices architecture is to offer leading-edge services to customers. For this to happen, the speed & agility of microservices is needed. Banks may also wish to offer services from third parties, rather than re-invent the wheel for each new service. Although some of this can be done with the “near-term architecture” outlined in this article, there are limitations that may become severe.