Overview of Microservices

What are microservices?

It is an architectural style which structures an entire application as a collection of small, independent and single responsibility services.

In simple terms, microservice can be defined as a small but independent functionality of an entire application that runs like a small application itself. It is then many such microservices connected in a network to work as a single application from the user perspective.

Another good defination to microservices is: Isolation of the entire application in small parts with respect to network boundaries as well as functional boundaries.

Microservice communication and data transfer. Source: (https://tinyurl.com/y6gfrfzo)

The best and most used application that is divided into many microservices is Netflix. From the user point of view, Netflix is just a single unified platform but it is divided into many microservices (not sure but of course more than 1000's).

Source: (https://tinyurl.com/y5yg8cxf)

Main Microservices principles:

1. Single Responsibility: Single responsibility means that a particular microservice should have one defined job and functional boundary. For example in an E-commerce site, suppose out of many services there are two services, one for inventory management and other for shipping management so these two services should have their single responsibility. Shipping management should look after all the functionality related to shipping and inventory management should look after all the functionality related to inventory.
2. Separate Processing: Each microservice should have its own place or container where it processes the request and should communicate with each other through REST API, message brokers or must use one of the many communication patterns for communicating with each other. Communication between services is generally preferred to be back-channeled secured communication.
3. Scaling / Resource Allocation Scope: Each service in a microservice architecture should have its own scaling/resource allocation scope which means that each microservice would have a different container (on which it is deployed) requirements. One service may need more or less resource allocation then another. But if we try to use the monolithic approach for resource allocation that means giving the same amount of resource to each service which can lead to overuse or underuse of the resources.
4. CI/CD: Each service should be deployed and maintained in such a way that we can apply Continuous Integration and Continuous Deployment on each service separately. So adding a new feature in any of the services is independent of other services and each service’s development and deployment can proceed on its own pace. If this principle is not followed then releasing multiple new features would be same as a monolithic application in which timeline for releasing multiple new features would be equal to the time that is taken to release slowest developing portion or feature of the application.
5. Maximum Decentralization: In a microservice architecture try to decentralize everything that is possible. This is one of the core concepts of distributed systems. One of the major advantages of decentralization is the removal of a single point of failure which means if one of the functionality in an application has a bugging code it would not affect the rest of the application and only the service that is responsible for that functionality needs to re-deployed once corrections are done.

Benefits of using microservice architecture:

1. Good Maintenance from a development perspective: As each service has an independent role and is comparatively smaller than a single monolithic application, so maintaining or fixing an issue in a microservices is much more easier than an entire monolithic application.
2. Eliminates the fear of single point of failure: The entire single application is divided into small and independent microservices so if one service is down it does not affect other parts of the application which are independent to the service that is down. But in a monolithic application if there is an issue in one part then there is a possibility that entire application crashes.
3. Releasing a feature is less of a headache: In a monolithic application if we want to release a new feature we have to somewhat run integration test on the entire application again to check whether or not the new feature have introduced an issue in some other part of the code. But in a microservice architecture, this is not a case. We just need to perform integration test on the service in which new feature is added or at max on the services that are somewhat interrelated to that service.
4. Highly and Easily Testable: Each service is independent and comparatively smaller than a monolithic application so performing unit or integration test is less time consuming and much easier.
5. Multiple Language Application can be easily developed: In a microservice architecture each service can have a different technology stack. So having this benefit would lead to many improvements like we can eliminate commitment to a particular technology stack for a long time. Many times it is seen that one technology or language is not a good fit for a particular functionality but another technology is a good fit for that functionality so we can implement that functionality in a different microservice with the technology that is a good fit for it.
6. Improve Fault Isolation: In a microservice architecture finding and fixing a fault is much easier than a monolithic application due to the smaller size of each service as compared to an entire monolithic application.

Drawbacks of using microservice architecture:

1. Increased maintenance from a deployment perspective: As each service need to be deployed separately in a separate environment/container so from a deployment point of view this increases much more headache than a single monolithic application deployment.
2. Not suitable for a tight budget and tight timeline applications: As each service requires a separate environment/container to run, This would lead to a single heavy instance (with docker) or multiple instances for the deployment of multiple services which would in turn increase deployment cost. It can also affect the timeline of the application if we don’t have skilled engineers who have some experience in a microservice architecture. In this case, we first have to train our engineers and then they would be able to work on the application.
3. Increased complexity when it comes to inter-communication between microservices: Inter-communication between microservices can lead to a bigger problem if the communication is not well structured. One of the problems can be related to application performance as well as it can also hinder the introduction of new features or an entirely new service.
4. Good coordination is required between teams of different microservices when inter-communication comes in picture.
5. Not so important point but still yet there are not much IDE/Developer tools that explicitly supports microservice development.

Thanks for reading this article. It’s my point of view over the microservice architecture after working on microservices from past 2 years. If you have some other point of view please mention in the comments section.

To get in touch with me you can mail me on “abhijit.chopra5@gmail.com”.