Migration from Monolithic System to MicroServices Architecture
Microservices is a another paradigm of developing software applications, in which the architecture is structured into small independent small blocks, each with its own responsibility and persistent data, which is loosely coupled to other services [2]. Microservices introduces, scalability, easy and low risk change management, and automation of deployment.
This post will be discussing migration of a monolithic banking system to an MSA. Different approaches will be discussed and principles of an MSA will be shown also. After that, an example approach will be followed to show what are the steps that can be done to finish the migration successfully, also how testing should be made to avoid any unexpected failures. In the following section, I will discuss some approaches and what are their principles and compare them to each other.
Related Studies
Banking sector is a very private sector, the reserach and developemend made in this domain, is most of the time not shared with public (as all other private sectors). Neverless, there was some banks that chose to share their experience and the workflow they followed to migrate from a monolothic system to MSA. Different banks, followed and created different approaches that suited best their business modal. First, let’s see what are the reasons that made those banks decide to move from a monolothitic system to a microservices architecture.
In monoloithic architectures, modularity is not a design principle, all functions are developed based on the moment business requirements, that’s why a lot of functions can be doing many responibilities, manipulating different classes of data, and communication so often with other functions, and even can be redundant, by repeating the some work done in other places of the program also. Beside that, since these functions require often communication, they are all typically written in the same language, this language choice usually is based on the one famous and seen as safe chocie in the time of develoepement, that’s why we see a lot of bank systems still use language as COBOL. The other problem with monolothic systems, is that they are not scalable, if one function is receiving a lot of requests, it will be using all resources, and effecting the performance of other functions, even sometimes a crucial function for the business, might not be able to work efficiently because other unnecessary functions (but still need to be exist) are consuming most of the resources of the system. Another problem is, change is so much expensive since one function is handling more than one responsiblity, and same code can be found in different places, so each time a change is made, the whole system needs to be tested, and that’s why most banks are limitting the number of deployment they have, which is also another problem in monolithic systems, because even a small enhancement change, or a bux fix, requires all the system to be recompiled and deployed togther. [3]
Before talking about how migration to microservices is done, I would like to mention some principles that needs to be followed [4] :
· Do one thing well
· No bigger than a squad
· Grouping like data
· Do not share data stores
· A few tables only
· Independent technology selection
· Limit chatty microservices
The above list, if followed, guarentees to a high degree, an MSA that will increase the performance, scalibility and liability of the system.
Migrating from a monolothitic system to an MSA, is not an easy task, and also it’s a task that takes a long time to finish. That’s why different banks, follow different paths to achieve that, based on their business requirements and the parts of the system they plan to migrate. The first approach that can be followed is a use-case microservices implemenation [5], which means, all the current use cases that the team wants to migrate to microservices is written down, and implementation of them starts according to their priority, this approach is followed in order to not re-implement the monolothitic system, in case of bad code logic or bad implementation, this approach will be a good solution to re-create everything from scratch. But, what if not all the use cases are known, and the current system is doing a lot of work that’s not documented, and there is a big risk of losing important functionality while migrating. To solve this, other teams prefere to first reverse engineer the current monolithic system [4], understand all the work it’s doing, list the functions and their responsibilities, categorise these functions, and than split them to small functions that can run seperatly as microservices. Both approaches can be followed, and the decision needs to be taken according to the size of the system to be migrated. In the next section, I’ll be discussing how did I use the first approach, to develop a small smart banking app, using the first approach mentioned in this section.
Implementation of project
List use cases of important functions
As mentioned before, a lot of different approaches of refactoring monolithic systems exist [6], one of the approaches that can be followed, is the one that emphasizes creating Use Cases about the functionality of the system. The use cases should be decided between the different department of the bank, Business/Financial Department will create a list of the current users behavior and functionality he is expecting from the current system, these functionalities should be listed according to their priority for the bank, for example, if the bank mobile app includes a “game” inside the app that allows the user to win different prizes, even if this game has a lot users, its priority will be below sending/receiving money. Figure 1 is an example of a use case.
Use Case 1: Send Money
. Verify the token validation of sent request.
. Verify the device of the current user.
. Verify the information of the user to be send to.
. Verify that the user has enough money in her account.
. Add a transaction request to transaction table with the right state.
. Subtract money from the user’s account.
. Send money to the other user.
. Update the transaction table with the right state.
Categorize the Use Cases them according to their priority
After making a list of all the use cases, the engineering team need to categorize them, the decision of categorization will be made according to two main objectives:
1. Business Logic: Use cases that are mentioning the same business objective, or the use cases that the different teams decide to put them together because of some business importance (changing from a bank to another).
2. MSA principles: respecting the principles of MSA mentioned in the introduction section is so much important (Figure 3), otherwise the new architecture will be a group of small monolithic systems, with no difference from the original system, or will have even a worse architecture, that will make maintenance and adding new feature a big problem.
Keeping services dependability and communication as low as possible is one of the most important principles of MSA, for the cases where services need to communication with each other, a middleware needs to be added, and, communication should be made in an abstract way. Thus, even that the services are communicating with each other, a future decision of change technology will not have a big impact (Figure 2).
Time and users to be tested on
Implementation of the use cases according to their categories will be discussed in the next section. In this section. In this section when and where the tests of the implementation should be implemented. Every banking system has a backup system and a testing system, that are always kept 1–1 updated with the release version of the system. As you can guess, the test should be made first on the Test System, since this is just a test sytsem, it can be duplicated as much as we need, so breaking it won’t be a problem.
Each time a new service is implemented, The replaced old services need to be shutdown and replaced by the new services, which means both the monolithic system and the MSA system will be working in the same time, until all functionality of the old system is replaced.
After all the old system functionalities are replaced with the new MSA system, we need to test it carefully again, the testing of the new system will be made in an opposite way of how the use cases has been assigned their priority. That is because we need to test how much the new system can be dependent on, by testing the new functions that are new crucial to the business. Saying this, means for the release version also, for a period both the monolithic and MSA versions of the system will be running together (Figure 3).
Conclusion
To facilitate the migration from a monolithic banking system to an MSA, a top down approach was suggested. This approach, which aiming for reducing the risk of any shutdown of services or mis-function of others, suggests 4 important steps.
The first step is to write down all the use cases of the current system and expectations of users. The second step is to categorize these use cases according to the importance to the business logic and by their software functionality. The 3rd step is to implement the uses cases according to their order, the decision of which technology to be used is decided by the engineering department as described in detail in the 3rd section. The last step should be done in parallel with the 3rd step because each new service is independent, it can be tested by itself without the need of the whole system to be completed.
Migrating from a monolithic system to a MSA for a banking system is a long and error-prone project, that’s why it should be done very carefully, and every decision made should be examined and discussed between all the teams before implementation. And each step taken, should be as much conformable with the MSA principles, otherwise the result will be a mix of monolithic and MSA systems, which is something that is worse than a full monolithic system.
References
[1] M. A, S. V and F. TP, “SOA maturity influence on digital banking,” IDRBT J Bank Technol 2, 2018.
[2] N.Dragoni, S. Giallorenzo, A. Lluch-Lafuente, M. Mazzara, F. Montesi, R. Mustafin and a. L. Safina., “Microservices: yesterday, today, and tomorrow.,” in Present and Ulterior Software Engineering., Springer, 2017.
[3] L. W, R. S, C. S, L. L and P. S, “Serverless computing: an investigation of factors influencing microservice performance,” in IEEE international conference on cloud engineering (IC2E), IEEE, 2018, pp. 159–169.
[4] A. Megargel, V. Shankararaman and D. K. Walker, “Migrating from Monoliths to Cloud-Based Microservices: A Banking Industry Example,” in Software Engineering in the Era of Cloud Computing, Springer, 2020, pp. 85–99.
[5] A. Bucchiarone, N. Dragoni, S. Dustdar, S. T. Larsen and M. Mazzara, “From Monolithic to Microservices: An Experience Report From the Banking Domain,” IEEE Software, 2018.
[6] J. Fritzsch, J. Bogner, A. Zimmermann and S. Wagner, “From Monolith to Microservices: A Classification of Refactoring Approaches,” 2019.
[7] C. M. Aderaldo, N. C. Mendonça, C. Pahl and P. Jamshidi, “Benchmark Requirements for Microservices Architecture Research,” in 1st International Workshop on Establishing the Community-Wide Infrastructure for Architecture-Based Software Engineering (ECASE), 2017.
[8] C. Richardson, “Refactoring a monolith to microservices,” 2020. [Online]. Available: https://microservices.io/refactoring/.
