Microservices - A Modular Approach to Software Architecture

What is Microservices?

Microservices is an architecture to create an independent and decoupled processes or services which are easy to deploy and develop. These services follow the single responsibility principle to serve a single business goal. These services interact with each other using API Gateway pattern.

Developing MSA from Monolithic/SOA based application

A typical monolithic web application consists of 3 major parts:

• Presentation layer - End user interacts with this layer to perform certain actions.
• User services - An implementation for business logic. Invokes the module/feature based on user interaction to the UI layer. Also initiates the backend job based on certain external event triggers.
• DB layer: This layer interacts with the persistence layer to commit the results of the user actions.

Demerits of this architecture:

• Inter module dependency
• Tightly coupled architecture leads to heavy regression cycles
• Substantially less releases
• Difficult to scale the application to an atomic level

One of our engagement of providing a healthcare web solution interface required users to enroll themselves to the health exchange by registering to the insurance policy. The legacy product was previously built over service oriented architecture (SOA). Each module was interacting with each other using REST API.

SOA Architecture

 

The above diagram shows the SOA architecture with typical 3 layers of the product. The Presentation layer interacts with the Business Layer using REST APIs. The Business layer is distributed within multiple servers interacting with the monolithic DB/persistence layer.

Need for evolving the solution/architecture:

• Pit-falls from monolithic application issues led to create componentized applications evolving SOA to the next level.
• With more applications moving to cloud platforms the need for the application led to creating complex and hybrid solutions. This requirement was easily be achieved with a stable Microservices.
• As per the current business needs, the product needs to be scalable. Usage of Microservices made the application easily deployable and scalable.
• In traditional SOA based application, the product used to go through heavy regression to make a release. But in case of MSA, innovation to a particular service could be made many times without modifying the other features.
• If any of the services goes down, it’s not required to shut the whole system down instead once the feature can be removed and re-installed while others serve the user.

The architecture has been evolved to the below diagram

Architecture

 

The module was identified and the feature was evolved to the Microservices architecture. Each service had its own UI, a business logic and an independent DB. On development end, each Microservices had been independently managed by a small team having its own code repository. The feature was easily modified and had its own deployment / releases without affecting the overall product feature. Team could choose their own technology/DB or architecture suitable for their business need. As the product drilled down to many decoupled applications, each feature could be sold out as an independent product. The inter-module interaction was done only using REST/AMQP without knowing the architecture of the other service.

Benefits

• Using Microservices architecture, reduced the overall integration time. The regression cycles were independently executed on these services.
• One small team could work on the service and control the release cycle as per their priorities.
• Deployment was made very easy as each service had its own repository integrated with the Docker image which took care of the deployment.
• Teams were able to choose the technology stack as per the business case or the feature requirement.
• As the services are decoupled from each other, scaling of these services was easily achievable.