Monolith to Microservices Migration

The monolithic application is assessed, and the boundaries between the services, the dependencies between the modules, and the ownership of the data are determined. A document will also be produced with the migration roadmap, the proposed sequence of the monolith decomposition, and the estimated effort for each service. This step is mandatory before any migration activity is performed.

We undertake microservices architecture design for new applications and for monolithic applications that are being broken up into microservices. This includes domain analysis and definition of bounded contexts, service boundary definition, inter-service communication design for both synchronous and asynchronous communication, API contract definition, allocation of ownership for data per service, and infrastructure topology. The result is an architecture that is documented and includes deployment diagrams, interaction diagrams for services, and a decision log that includes technology decisions and trade-offs. Architecture design is one of the services that can be undertaken independently of migration work.

We apply domain-driven design principles to assess the current monolithic system and define bounded contexts. We then define boundaries between services based on domain-driven design principles. Each service owns its data and has its own API. We define the order of decomposition based on coupling analysis, not visibility. We start with modules that are least coupled.

In the case of applications that do not allow a shutdown, we employ the strangler fig approach, which involves the creation of new microservices parallel to the existing monolith, with the routing of the monolith to the new service done gradually. This eliminates the need for a ‘big bang’ approach, as well as allowing each service to be tested in production before moving on to the next service.

In this approach, shared monolithic databases are split up among the different services, which includes schema decomposition, data migration, as well as implementing eventual consistency patterns and synchronizing mechanisms for the transient phase where shared databases are still in use.

The services include the creation of the API gateway layer and the creation of communication protocols for the services. In terms of synchronous communication, this can be done using either REST or gRPC. In terms of asynchronous communication, this can be done using event streaming, where technologies like Kafka and Azure Service Bus are used.

The microservices are containerized using Docker. In terms of orchestration, there are several options available. They include Kubernetes as well as other services like Amazon EKS, Azure AKS, and Google GKE.

We implement the CI/CD pipeline for all the microservices. This is important because, in the monolithic architecture, there is shared deployment. With the implementation of the microservice architecture and the use of the CI/CD pipelines, we are able to achieve the smooth upgrade process without the shared deployment.

We set up the observability and monitoring for all the microservices. This step is important because we are able to monitor the behavior of the microservices and any issues or bugs that might have occurred in the process. We achieve this through the use of Open Telemetry, Prometheus, Grafana, and ELK Stack.

We decommission the monolith, clean up the shared infrastructure, and document the process. This step is done after all the services have been extracted and are running in the production environment.

We offer maintenance services for applications that are based on a microservices architecture after migration or initial development. This includes performance monitoring and resolution of incidents, dependency and security updates for all services, cost optimization for infrastructure, configuration updates for scaling services, resolution of bugs with root cause analysis, and development of new services within the existing architecture.