Microservices have become very popular due to significant benefits it provides over traditional Architecture especially in management & implementation of large complex applications.
Table of Contents
Introduction to Microservices
Microservices is a type of Architecture in which application is created as multiple small independent serviceable components. Each service component focuses on single business functionality and runs in its own process with its own datastore. Microservices are not managed centrally instead managed independently by different teams which allows each team to choose their own choice of programming language and data-storage technology. These independent teams are responsible for the entire development lifecycle of the service which is managed by them. Microservices Architecture we can say is an improvement over Service Oriented Architecture to address the problems that are attached to Monolithic Service based application. Each service should be small enough to perform only one task and big enough to provide value.
Monolithic Architecture
Monolithic is a very common style of Application Architecture also sometimes referred to as a traditional way of building applications or N tier applications as applications are divided into multiple layers typically 3 or more layers. Common layers being UI, Service & Data Layer.
Each layer is a single unit that can be deployed on separate VM but the complete unit needs to be deployed on each VM. i.e. we cannot split the service layer i.e. for e-commerce to deploy just order service and not any other service like the catalog, payment, etc. Each layer can be scaled horizontally i.e. in event of increased load we can run multiple instances of each layer but complete layer i.e. all services needs to be hosted.
Microservices Architecture
Microservices Architecture is a style in which one large application is developed as a set of small services. Each business functionality is a separate service with its own data store. Here you have many independent applications that run on their own. These services are created/managed by different teams and if required these services can be created using different programming languages. Each service can be deployed independently on a separate VM and can be scaled independently. i.e. in event of increased load, we can increase the number of instances of order service only. These services can communicate with each other using stateless, lightweight protocol i.e. over HTTP or Advanced Message Queue Protocol (AMQP).
Size of Microservice is not important, only it should be independent so that it can be developed, deployed & scaled separately. Also, it should not have too many direct dependencies on other Microservices.
Benefits of Microservices
- Gentle Learning Curve – As business functionality is broken into small services it allows developers to learn just the functionality of that service only.
- Better Scaling – Each service is deployed independently and so can be scaled separately.
- Lesser time to market – Application development cycle can be shorter as each service component is independent of each other.
- Fault Isolation – Failure of one service does not affect the operation of other services.
- No dependency on a single programming language & deployment model.
- Parallel & Fast development of different Services is possible as separate teams are working on different services.
Disadvantages with Microservices
- Small independent services require coordination among each other which may be not simple as compared to Monolith Application
- Managing distributed transactions across multiple services can be complex.
- There are Multiple Services/Components to Monitor.
- Testing can be little time consuming as each independent service needs to be tested before integrated testing.
- Whole deployment architecture for large applications becomes very Complex to Manage.
Microservices Architecture is about better handling a large & complex system but to achieve that it exposes its own set of complexities & implementation Challenges. Despite the disadvantages or problems, the benefits of adopting Microservices are driving factors for many companies to implement Microservices.
Monolithic v/s Microservices
| Monolithic | Microservices |
|---|---|
| Single service/application should contain all the business functionality | Single service should contains only one business functionality |
| All service are tightly coupled | All services are loosely coupled |
| Application is developed in one single programming language | Each service can be in different programming language |
| Single database for all services. | Each service has separate database |
| All services needs to be deployed together on VM | Each service can be deployed on separate VM |
| All services run in same process so if one service goes down then whole application breaks | Each service runs in different process so failure of one service does not affects other services |
| Difficult to scale a particular service as new instance will have to have all services | Can be Scaled easily as any single service can be deployed independently |
| Single large team works on whole application | Separate small team work on each Service which are more focused. |
| Simple to develop & test small applications | Add complexity to the application by the fact that its a distributed system |
API Gateway for Microservice
Any discussion on Microservices cannot be complete without mentioning API Gateway. API Gateway is a single entry point for all clients that takes care of various requests to services. API Gateway helps in managing the endpoints and coordinates with different services. It encapsulates the internal system architecture by not exposing the different Microservices to the outside world.
The request will be received by API Gateway and it will route it to the appropriate Microservice or Microservices. It helps in reducing the number of round trips between client and service by transferring logic for calling multiple services from client to API Gateway. Security also can be handled by API Gateway.
There are also drawbacks with API Gateway like it creates an additional possible single point of failure, can increase response time due to additional hop, if not scaled properly it can become a bottleneck & it is an additional cost too.
Even after drawbacks, there are benefits in implementing API Gateway for large & Complex Microservices based Applications. As if you don’t have API Gateway then client directly sends the request to Microservices and that causes problems such as follows:
- The client needs to know the internal areas of the application so when evolving or refactoring these services it causes breaking changes to the client app.
- A single transaction in client app might require more than one microservice call & this results in multiple network round trips which add latency.
- Each exposed microservice should handle authentication & authorization.
Communication in Microservices
There are no rules around communication within Microservices i.e. if there is a need it can communicate with each other. But this adds to the complexity of Architecture as it creates dependency within individual services. It can cause cascading failures as well i.e. one failing service can cause others to fail as well. A better design would be to minimize calls within services.
Still, if there is a need to implement communication within Microservices then it should be done in a loosely coupled design approach. Microservices can implement communication patterns like synchronous and asynchronous.
The synchronous pattern means making a direct call to the service and waiting for the response i.e. when a client is making a call to service and HTTP protocol can be used for this. This doesn’t mean that client code should be synchronous, based on client design service call on client end can be synchronous (thread blocked) or asynchronous (thread not blocked).
Making synchronous calls within Microservices is not a good design and should be avoided as this will create direct dependencies between them, increase response times, and also cause failure if one of the services fails. If possible always make Asynchronous calls across microservices as the goal of services is to be autonomous and available even if other services (s) are failing.
Asynchronous communication patterns can be used for inter Microservices communication. Queue based architecture can be used for asynchronous communication i.e. Microservices Publishing messages to an event bus. A protocol like AQMP (advanced queue message protocol) can be used for asynchronous messages.
Best Practices
- Microservice should implement only one single functionality that should be able to deliver value.
- Each Microservice should have their own datastore and this should not be shared across services.
- Always maintain updated documentation for Microservices. Swagger UI is a good tool for documentation.
- Use containers for the deployment of services.
- DevOps & CI/CD practices
Summary
- Microservices is a type of Architecture in which application is created as multiple small independent serviceable components
- Microservice should contain only single business functionality and should be small enough to stay focussed and big enough to deliver value.
- Each Microservice should have its own data store.
- Microservices can communicate with each other using lightweight protocol i.e. over HTTP or Advanced Message Queue Protocol (AMQP)
- Microservice can be deployed independently on a separate VM and can be scaled independently.
- There are benefits in implementing API Gateway for large & Complex Microservices based Applications.
You can also check my another Article explaining how to analyze ASP.NET application issues – https://procodeguide.com/programming/analyze-aspnet-application-issues/
Additional Resources: https://dotnet.microsoft.com/learn/aspnet/microservices-architecture
Hope you found this article useful. Please support the Author
