The Best Practices for Microservice Web Application Development

The development of microservice-based production deserves the best practices to have intended outcomes. If we do not follow the best industry realized best practices with microservice development, then you will get more negative consequences on your system.

In this article, we will be discussed about more valuable best practices for your microservice application development one by one.

💛Design

  • As we discuss in the previous article, every area that we intended to apply microservice architecture should follow the domain driven design.
  • Then only, the entire application can be scalable as we needed.

💛Hard Code Values

  • Any software application may consists with thousands or millions of code lines even it is monolithic or microservice.
  • Then mapping for a particular service is really hard and need to do it in a precious manner. Unless, it will create an additional resource usage, time or cost consuming task than expected.
  • For an instance, a rent a car application has 2 services to renting a car to a particular customer (called Service A) and find his/her history through their records (Called Service B). Then as a developer what you can do is map a URL of Service B with the Service A. Somehow, with the new requirements, the developer has to change a host name of Service B. Now what will happen ❓

Definitely, your system will fail. Because, Service A does not know how to map with the new host name of Service B unless you are manually configuring it with the Service A.

  • But with the help of microservice architecture, we can use the Service Discovery Tool with your application. Then it will give signals for other services when one service go offline for its own reason. Until the service is in active use, other services will not call.

💛 Logging

  • Logging is a part of software development which provides information on what the particular code is actually doing.
  • They provide developers with the better understanding on what code snippet actually does.
  • Therefore, as developers you need to maintain a proper logging system with your application for the sake of your help as well others. So, even new developer join with your project he/she can get proper understanding on the development part.
  • Also, it is not acceptable to log everything in your application. But make sure, all the required information have logged.
  • In microservice architecture, we have really fascinating term regarding loggings. That is “Fail fast, Log later”. That means, when the request or requested service see some exception on your service, don’t log it there. So, comeback to its initial state where the journey starts and log there.
  • But, we must need to log on the Stack Trace. [Stack trace is the place where every unhandled exceptions are logged on in the console]. Unless, we might get mislead on loggings.
  • Also, there is another way we can handle logging related with the exceptions.

If you provide specific service ID for every service request hit on your service, then it will easy to track your all service calls at any given time. So, it will be easy to configure when the exception is initiated, where is it initiated, where it goes and so on.

  • To made the loggings you can use a logging framework like Log4J, Splunk, Logstash and so on.
Reference: https://www.haproxy.com/blog/introduction-to-haproxy-logging/

💛 Versioning

  • Your microservice APIs (Application Program Interfaces) will have to be changed overtime. But, you have to carefully think about your consumer services. If not, those services will be die even with your minor changes.
  • In that case, if we can use proper versioning mechanism with the microservices, then your customer will be able to properly migrate with your changes [Force Upgrade]. Once all the users upgraded their services with new version, you can de-commission your old service.
  • Also, in microservices we can have Elasticity Mechanism to manage our versions on applications. What happens in when we have old and new versions, your clients will upgrade their services to compatible with your new services. Then you can reduce the instances from old service while increasing the instances from new service.
  • In Docker, it generates an isolated operational environment. So, when you need more instances you can create multiple Dockers. If you do not need them, can destroy as well.
  • In that case, the Semantic Versioning is really useful.

✨Semantic Versioning : It clearly states about,

— If it is a bug fi, then which digit you should increment,

— If it is a new functionality but compatible with older version, then which number should increment,

— If it is breaking a existing functionality and not compatible with the existing function, then which digit you should increment and so on.

Then your consumers will be able to get a clear idea about which version can be used with their requirements.

💛Authentication and Authorization Mechanism

  • One of the time consume tasks in software application development. Because, when all the requests are validated by your service, then it will add more latency.
  • But we can use separate ID Validation Service to validate all the services request to before hit our service. Also, it allows you to change any validation and authentication processes based on your algorithms.

💛Dependency

  • Microservice architecture is based on the loosely coupled concept. So, it requires to avoid any hard dependency between the services as much as possible.

💛Make an Executable Contract with your Users

  • Any system is intended to make happy their users or client.
  • It is not good, even you deploy a fully functioning and upgraded service which is failed to serve your users.
  • Therefore, we can implement a contract between you and your users.
  • We can create different testcases and test scripts in this executable contract with users. Then, whenever you do changes with the service, it will go through these test scripts and test cases. Only if these test cases and scripts are passed, then you can implement the changes with your service. Then your users will never be failed with the new service changes.

💛 Fault-Tolerance

  • When your service take more time to respond your service request, then your system will get long queue and will make the system inefficient.
  • Because, microservice architecture has small microservices which are communicate with each other. Therefore, breaking of one service will be affect on directly or indirectly on other services as well.
  • As a solution, microservice based system can implement the Call back function [We will discuss more about this area in one of my incoming article of Circuit Breaker Pattern].

💛Documentation

  • Creating documentation is really helpful for microservice-based system users to get a clear understanding on each and every areas of their application.

So, in this article, we have discus about some major best practices we should follow when implementing any microservice based application. In my next article, we will discuss about the design patterns which will be used in industry to develop microservice applications. Until then,

Stay Safe !!!

References:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store