Riding the wave of API, banks start to implement Microservices as an API framework. Some banks even see it as an antidote to many problems.
Such as performance, resilience, scalability, etc. Some people even claimed the future of core banking is also on Microservices.
Microservices has the undoubted capability in solving many problems but it has its limitations. Here we list 3 major challenges of implementing Microservices in Banks.
Transaction Management
Service Performance
Application Partitioning
Transaction Management:
Transaction Integrity in Distributed Computing is always a problem.
Since Microservices is the technology of distributed computing, when transactions are taken place in different Microservices or different servers, the overall integrity of these transactions is difficult to be managed.
For example, you can deduce money from one account but fail to deposit money to another account.
There are several solutions for this problem, such as Distributed Transaction Coordinators, its slow in performance.
The other solution is to adopt the event subscription architecture. It may have a window of data inconsistency.
Our suggestion is to avoid the distributed transaction. So you partition your Microservices in the way that all transactions are taken in one service.
Service Performance:
Although Microservices is able to distribute the load to different servers, it does not guarantee the performance of each individual call.
This is because each individual call may trigger a number of Microservices, all Microservices communicate over a network, and the efficiency, latency, reliability of the network never guarantees.
Application Partitioning:
The architecture approach of traditional applications is Monolithic. Software architects need to adopt a new architecture approach of Microservices.
They have to break down the single application into many small services, each service can run and be managed independently.
The application partitioning is a case by case exercise each application.
In addition to technical knowledge, designers also need relevant domain knowledge. We consider the domain knowledge, is even more important than technical knowledge.
For instance, if you are going to develop a Microservices-based OMS, you need to know the Life Cycle of Securities Trading. So that you can define the system boundary well.
We see there is a hype in the banking sector for the use of Microservices. But it is not a silver bullet. There are cases completely not suitable for Microservices.
We have seen a case of system migration from a database-centric application (It has over 100 thousands line of code in stored procedures) to Microservices architecture. Needless to say, the project ended up in failure.
In the nutshell, the monolithic approach has many advantages. Whether the Microservices approach fits you, depends on the problem you are dealing with.
Thank you for reading the article. For the details of Microservices implementation in Banks, please contact us. Thank you.
Comments