The future of fintech involves wholesale application modernization of legacy banking platforms to modern Microservices architectures. Myriad banks & financial institutions are modernizing their monolithic architecture to accelerate fintech innovation, seeking benefits such as reduced payment latency and streamlined regulatory compliance. Competition from platform banking innovators is forcing established banks to adapt quickly. In this article we will examine a 3 Tier roadmap for migrating from monolith to microservices, incorporating both a service mesh and API Gateway into the architecture.
Challenges Facing Banks
Clearly, not all banks are facing the same set of innovation challenges. For some, the starting point is a 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 application architectures will need to modernize in a more measured fashion, refactoring their core application over time & piece-by-piece.
In Part 2 of our Microservices Series, Cloud Migration Strategy: Monolith to Microservices we outlined 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 for migrating legacy applications from monolithic to microservices. This roadmap includes incorporating a service mesh, API gateway & eventual legacy core modernization. (See Figure 1 below.)
Monlolith to Microservices
A transition from monolithic to microservices 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.
Service Mesh: Near-Term Solution
Although microservices are perfect for most banking applications, there are challenges at scale. By deploying a service mesh early in the application modernization process, dev teams can address increasingly complex communication between services, a strategy that pays off later as the architecture scales.
What is a service mesh? A service mesh is a configurable, low-latency infrastructure layer that manages the high-volume of communication between microservices. In microservices, one service must request data from many other services. As microservices scale, this can become a challenge to manage. A properly designed service mesh architecture automatically routes requests between services & optimizes the interactions.
Why Service Mesh?
As the complexity of a microservices architecture 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 microservices can be established & proliferated throughout the platform. This increases 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.
Service Mesh Implementations
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.)
You may ask, “What about my Kubernetes 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.
API Gateway: Added 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 Core- A Future Necessity
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.
Fintech innovation from 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. In the long-run, banks will likely move to a next-generation microservices based core platform in coordination with a service mesh + API Gateway.
Cloud App Developers, LLC offers Legacy Application Modernization Services. We are Microservices Experts with a mastery of Microservices Design Patterns. To assist in this effort, we also have domain experts in fintech, telecom, insurtech and many other industries. To learn more about our Microservices Expertise, visit Cloud App Developers, LLC or contact wes@cloudappdevelopers.com
Copyright © 2021 Cloud App Developers, LLC. All Rights Reserved.