Let's look at a scenario where we are dealing with a very simple monolithic application deployed on a single server:

We can see all the user requests through the browser or other clients will directly hit our application deployed on the server. So when an issue or latency is reported, we know where to look for the problem: you log in to the server, and look at logs and server health. We know where to add all the monitoring and profiling. Well, in the real world, a deployment will be more complex as it will have databases, log files, clusters, load balancers, and so on, but, it is still possible to monitor applications with a monolithic architecture.

Now, let's think about a simple Microservices-based application. An application that implements Microservices will often have multiple Microservices, each one focused on one core solution and interacting with other services to pass on or fetch information.

Take a look at the following diagram to get an idea of the complexity that Microservices can add to the system:

In the preceding diagram, we are trying to show instances of three services deployed on six boxes. Again, to keep things simple, we won't get into Database, Queue, or scalability details. Think of a scenario where you get a call from a user saying that they are not able to access a page or are facing some latency. We don't even know where to start, which box to look at, or which service is down or slow to respond.

Consider the fact that the preceding design is simple compared to a real-world scenario where there might be tens of services with auto-scaling, queues, and messaging, and where services will be spawning up or down as required. Think of the mess we will be dealing with.

These complexities make it very important that we add, monitor, and profile carefully when dealing with Microservices. Now, let's deal with the actual implementation of monitoring in Microservices.