Microservice architecture is a promising approach to developing corporate software systems. Instead of developing an application as a large monolith, simple services are created which offer the desired functionality when combined.

Microservices have beneficial properties, however, how to deal with monolithic applications that are still in operation, support important business processes and will evolve for a long time? When and how to migrate them to the microservice architecture?

To decide whether a large and complex monolithic application should be refactored into microservices, you should answer a few questions:

  1. Will the application remain in operation for a long time? Will its functionalities have to be updated?
  2. Are the development and implementation of new functionalities complicated and slow?
  3. Do new versions of the application usually have bugs?
  4. Do application scalability and quick deployment have problems?

If the answers to these questions are positive and if previous actions have already been applied unsuccessfully to resolve these issues, then the monolithic architecture may be the problem. In this case, migrating to the microservice architecture may provide many benefits, including easier maintenance, tests and deployments, therefore, faster and better development process. Moreover, the microservice architecture is highly scalable and has better conditions for isolating errors.

Migrating to Microservices

Converting the monolithic application into microservices is a way of modernizing the application, but only if it solves a significant part of the problems of the current application.

You can do this process in the following two ways:

1) Create a new application version from scratch; or

2) Gradually migrate to microservice architecture.

The implementation of a new version of the application from scratch is known as the big bang rewrite. It seems simple to solve it that way, but some problems need to be taken into account:

  1. Probably a lot of time has been spent and a lot of work has been done so that the monolithic application could meet the business needs to date. Therefore, considerable effort is also required for it to be developed in the new architecture.
  2. It will be almost impossible to make the current monolithic application stop evolving to wait for the new microservice based application to be ready for use.
  3. Furthermore, it is very likely that at the end of the development process the new application is out of date with the current business needs due to the time spent.

This is rarely the best solution. Instead of using this approach, we can gradually migrate it, so that the functionalities of the monolithic application are “transferred” to the new microservices that will be built.

Gradual migration

In this way, the number of microservices increases and the monolithic application decreases until it disappears completely. During this process, both microservices and monolithic application need to collaborate with each other so that the business’ functionality needs are met.

This strategy has some challenges, but it certainly has fewer risks than the big bang rewrite approach. Moreover, the strategy of incrementally refactoring the monolith into microservices provides an immediate return on investment. It supports the migration process, which can take a long time and may need new resources. In addition, each microservice is developed with new technologies, as well as new development and delivery techniques, and the software team becomes more agile and efficient as time progresses.

During this process, the ideal is that the changes to the monolith only enable interaction with the microservices, that is, the new functionalities or changes to the application should be implemented in the new architecture so that it supports the new business process needs.

Building Microservices

Incremental refactoring requires a strategy to indicate which microservices should be built and in which order.

Firstly, we can take into account the new functionalities that arise during the process. As mentioned, it is preferable to develop them with the new technology, according to the rules for creating microservices and their properties. That is, if the new functionality is too simple to qualify as a microservice, you must update the monolith to incorporate such functionality.

If the new functionality supports the creation of a new microservice, you have to create the elements to integrate the monolith and the new microservice. Such elements are:

  • API Gateway to route requests to the new functionality of the microservice, as well as to the monolithic legacy functionalities.
  • Code to integrate the microservice and the monolith mainly to access databases and other functionalities, which can use one or more communication mechanisms between processes.

However, to enable the incremental functionality model through microservice and the gradual migration of functionality as a whole, you have to make sure that the presentation layer of the application is completely separate from the business and data access layer, which may change the application. The layers must communicate exclusively through an API. This API encapsulates business and data functionality for the presentation layer.

Gradual extraction of monolithic functionalities

Monolithic functionalities can be extracted gradually to be implemented in microservices by splitting the monolithic application into layers. Such microservices include business functionalities exposed as API calls. They can also access the monolithic database or have their own autonomous database.

The fact is that the process of creating each microservice to replace monolithic functionalities faces the challenge of refactoring the domain of the previous application by isolating the domain of the new component. Such separation typically requires breaking dependencies and refactoring the monolithic database.

Prioritizing the most important functionalities of the application for implementation in microservices is crucial. The characteristics below help to identify the most beneficial functionalities when implemented in microservices:

  • functionalities that will evolve greatly over time;
  • parts of the monolith that have scalability, performance or reliability problems;
  • functionalities that facilitate the extraction of other functionalities.

Finally, the analysis of the elements of the current application can indicate the microservices that must be built to replace the functionality of the monolithic application or it is possible to follow an independent path, that is, to indicate the ideal set of microservices for the business needs and then map the migration of monolithic functionalities.

Related Articles:

API Gateways
Webinar: Modern application development with Microservices and API Gateway