4

Best Practices for Microservices

 3 years ago
source link: https://medium.com/geekculture/best-practices-for-microservices-aad94b20497b
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Best Practices for Microservices

Welcome to another article. This article will give you what are the best practices that you should follow when developing microservices. If you are new to microservices you can refer my previous article which is introduction to microservices. So without further taking let’s move on to the best practices you should follow when developing microservice application.

1. Design should be domain driven

When you are planing or designing a new microservice application you need to think it freshly. You need to think about how to separate the entire solution into independent services. Some people put all services in to microservice and say just sake of saying we have moved to microservices. So don’t do like that. let’s say we have a banking application so there are user accounts module , user registration module, deposit module, withdrawal module, credit/debit card handling module. So you need to remember not to put all together in one or two services.

If your application is currently in a monolithic architecture and you are planning to move to microservices. You need to rethink it freshly. There are some scenarios where you don’t need to rewrite the entire application from the beginning. You just need to take some time and rethink. So if there are any services in side another service which are not relevant you can take it out and create a separate module for that. Like wise sometimes you can do it by little changes without rewrite the entire application.

2. Hardcoded values

Let’s say we have microservices called A and B. A is calling the service B using service B address. Sometimes developers hardcode the url and host name on service A. definitely service A now know where is service B. But there are some drawbacks. let’s say the networking team of your company is decide to change the host name or a network address. So if they change it then your application is not working anymore. Then the developers need to do the modification and deploy it again. Since it not a good practice what you can do is there are some service discovery mechanism tools, so you can use those instead of hard coding.

3. Logging

Logging is an important mechanism to detect a failure of the application. But many developers are struggling with the logs. Sometimes developers are using too many logs for a single failure which is not a good practice. So remember don’t use too much logs. You can log where ever you initiated the process. Also you need to log the stack race.

4. Versioning Microservice

The whole point behind versioning is to let you keep track of all the changes and progress you made. So keep in mind versioning is a must. One of the most widely used versioning schemes is the semantic versioning. You can follow the semantic versioning.

1*c2lrK2Bqvntq1p-frD2KcQ.png?q=20
best-practices-for-microservices-aad94b20497b

Semantic versioning is a formal convention for specifying compatibility using a three-part version number: major version, minor version and patch. When you upgrade to major versioning you can deploy that service as a separate service and give a notice to the consumer to upgrade to the new version while you are maintain the previous version. Once all the consumers are migrate to the new version you can decouple the previous version.

5. Handling Authorization and Authentication

In here you need to keep in mind not to validate the user in each and every service because it will add more and more latency to your round trip. What you can do is you can have a separate identity validation service and whatever the request is coming to your service layer you can redirect to identity service. If it success you can direct to the other services.

6. Fault tolerance

In microservices since you have multiple services there are plenty of possibilities to have failures. Therefore, you need to properly manage those. If one service is taking long time to respond, it should be failed fast. Because the waiting time will make an extra queue behind the service. I will explain this in deeper in the next article where I discussed about the design patterns for microservices. So for now keep in mind you need to properly manage if failures are happen.

7. Documentation

As software engineers most people are don’t like to do documentation tasks. However documentation is a must because we need to create a good documentation so then other people can understand it well. Good news is there is a tool called swagger where we can write our documentation in a technical way and it converts all those into a very attractive document.

This is the end of this article. I hope you learn what are the best practices for microservice. Next article most probably will be design patterns for microservices. So time to say good bye and stay in touch.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK