IV. Migration example
The sample e-commerce system includes interlinked modules for shipping and invoicing. Soon, the shipping module will have to undergo a rapid expansion due to the assumed integration with new courier companies that make their services available through an external API. It is therefore a great time to separate the shipping function into an external microservice. In a few steps we will show you how such a process could look like.
1. Initial state
The starting point is a monolithic system that contains, among other things, the shipping and invoicing modules described above. The system uses a single database in which all the necessary information is stored. It is a web application used by users via web browser.
2. Overview of existing code
As a first step, it is necessary to check what the existing code for the module handling shipments and invoicing looks like. In particular, it is important to determine how these two functions are related to each other and the dependencies on other modules, external interfaces, etc. Separating these two functions may require refactoring the existing code.
3. Separation of the dispatch function into a separate module within the monolith.
If we have reached the point where both functions can be implemented as separate parts of the application, we divide the shipping function into a different module. Both modules remain within the existing monolith and continue to use a single database.
4. Data partitioning – extraction of a new database schema for the dispatch module
In this step, the data model will be divided. This is because we need a separate database schema for the new shipping module. However, both modules remain within the existing monolith.
5. Separation of the dispatch module as an individual microservice
Having a separate shipping module within the monolith along with a separate database model (schema), we can extract it from the monolithic application to a new microservice. This microservice does not have to be used in production at the beginning, because the shipping module still exists in parallel in the monolithic application.
6. Making the microservice available to users
The purpose of this step is to make the new microservice available to users of the system and thus replace the old shipping support module in the monolith. To do this, we need to add a new element to our application called API Gateway. This is a service that distributes incoming requests from clients/users. Some of them (e.g. those concerning invoicing) will go to the monolith. Requests for shipments, on the other hand, will already be directed to the new microservice.
7. Removal of the dispatch module from the monolith
If the acceptance tests of the new microservice are successful, then the last step is to finally get rid of the dispatch module from the monolith. This is a very important step in order not to maintain unused code on the monolith side and to reduce its complexity, which can also benefit when migrating other functions from the monolith to subsequent microservices.