Converting from Monolith to Microservice Architecture

Monolith applications may suffer from multiple problems and issues that can be resolved using microservices architecture.

We will use a domain driven design (DDD) approach to decide and convert our monolith to a scalable microservice architecture.

Not all applications fit as a candidate for microservice architecture; as small applications with few subdomains are better maintained as a monolith.

The decision to move from a monolith to microservices can be guided by the following questions:

• Do we have more than a few subdomain models (few is between three and nine) in our monolith application?
• Can we afford the extra overhead of multiple database schemes and service bus?
• Are we expecting our subdomains to expand in the near future?

If our answers slide to the "yes" side more than that to the "no"; then we can start thinking of converting our application from a monolith to a microservice architecture.

The Business Administration Example Application

To better understand the process and the concepts, let us adopt a real lifetime example.

Let us say that we have a monolith business administration application that consists of three subdomain models: Reception, Backoffice, and Management as illustrated in the following diagram:

As you can see, there are three subdomain models in this application, this is meant for simplicity of the example. Usually, if your application is small and consists of only few models you may prefer keeping it maintained as a monolith rather than splitting it to a set of microservices in sake of cost efficiency of RDBMS systems and not to have to use extra components needed for the architecture.

Our example application has three models serving different actors' business requirements and is utilizing a single database.

Characteristics of Microservice Architecture Application

Take a look at the following diagram where we split the monolith application into an equivalent microservice architecture pattern:

All what we did is that we split the application into three microservices each serves a specific subdomain.

Notice that now each microservice has its own database, a thing that might add extra cost of RDBMS licenses as well as extra overhead of maintenance.

Also notice that data records might now get duplicated between those microservices schemes as no one service is allowed to access the database of another.

But how do the three microservices communicate to establish a concrete business workflow?

The Service Bus

Take a look on the following diagram:

Here we added a service bus such as Kafka, Artemis MQ, or RabbitMQ. This is to serve as an interprocess communication mechanism allowing microservices to log events with data needed by other microservices to update and maintain there persistent status.

This pattern serves scalability very well, as now we can add as many services as we need and provide proper communication using event logs.

The Deployment View

Now as we succeeded converting our monolith to microservice architecture, the remaining question is how we deploy them. Take a look on the following deployment diagram that offers scalability at its maximum levels.

To know the details watch my video on you tube: https://www.youtube.com/watch?v=AvxtzkQUxE0