MicroServices The Trend Setter

Posted by: admin
Category: ASP.NET Core, C#, Design Pattern, Development

Software development has been evolving from time to time and every developer tries to make their development better in some or the other way by applying different patterns that allows the code to resolve a typical problem effectively. So, I have gone through one of the emerging concepts of development called as MicroServices. Here I am sharing my understandings about MicroServices this will give you the idea about what are the use-case of it and how it works.

What is Monolithic Architecture?

To understand the concept of MicroServices, it is require to understand the predecessor of this architecture “Monolilthic” architecture, an existing development pattern. Traditionally application is developed as interdependent modules but deployed as an atomic bundle at same place. 

Due to its tightly coupled architecture, each component of the application is developed in specific order to be make the code compile and run. This makes it easy to maintain and debug the issues as it is available on the same place.

So, it is easy to develop, deploy, test and horizontal scale with multiple copies. But there are some caveats to this such as

  1. It might not be easy to understand the application when it grows too large and complex.
  2. Large application will take time to start.
  3. Even a minor update will trigger republish of entire application
  4. Tough to manage changes and adapt new technologies.

To overcome this disadvantages, concept of MicroServices came into picture.

What is Microservices?

MicroServices concept came from Single Responsibility Design Pattern which says that each component should have their own single responsibility.

Here, MicroServices Architecture is nothing but splitting a complete application in to small interconnected services. Each services will have their own architecture. It is also possible that one service may be connected with other services. This services will be exposed through REST API. As the architecture is different, it is advisable to have different databases as well.

So, as per the reference by definition from Chris Richardson, each service in this architecture will be easily manageable and testable, which can be deployed independently and mainly they would be loosely coupled.

Use Cases of MicroServices Architecture

Using MicroServices, it is possible to add new functionality to existing large application. By developing the functionality through MicroServices, it will be joined to the existing system and later on other functionalities can be developed as separate MicroServices.

When the requirement is huge and big data application needs to be developed then this architecture is the best choice. By defining the functional boundaries with separate modules, we can develop the application using multiple teams of developers. E.g. Facebook, being a large application has multiple separate projects available like ads, events, mobile app, news feed etc.

They divide their work in separate team assigned to separate services created for individual functionalities.

It’s also advisable to use MicroServices when intensive work of real time processing is required. Let’s say we can divide this kind of processing task from application and create separate services for them to reduce the load of the same on entire application.

Even when the application requires more analytical data, this would be useful. Let’s say when there is a lot of data available and different analytical reports needs to be generated from the system, this architecture would be useful.

How it Works

Now let’s focus on the architecture and understand how it works. User with different user interface like web app or mobile app, will access the application. As we have a common API Layer which is available, will communicate with the MicroServices.

Each MicroServices will have its own internal architecture available along with Database to fetch and store the data. It is also possible that all services can share same database but different database would be preferred.

In case of requirement of communication between MicroServices, they will user Message Bus to generate the events for the functionality. MicroServices will have their own set of service discovery mechanism to get the message from the queue. Here, API layer is a middle-ware for the application because each component of the application architecture is connected with it.


Due to defined boundaries of service, it can be easy to develop multiple services simultaneously through multiple teams of development. It is also easy to scale up the services when required.

Easy to understand and also easy to deploy independent services. Due to independent structure, in case any error comes up, only some functionality of the application will get affected, entire application will not stop functioning. It is easy to identify the issues in specific services and resolve them and no need to re-publish entire application.

Concept of re-usability can be easily applied with this architecture. Services can be used by another services whenever required. E.g. User services can be used by all other services across the system. When specific functionality or the service becomes more complex to manage, it is easy to scale them horizontally or vertically.


Adding multiple services to a single application may become tough to manage and test the application.
It might be possible that there can be a duplication of efforts due to distributed system.
Also, deploying the application with MicroServices is complex task compare to deploying Monolithic application.


Author: Naishadh Patel 

Let’s build your dream together.