Microservice architecture is an application structure that fosters the use of a loosely coupled system to allow you to develop, test, deploy, and release services independently of each other. These services are part of a unique system, and the idea behind using microservices is to break a big problem in smaller problems. Usually, each service interacts with the others through an HTTP endpoint, hiding the details of its technology stack by exposing only a contract to its consumers. Service A will call Service B, which at the same time calls Service C. Once the request chain is complete, Service A might be able to respond to the end customer that initiated the request.
Microservice architecture offers a lot of great benefits like the ability to use different technology stacks, deploy independently, solve small problems one at a time, and more! But using microservices comes with a high cost in that they are complex…not only in how they communicate but also in how to manage them. And they get even more complicated when one or more services fail. Which service failed? Why, and under what circumstances? All these questions are hard to answer if you don’t have good, meaningful logs.
And let’s be honest, we all hate those “unknown” or “something went wrong” system errors. I myself have struggled with the problems that come from a lousy logging strategy. Let me share a few best practices that have helped me when dealing with microservices.