Home > blog > Microservices II – Is it possible for all banks to adopt microservices?

Enterprises have been struggling to develop applications that are agile and quick to change. Microservices architecture provides a way to overcome this challenge and has therefore caught the attention of enterprise IT teams.

From a technical angle, microservices avail service-orientation principles and functional partitioning to “monolithic” applications so that the systems work as relatively independent services. From a business benefit point of view, it makes companies digital ready and provides numerous advantages to them like allowing experimentation and innovation, sanctioning more autonomy and accountability, enhancing the resiliency of mission-critical systems, by scaling and reproducing parts of systems rapidly, and enabling cloud adoption and cloud-native architectures by deployment of services over multiple VMs or containers that function together.

Bank regulators are looking to drive better deals for the clients by generating more competition by innovating customer information sharing, transaction initiation, and payment mechanisms through open APIs. With an open API economy, banks get an option to introduce their customers to new products and services through collation among the business units within a bank, across industries, and between banks and other complementary sectors of the economy, especially data businesses and technology.

Microservice splits monolithic applications into a set of services that communicate with each other through open APIs. Each service acts out one particular function pretty well; the service and its API are a product that is detectable, well-defined and carefully maintained. These self-contained services are then constituted as needed so as to deliver complex functionality, even if they are deployed independently of each other. Services can calibrate independently as well, making the software flexible at runtime. And if a single service folds, it doesn’t mean it will bring down the entire system because of the flexibility built into microservice-based digital banking solutions.

It has come as a blessing for the banks because this approach will provide favorable circumstances to deliver value at subsequent intervals and not wait for a massive technology shift to happen. Open API banking combined with microservices-based architecture will define the success in banking space in the near future, where banks would be in a better position to accelerate time to market in the real sense.

While microservices promise a better future to the banking industry, it would require banks to rethink their operational support, delivery methodology and required skills. Only that banks that will consider an upgrade in people, process and technology will be able to leverage the power of microservices and utilize it to the maximum.

Examples of banks that have benefited from adopting microservices

Nordic APIs recently worked with the Canadian Imperial Bank of Commerce (CIBC), who have set out on their own microservices journey to get rid of their existing monolithic backends. One crucial tenet of this journey is a microservices framework Light 4J, that CIBC built themselves. They’ve assembled it from open source components instead of trying to customize a commercial offering. Nordic APIs was assigned the task of reviewing its features and functionality to both validate their progress and provide constructive feedback.

By developing their own microservices framework, CIBC acknowledged the need for microservices in a standard, reiterating framework of development that can be embraced by the all within an organization. Cultivating a microservices framework from the beginning connotes that it can develop side-by-side with CIBC’s microservices maturity. This is crucial because it allows the organization to learn lessons and adjust their approach accordingly. With these benefits, CIBC is well-placed to adapt and experiment with their architecture, both in terms of domain and technology. This kind of flexibility lends itself to the Evolutionary Architecture style. In the process of building the Light 4J framework, CIBC is using a standardized microservices frame that deals with cross-cutting concerns as a key tenet of the framework. The homemade approach is also beneficial when it comes to introducing resiliency in the style of API that can be supported.

Another example is the Monzo Bank, who created their backend systems using microservices architecture and implemented using Google’s Golang. The memorable part of this project was Golang’s brilliant concurrency primitives that make this language consistent for creating ‘high volume, low latency, distributed applications; the use of a microservices framework like Monzo’s open source ‘Typhon’ framework in amalgamation with the CNCF ‘linkerd’ proxy, being highly advantageous for implementing core communication concerns; and enabling distributed tracing through context propagation being a key enabler for observability and debugging distributed systems.

Will the microservice architecture become the preferred style of developers in future? It is a question that still remains unanswered. But it’s clearly a potent idea that provides serious benefits for designing and implementing enterprise applications.

Article by

Maveric Systems