Best Practices for Microservices (Microservices — Part-2)
In this blog, I’m going to talk about what are the good practices that should we follow when we do the microservice-based implementation. When we know the best practices you can avoid the common mistake.
Let's see one by one…
1. Design should be Domain-Driven Design
Microservices is an architecture design model with a specific bounded context, configuration, and dependencies. These result from the architectural principles of domain-driven design and DevOps. Domain-driven design is the idea of solving problems of the organization through code.
The business goal is important to the business users, with a clear interface and functions. This way, the microservice can run independently from other microservices. Moreover, the team can also work on it independently, which is, in fact, the point of the microservice architecture.
Many developers claim microservices have made them more efficient. This is due to the ability to work in small teams. This allows them to develop different small parts that will later be merged as a large app.
They spend less time coordinating with other developers and more time on developing the actual code. Eventually, this creates more value for the end-user.
Important Terms in Domain-Driven Design
- Domain logic
- Domain model
- Subdomain
- Design patterns
- Bounded context
- The Ubiquitous Language
- Entities
- Value objects and aggregates
- Domain service
- Repository
If you need to know about these each important terms, please go through this below link
2. Do not use Hard-coded values
Hard Coding a value means it has been declared as unchanging and cannot be changed directly. When a value is hardcoded, it remains the same as it was throughout the execution of the computer program.
If we see the example:
Assume there are two services as X and Y. Now the service X is calling the service Y. To call Y, you should have its address. So most of the developers hardcoded this address (It may be a hostname, IP address, URL…etc.) on the service A. — But this is not a good practice
If your networking team is decided to change the hostname, URL …etc. then you’ll have to face issues. Because you need to send other deployments. So this is not a good way. In order to stay away from this, we can use some kind of service discovery tool to discover the 2nd service.
3. Logging
In the microservice architecture, there are some challenges in this logging process. Because there are so many services & they communicate with each other through interfaces. For this reason, the normal logging procedure will not applicable.
For example, assume that one application has a network issue. The development team go to the logs and figure it out. But in the log folder may contain logs from different services and it will be really hard to identify correct logs.
3.1 Microservice Logging Tip
- Correlate Between Services —Once all your logs are in one place, you’re going to notice something when debugging: they’re noisy. If you’re working on a high-traffic site, your application generates millions of log entries per hour. That’s too much to look through! Tracing down the bug from earlier is still just as tough, even though all your logs are in one place. To solve this problem, I like to include a unique identifier generated by the client making a request from your server. The identifier is passed between each service needed to complete the request. Now, if you’re trying to troubleshoot a bug, your first step is to identify the unique identifier passed with the request. It’s even better if your error handling includes the unique ID during the error log.
This one tip can save you countless hours debugging your application when you’re using a centralized microservice logging approach. If you take one thing away from these tips, this should be it: get your logs into one place and make it easy to trace a single request between microservices. - Get Everything Into One Place — Getting all the logs from disparate systems into one place makes troubleshooting issues simpler and faster.
- Monitor Your Logs — It’s essential to have visibility into your logs at every level of your microservice architecture. Debugging an issue after the fact isn’t enough. Instead, you need to know as soon as an issue presents itself. Good microservice logging uses logs to tell you before things get out of hand.
- Don’t Sleep on Search — A high-quality microservice logging solution needs a quick and easy way to search those logs. Logs you can’t find don’t bring any benefit.
4. Versioning
Irrespective of the architecture pattern i.e. whether Microservices or Monolith, there are two standard version techniques that are popular in the software community. We will briefly cover what are they and when to use what.
4.1 Semantic versioning
What is it?
Semantic versioning represents each release with the combination of three non-negative integers (MAJOR.MINOR.PATCH ) and each integer implies a certain meaning.
- MAJOR: Increase this number when the previous version is incompatible with the newer version.
- MINOR: Increase this number when the previous version is compatible with the newer version, but internal business logic is changed.
- PATCH: Increase this number when the previous version is compatible with the newer version, but a bug is fixed as part of the newer version.
The increment in either of the three integers automatically implies a certain specific meaning for the consumers.
When to use it?
When you are working on a project with many modules and each module is interdependent on another module, then semantic versioning will definitely be a savior.
4.2.Calendar versioning
What is it?
Calendar versioning is another type of semantic versioning, but instead of using non-negative integers, it is primarily driven by calendar dates i.e. the combination of YEAR, MONTH, and DATE. Rather the fixing the specific date format, it allows you to choose various combinations listed below.
Year:
YYYY — Full year
YY — Short year
0Y — Zero padded year
Month:
MM — Month
0M — Zero padded month
Day:
DD- Day
0D — Zero padded day
We can choose any of the above Year, Month and Day combinations for versioning specific to your application.
When to use it?
When the application is time-bound, this versioning is very much useful. There are some leading operating systems that tie their support cycle based on the calendar version. For major versions, they provide a couple of years of support and minor versions couple of months of support, and their support periods are directly derived from the corresponding version. Ubuntu is an example of this.
For enterprise business application who uses Microservices, I would recommend the Semantic versioning approach. Calendar versioning is more suitable for the products where support and availability period is duration driven rather than usage driven.
5. Authorization and Authentication mechanism in Microservices
In our system, every system starts to validate the user it will lead to increase latencies. But if have a separate identity validation service to validate each service it's much better and you can call directly all requests which come to the service layer to their identity validation service. Once the validation is a success then we can direct them to the rest of the path.
6. Dependency Management
Assume there are 3 different services as X, Y and Z. If you need to deploy Xand if you fail to deploy the other 2 services together, then it will lead to having a set of problems. So we should avoid any dependencies and should be deployed as independently.
7. Fault Tolerance
Microservices need to be extremely reliable.
When we build a microservices architecture, there are a large number of small microservices, and they all need to communicate with one another.
Let's consider the following example:
Let’s say Microservice5 is down at some point in time.
All the other microservices are directly or indirectly dependent on it, so they all go down as well.
The solution to this problem is to have a fallback in case a microservice fails. This aspect of a microservice is called fault tolerance.
8. Documentation
When it comes to documentation, the document should clearly explain how the software or service is operating. It can be text or illustrations. For the developers, this documentation is very important because to get a clear understanding of the particular service.
Swagger is a popular open-source tool that helps to document APIs at any scale. That supports us to design, build, document & consume REST APIs.
