In this chapter, we will look at some possible strategies to follow when we have to transform a monolithic application into microservices, along with some examples. This process can be a little difficult if we already have a big and complex application, but fortunately, there are some well-known strategies that we can follow in order to avoid problems throughout this process.
The process of transforming a monolithic application into microservices is a refactor code in order to modernize your application. This should be done incrementally. Trying to transform the entire application into microservices in one step could cause problems. Little by little, it will create a new application based on microservices and finally, your current application will disappear because it will be transformed into little microservices leaving the original application empty or maybe it will also be a microservice.
When your application is already a hole, you have to stop diving in that hole. In other words, stop making your monolithic application bigger. This is when you have to implement a new functionality, it is necessary to create a new microservice and connect it to the monolithic application instead of continuing developing the new functionalities in the monolith.
To do this, when a new functionality is implemented, we will have the current monolith, the new functionality, and also two more things:
- Router: This is responsible for the HTTP requests; in other words, this is like a gateway that knows where it needs to send every request, either to the old monolith or to the new functionality.
- Glue code: This is responsible for connecting the monolithic application to the new functionality. It is very common for the new functionality to need to access the monolithic application in order to get data or any necessary functions from it:
Stop diving strategy
Regarding glue code, there are 3 different possibilities to access the application from the new functionality to the monolith:
- Create an API on the monolith side to be consumed by the new function
- Connect directly with the monolith database
- Have a synchronized monolith copy of the database on the functionality side
As you can see, this strategy is a pretty way to start developing microservices in your current monolithic application. In addition, the new functionality can scale, deploy, and develop in an isolated way from the monolith, improving your application. However, this does not solve the problem, it just avoids making the current problem any bigger, so let’s take a look at two more strategies.
Another strategy is to divide the logic presentation part from the data access layer. An application usually has at least 3 different parts:
- Presentation layer: This is the user interface, in other words, the HTML language of a website
- Business logic layer: This consists of the components used to implement the business rules
- Access data layer: This has components that have access to the database
There is usually a separation between the presentation layer and the business logic and access data layers. The business layer has an API that has one or more facades that encapsulate the business logic components. From this API, it is possible to divide the monolith into 2 smaller applications.
After the division, the presentation layer makes calls to the business logic. Take a look at the following example:
Divide frontend and backend strategy
This division has 2 different advantages:
- It allows you to scale and develop two different and isolated applications
- It provides you with an API that can be consumed for future microservices
The problem with this strategy is that it is only a temporary solution, it can be transformed into one or two monolithic applications, so let's look at the next strategy in order to remove the rest of the monolith.
The last strategy is about isolating modules from the resultant or resultants monoliths. Little by little, we can extract modules from it and make a microservice from every module. Once we have all the important modules extracted, the resultant monolith will also be a microservice or it will even disappear. The general idea is to create logical groups of features that will be your future microservices.
A monolithic application usually has many potential modules to be extracted. The priority must be set by selecting the easier ones first and then the most beneficial ones. The easier ones will give you necessary experience in extracting modules into microservices to do it with the important ones later.
Here are some tips to help you choose the most beneficial ones:
- Modules that change frequently
- Modules that require different resources to the monolith
- Modules that require expensive hardware
It is useful to look for the existing coarse-grained boundaries, they are easier and cheaper to convert to microservices.
Now, let's look at how to extract a module, we will use an example to make the explanation a little easier to understand. Imagine that your monolithic application is a blog system. As you can imagine, the core functionality is the posts that are created by users and each post supports comments. As you can see from our small description, you can define the different modules of your application and decide which is the most important.
Once you have the description and features of your application clear, you can continue with the general steps used to extract a module from your monolithic application:
- Create an interface between the module and the monolith code. The best solution is a bidirectional API, because the monolith will need data from the module and the module will need data from the monolith. This process is not easy, you will probably have to change code from the monolithic application in order to make the API work.
- Once the coarse-grained interface is implemented, convert the module into an isolated microservice.
For example, imagine that the POST module is the candidate to be extracted, their components are used by the Users and Comments modules. As the first step says, it is necessary to implement a coarse-grained API. The first interface is an entry API used by Users to invoke the POST module and the second one is used by POST in order to invoke Comments.
In the second step of the extraction, convert the module to an isolated microservice. Once this is done, the resulting microservice will be scalable and independent, so it will be possible to make it grow or even to write it from scratch.
Little by little, the monolith will be smaller and your application will have more microservices.