Split the Monolith: What, When, How

Steps to Split

Preparation

Here are more or less formal steps to split monolith. The steps may be adjusted taking into account business needs, monolith state, CI/CD procedures, etc.  

The list of modules/services that were obtained early on when the baseline was established should be organized around business capabilities and may be one level deeper.  An example could be that addresses may be required by the fraud detection system and by promotion services as well. 

The desirable goals may be achieved in the middle of the splitting process. It may be good from a business point of view, but terrible from a tech point of view to stay with monolith with several extracted services. 

Refactoring First

It is hardly possible that the application, which needs to be split has a good shape for this. Therefore, several rounds of service refactoring in the monolith may be performed. Some services may be under refactoring, another is extracting. 

Typical Layered Application

This is the starting point for service extraction, when the main layers of application such as controllers, application services, DAO, etc., are observable and understandable.  

Service/Feature Boundaries and API

The DDD may help to define and service boundaries, but instead of modeling the business model, we need to extract business functionality from the existing application. Just start mapping business functionality to the existing application services and domain model to identify service boundaries. 

In the layered application, controllers may depict the API to extract. The API may be adjusted/extended, but the main point here is that the entire application must work with service with minimal changes. Changes are related to the why and how we need to work with functionalities to extract (Proxy and Facades).

Create Service Facade

When service(s) boundaries are defined need to change the way of interaction with functionality, instead of dealing with a set of application services that represent business functionality, we need to create a facade and work through facade in monolith application.

In other words, we need to get a loosely coupled monolith before extracting services.

Refactor Data

Extraction of one service with a database may impact several different services of a monolith. Access to the service data must be through API only, not via database. So even one service extracting, may require significant effort, because of direct access to the data.  

Stop Writing New Features Into Monoliths

It is a standard situation when two initiatives such as split to microservice and adding a new feature into solution are performed in parallel, so it makes sense to create a new feature as a separate microservice from the beginning.

Splitting

Mostly all preparation steps should be done before the actual splitting. The application should be presented as a loosely coupled monolith with fine-grained services, well-described API and boundaries, and isolated data per service (avoid data sharing across DB).

Prioritize Services To Extract

The more correct way is to call not a service extraction, but business feature extraction. Try to reorganize/refactor/group existing applications by business capabilities/domains, and each of them may include multiple application services.  

Potential prioritizing criteria:

• The most frequently changed services: Minimize influence to deployment.

• The service that may be replaced by 3rd party service: Just to make the codebase lighter

• The service which needs to be scaled: Optimize performance.

• Coupling with the entire monolith: Make the codebase lighter and more understandable.

• The complexity of the service: To gather experience with a small one, establish CI/CD process, way of communications, etc.

The list may be different; such criteria as changing underlaying database model from relational to NoSQL, technology changes (programming language), teams utilization, etc. may be added.

As a result, at least one service can be chosen for extraction.

Select the Way of Communications Among Microservices

This is not a very complex step. However, we need not only to select the protocol and serialization type but also to take into account restrictions from the cloud providers (i.e., broadcasting support). In most cases, REST or gRPC is a preferred way for request-response synchronous communications. This is due to reasons including relative simplicity, teams experience, support by different tools, etc. It is very hard to imagine clean TCP usage for new or extracted microservices.

The message-based way of communications cannot be considered as a request-response alternative due to async nature, single direction (of course, it's possible to use the “reply to” mechanism, but it leads to service coupling), etc.  The async is suitable for event sources (fire and forget), and for consumers to build their own picture of the world.  An example would be a notification about successful payment will be reflected in the order fulfillment system to assemble the delivery and in the finance systems. The SQS, Kafka, or some other messaging services may be used.  

Implement Service

Implement microservice with selected communication approach, own database, etc. It makes sense to create a service mock for testing purposes to test monolith and the rest of the related microservices.

Create Service Proxy

Create service proxy with additional responsibility. Use service in monolith or use extracted service. Imply that proxy is available to communicate with remove/extracted microservice.

This proxy will allow easy switching between existing service implementation in the monolith and extracted services. The canary release approach can be used.

Check if initial goals are achieved and make the decision to stop or to continue the splitting process. In the case of continuation, you need to select the next feature and perform an extraction.