Microservices is a way of building a single application which is composed of many small services. These all services are independent of one another and also tested and deployed independently of one another.
In order to communicate with each other as a part of the single application, these micro-services communicate with each other using APIs that each micro-service exposes.
Common characteristics of micro-services can be mentioned as defined below.
- They do one thing or are responsible for one functionality.
- Each microservice can be built by any set of tools or languages since each is independent of others.
- They are truly loosely coupled since each micro-service is physically separated from others.
- Relative independence between different teams developing different micro-services (assuming that APIs they expose are defined in advance).
- Easier testing and continuous delivery or deployment.
The biggest challenge with the use of microservices is to decide as for when we can use them. When building any product, Initially its quite simple and at that time it’s hard to visualize the benefits of using micro-services, one does not understand what problems a microservice implementation can resolve, So often development starts as a monolithic and when problems begin to arise and teams see use of micro service way of development as solution, but at that time implementation difficult due to cost in converting the monolithic app to a microservices based application.
Monolithic vs micro services
With enough data on the internet about microservices, it seems that microservices are a better option as compared to the monolithic applications but there is also a downside of using microservices and one has to be careful when designing architecture of an application to be developed as a group of micro-services.
The disadvantage of using micro services is increased operational and deployment complexity
Various components in microservices communicate with each other using remote API calls which of course are slower than the internal calls to classes and methods as in case of monolithic applications.
This problem with microservices cannot be removed as this is the standard way in which micro-services actually work. But the careful division of the application into microservices like based on functionality can help to avoid such problems to some extent.
Innovation: As various components of the application are running as micro-services which usually communicate over APIs, so you are provided full freedom to choose the language of your own type, all you have to do is to expose some APIs which other micro-services will use. Freedom promotes innovation.
Flexibility and its lot: When building a monolith one has to plan for the language type one is going to use, start with an architecture and technologies and they will remain for the lifetime of the application. But sometimes same programing language may not be good for all the problems one may want to test a new feature developed in some other language, so a micro-services way of development provides that flexibility as various microservices in the end will be communicating over the APIs without taking care how they are designed internally.
Size: Since microservices are small, they are much easier to understand. There is much less code to go through to see what one micro service is doing. That in itself greatly simplifies development
Scaling: It’s always easy to scale up the application based on the micro-services. As compared to the monolithic app you do not need to scale up the full application, even if you do not want some components to be scaled up, in microservices components being loosely coupled, you can easily scale up the required component.
Deployment and rollback: Microservices being a small piece of code is always easy to build and maintain. Being small, its always an easy task to deploy a micro-services as compared to the big application, also in case of an issue the pain point area is already isolated as you have already divided your application, so it’s easy to find as which area is buggy. In case we realized that there is a problem, that problem has a potentially limited effect and can be rolled back much easier. With micro-services continuous delivery or deployment can be done with speed and frequencies that would not be possible with big applications.
Below is the diagram showing the possible architecture of a monolithic app.
Possible architecture of a microservice based application