The Best Practices for Microservice Web Application Development

  • 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.
  • 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 ❓
  • 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 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.
  • 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/
  • 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.
  • 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.
  • Microservice architecture is based on the loosely coupled concept. So, it requires to avoid any hard dependency between the services as much as possible.
  • 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.
  • 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].
  • Creating documentation is really helpful for microservice-based system users to get a clear understanding on each and every areas of their application.

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
Sanduni Jayaweera

Sanduni Jayaweera

Associate Software Engineer at Virtusa.