Refactoring an application for the microservice architecture has several issues. Although it is possible to rewrite the application, a strategy known as “big bang rewrite”, this approach is rarely used. The most common is to gradually migrate the functionalities from the monolithic application to the new architecture.

The monolithic application runs at the same time as the new microservice-based application during the gradual migration process. This gradual migration process includes:

  • Separating the presentation layer from business and data layers;
  • Deploying new application functionalities as microservices;
  • Extracting the business functionalities of the application and build them in microservices.

Separating the presentation layer from business and data layers

The first important step in enabling the migration of a monolith to the microservice architecture is to separate the presentation layers and the business and data layers. The communication between the presentation layer and the application must be guaranteed by such separation. This must be done exclusively through an API, which encapsulates business and data functionality. Building this API allows to subsequently separate the functionalities served by the monolith from the functionalities served by the new microservice architecture.

The result of this process is:

  • an application for deploying the presentation logic and accesses the business and data layer through an API;
  • an application for deploying business and data logic;
  • encapsulation of the business logic through an API, which can use, for instance, the REST or GraphQL model.

Subsequently, the new microservices will use this API to access functionalities and, eventually, data from the monolithic application, as long as the two architectures coexist.

Deploying new application functionalities as microservices

Suppose that a new functionality must be incorporated into the application deployed as a new microservice (or a set of microservices), according to the adopted migration strategy.

In this case, the new microservice will also expose its functionality through an API, and we will use an API Gateway to route requirements to the new component or monolith.

Probably, the microservice will have to interact with the monolith to activate its functionalities or to access or record data. In this case, microservice can interact with the application exclusively through the APIs, or you can create specific integration code between the two elements, which may be necessary even for performance reasons.

The result of this process is:

  • The current monolith;
  • The microservice for deploying the new functionality (or a set of microservices);
  • An API gateway to route requests to the monolith or microservice;
  • An integration code for the microservice to request the functionality of the monolith and access its database.

Migrating business functionalities to microservices

To gradually extract the functionality of the monolithic application, you must take into account the need for integration with the rest of the application and, especially, the access to data on both sides when building each microservice. Microservices must have their own databases so that they are autonomous and enable evolution and versioning in a completely independent way from the application (also from other microservices).

As an intermediate step, the microservice may have to share the application’s database, however this must be a temporary situation.

Using an incremental process for refactoring a monolith into microservices anticipates benefits from the new approach. However, some issues can arise from the extraction of monolith functionalities into microservices, such as the application domain model reorganized into two new domains. Specific techniques can be applied to these cases, that is, there are already good practices for the coexistence of the monolith with microservices. For the application to run properly, microservices and the monolith must coexist and integrate with each other. In order to get the best results from this effort, the process must respect the characteristics of microservices and the integrity of the monolith in each step.

Related Articles:
API Gateways
Microservices: Concepts and Characteristics
Microservices: Properties and Achitecture
Migrating from Monoliths to Microservices