An Introduction Microservices and Their Best Practices
Early and nowadays developers use monolithic architecture to build their web-based applications. But there are some pros and cons related to this. Assume you want to change a small business logic according to a new business requirement. So, you need to put down the entire application for some time to integrate the new requirement into the web application. Assume when developers are working on a large project, they have to maintain a huge codebase. When some problem happens at the production, it is hard to find the place where the problem occurred. Because of that, the developers have to go for a separate support process to fix that problem. When we talk about the advantages of monolithic applications, it is easy to test and monitor. But, if we have some better solution like microservices rather than this, it is easy to implement web-based applications. The following figure 1 illustrates the difference between the monolithic and microservices architectures.
When talking about microservices, it’s important to consider the following points.
- Each microservice has a dedicated purpose of living.
- Microservices can run their processes which implies they do not depend on other processes.
- Microservices can communicate with other services via a lightweight way mainly with HTTP.
- Microservices should be able to scale and deploy independently. Here, the developers have to maintain decentralized control as much as possible.
- It should be possible to implement microservices with different languages and to develop with a small team ranging from 8 to 10.
The Scale Cube
As per the book The Art of Scalability written by Martin L. Abbott and Michael T. Fisher, microservices can be scaled as follows. Refer to figure 2.
- X-axis: Microservices can be scaled by adding multiple copies of their instances.
- Y-axis: A single service can be scaled by splitting it into multiple different services.
- Z-axis: Here, rather than using a single server, we can set the copies of the code in different geographical locations to distribute the traffic among them. But, each server only responsible for a subset of the data.
Best Practices for Microservices
When talking about the best practices for microservices, the following should be taken into consideration.
- Developers should use domain-driven designs to implement each microservice. This implies it is better to create independent services for each domain.
- Avoid hard coding the address of the next calling service. Assume service A calls service B and inside service A, has defined the address of service B. This is not a good practice because if the network team needs to change the address of service B, developers need to change the address declared inside the code by putting down the entire production application for some time. To avoid that, developers can use service discovery mechanisms. As an example service registries can be used to discover the service B.
- It is better to maintain a proper logging mechanism including info, warning, error, etc. to find problems in the production and else.
- When dealing with microservices, it is appropriate to use versioning semantics. As per figure 3, the major version defines the increment when the new version includes some functionalities incompatible with the previous version. Minor version defines the increment when the new version holds some new functions that do not do any harm to the other old functions. In this case, consumers can use both versions without having any harm to their applications. Finally, for the patch version, there are no specific guidelines defined for this but sometimes this is used to define the bug fixes.
- When using microservices, it is essential to consider authorization and authentication mechanisms. Assume each service of a certain web application validates the identity of the logged user. But each validation takes some time. To avoid that developers can use a separate identity management service to validate the logged user and pass the rest to other services.
- Developers should avoid making dependencies between microservices.
- Microservice developers should follow proper fault tolerance mechanisms.
- It is appropriate to maintain proper technical documentation like swaggers.
References
