What are microservices
Before starting to check if the microservice architecture is the best option for your project, we will try to understand what are microservice. If you think that writing the code and exposing it as the REST service is an microservice. Your understanding is wrong. Not each REST api is microservice. We will discuss about them in details in this article.
In the software industry there are three types of architectures.
These are monolithic, SOA and microservice. In the 2000’s, the enterprise applications were developed using monolithic architecture. All the UI, business logic and DAO objects resided in single server. All the code present in this server used to communicate to the DB. There was no modularity or loose coupling.
SOA or service oriented architecture was mainly build by dividing the logic across multiple services. This would help other applications to use the same logic if required. It was not tightly coupled to single application. There service could be deployed in different servers as compared to data access code or UI code. In this type of architecture the UI would not communicate directly with the services rather it would interact using a proxy URL provided by tools like enterprise service bus.
Microservices is the latest evolution of the way the applications interact with DB’s. In the Monolithic or SOA architecture even for a single change we had to make a whole release, which would cause time and resource wastage. In microservices architecture, all the business components are divided into small separate services. This helps to reduce the deployment time. These services are easily scalable.
Microservice characteristics
Below are some of the characteristics of Microservice:
Microservice are small
As the name suggests, these are small and easily understandable piece of code. But how would decide, how small is small? The answer is , if you loose your code of the microservice or throw it somewhere and you are able to re write it in couple of days or may be in a week or two. You have got a microservice.
Focused one task
This is really related to separation of concerns in the problem domain. If you are handling and doing multiple things in your service, that is not an idle candidate for microservice. It does one task when viewed from outside. Here the modules are not coupled with each other. Individual features can be released and deployed without disturbing or testing other modules.
Aligned with a bounded context
It is an important criteria to have an idle microservice but is missed by the most.
“A bounded context is a defined part of software where particular terms, definitions and rules apply in a consistent way” – Eric Evans in Domain driven design.
Autonomous
The teams which are are working on a specific microservice can work separately without collaborating with other teams. The team can change the implementation of the service without coordinating with anybody else.
Independently deployable
Deployability is one of the feature of these services which make them highly useful. As a team working on one feature of the project need not to be dependent on the other team as non of the functionality cross each other.
Teams can decide independently when to deploy each part of the service.
If you need to test your service with other services, its not a microservice. We should be able to build, test and deploy the microservice independently.
Loosely-coupled
Make external and internal representations different. The interface to a microservice is a public API.
Drawbacks of Microservices
Each good thing comes with some drawbacks as well. That is true with microservice as well.
Complexity
Microservice are highly complex due to their scattered nature. We need to maintain multiple systems for each and every service. These are ideal for big teams. These teams can individually take care of these systems.
Infrastructure Overhead:
There is a huge infrastructure overhead to maintain these services. Since we need to deploy all of them to the individual containers.
Security concerns:
In monolithic and SOA architecture we have to be concerned about only one system. But that is not the case with microservice and it becomes easier to have security loopholes in this architecture.