Overview: Microservice Observability

In the previous chapter, we were able to orchestrate the MTAEDA application so that it’s easy to launch and debug all the components of the system. Every individual service is available for interrogation at runtime, so it’s easy to identify issues and gain the necessary insight to resolve them.

Eventually, the MTAEDA application will reside in several other environments outside of active development. When the application doesn’t work as expected, it’s vital to be able to observe what’s going on internally. Classically, monolithic applications produce cohesive serial logs that can be observed as needed.

Objective

Observability is critical to the speed of the overall development life cycle in quality assurance and user acceptance testing environments. When more effort is required to find out what’s happening during an application failure, this ultimately prolongs the development of a fix and the subsequent testing to verify that fix. DevOps cycles are ground to a halt when whatever’s happening in relation to a bug can’t be observed quickly. In production environments, often, the only way a bug might ever be observed is through the series of events occurring in real-world scenarios. These difficult-to-reproduce production bugs are critical to resolving an application and for it to be viewed as well-supported and reliable.

This chapter intends to explain how to shift the mindset of observability relative to monolithic software development—first, by addressing the challenges through using microservice patterns, then by addressing the challenges introduced by event-driven architecture.