What is Microservices Architecture?

These days a lot of attention is being gained by microservices architecture pattern. A lot of companies are supporting and moving towards microservices because of the ease of development and deployment effort for microservices architecture based applications. I recently finished working on one such interesting project and would love to share my experience with you!


What is Microservices Architecture? 

It is the approach to develop a single application as a suite of small services such that each service runs in its own process and communicates using lightweight mechanisms, often an HTTP resource API.

To better understand what microservices architecture is, let’s see how it’s made a difference.

A monolithic application (earlier) – 

  1. Has all of its functionality in a single unit.
  2. To scale the monolith, it is to be replicated in entirety on multiple servers.

A microservices architecture (now) –

  1. Different elements (functionalities) of an application are kept as a separate service.
  2. Each service could be distributed across multiple servers and replication can be done as and when needed.


Advantages of Microservices Architecture?

  • Ease of Development

With a complex monolith, development becomes painful and the codebase becomes too large for any developer to fully understand. If it’s not understood properly, then there is a high risk of missing out on some use cases. 

In a Microservices Architecture, a functional unit corresponds to a service. One only needs to understand a single function, without worrying about breaking other functionalities.

  • Continuous Delivery

Since a monolithic architecture is one big service even one small change would require you to rebuild and redeploy the entire application. It may not seem much of a problem in case of a small application, but can get really frustrating for applications which take a lot of time to build and deploy. 

We used microservices for our project, so we only had to redeploy the service (functionality) which needed change and it did not affect the entire application. In our monolithic application we were spending more than 2 minutes to build after every check-in. Now it has come down to a few seconds.

  • Great Scalability and Performance:

In a monolithic architecture, scaling is done by replicating the entire application and resources across servers. So even if a particular function needs to be scaled, we would end up scaling the entire application with all the resources which would cost more money and wastage of resources. 

We were using one authentication service which was used by every other microservice. We identified that as a bottleneck and we could scale the entire application, just by running multiple instances of authentication service. 

  • Technological diversity: 

With monolithic architecture we need to decide on one technology stack and the entire application is developed using that. It can’t be changed later, it stays limited to that stacked only. 

With microservices architecture, we can start with the technology stack we require and if needed, later we can add and use different technology stack for different services.

  • Changing technology stack: 

In case of monolithic architecture, to move to a better technology stack we would have to rewrite the entire application. That’s why there are many legacy applications on old technology stack, it’s a costly affair.

With microservices architecture we don’t have to rewrite the entire application in one go, we can choose the specific services we need to rewrite. Even if we have to rewrite the entire application, it can happen incrementally.


Disadvantages of Microservices Architecture?

Just like any other technology,  microservices architecture also has disadvantages:

  • Choose how services within a system communicate

Developers need to choose and implement a means for service communication which could be done either by using messaging or REST. We used RabbitMQ for communication.That’s why we had to create a rabbitMQ server, a rabbitMQ exchange to publish services on and rabbitMQ queues to subscribe services to.

  • Partitioned Database Architecture

The partitioned database architecture is another challenge that Microservices Architecture brings up. Each service owns its own database, hence the common data needs to be duplicated across databases and could also require making changes in multiple databases owned by different services for a single function call.

  • Service Discovery Mechanism

Since each service is a separate unit, there are many moving parts that need to be configured, deployed, scaled and monitored. In addition, you will also need to implement a service discovery mechanism (like eureka) that enables a service to discover the locations of any other services it needs to communicate with.

  • Debugging 

Debugging the application becomes a bit difficult since you would have to run/debug other services’ instances as well.



In this blog, we learnt what Microservices Architecture is, why we should consider moving to it and what are some challenges associated with it.

Make sure you choose the right architecture according to your application. If your application is lightweight and simple, a Monolithic Architecture is the right choice for you. If your application is complex and evolving, Microservices Architecture pattern is a better choice for you.

In the next blog we will talk about inter service communication using service discovery mechanism. 


Banner Image : Link