Migration of a monolithic system to a system based on microservice architecture style.
Monolithic system divided into modules based on technical or functional division.
- The target system is to be built from independent microservices that can be developed by different teams.
- Each microservice can be independently created, tested and deployed.
I. Preliminary steps to be taken before the migration
1) Preparing for migration
Regardless of the type of migration that will be carried out, it is necessary to perform several steps before the actual start of the migration implementation. The preparatory phase is illustrated in the diagram below.
2) Analysis of the existing solution and preparation of an initial migration plan
The second step is the analysis of the existing system and presenting an initial idea for its migration.
3) Planning the pilot migration phase
As migration is a complex and usually lengthy process, in order to better plan its course, we propose to perform a pilot migration at the first stage. It will allow to migrate 1.2 selected functions/modules of the system.
Consequently, the abovementioned migration will allow to test the prepared infrastructure, CI/CD tools, etc. We suggest that these should be functions independent of the core business domain of the system, which can operate separately from the existing monolith. Good candidates for testing are e. g. user authentication, customer profile, etc. It can also be a completely new system function that will be implemented as a microservice. During the implementation of the first microservices the team will gain knowledge about:
- The transformed monolithic system, its architecture and existing technical background.
- Creating a system based on the microservice paradigm. After this stage, tools and good practices are already known, which will be used to create further microservices in a coordinated and secure manner.
- The needs and requirements of the infrastructure and environment in which microservices will operate.
The stages of the pilot migration are shown in the diagram below.
3a) Gaining extensive knowledge of the business domain of the migrated system.
One of the conditions for a successful migration of a monolith to a microservice system is a good definition of microservice boundaries, i. e. functions performed by individual microservices. However, for this to be possible it is necessary to have a good knowledge of the business domain implemented by the existing monolithic system.
Considering the fact that a microservice system is often created by a new team that does not have the domain knowledge, it is necessary for the participants of this project to acquire it. For this purpose it is good to use one of the methods of acquiring domain knowledge, e.g. by organising an Event Storming session. Without going into details, during such a session business representatives and experts meet with the project team, which can gain information about key processes as well as the way the business works and then relate this information to the designed system.
From the technical point of view, the system whose migration is estimated should have appropriate documentation of the existing architecture. If such documentation does not exist or is incomplete, we suggest performing such a technical analysis and documenting the architecture, e.g. in the form of the C4 model, before commencing the migration.
3b) Infrastructure preparation
The process of creating a system based on microservices also includes the preparation of an appropriate infrastructure which will be able to ensure the possibility of fast integration of all microservices on a single platform, their testing, debugging and implementation e.g. in cloud environments. Using appropriate tools such as Docker and Kubernetes will allow you to prepare the infrastructure once and then freely deploy it both in on-premise and any cloud environments (e.g. Azure, AWS, GCP, etc.). It is also important to be able to monitor the operation of microservices, in order to be sure that individual elements of the system are working correctly.
This can be ensured by creating appropriate pipelines within the CI/CD tool. Furthermore, the containerisation of services and side tools will contribute to easier transfer of system elements between different working environments. It will also provide a higher level of abstraction of the implementation infrastructure.
In the diagram below, there is a description of an example of Continuous Integration flow using Azure cloud services.
Once the code is placed in the GitHub repository, the automatic process of downloading the code changes from the repository and executing CI processes scheduled within the Jenkins tool. In this step, container images are built (e.g. Docker) and are then placed in the Azure Container Registry repository. In the next step, Jenkins deploys the new images to the Kubernetes cluster, which manages a whole group of microservices and side tools. The Azure cloud provides the Azure Cosmos DB tool, in which data can be modelled as a non-relational database. In turn, the Azure Monitor and Grafana tools enable continuous monitoring of the status of applications and containers and databases used in the migrated system.