One of the core developers of ISTIO (the Service Mesh designed to make deploying and operating microservices easier in production) has made a compelling case that ISTIO itself is an example of an application is is better off being implemented as a monolith vs. being a set of microservices. You can see how much simpler the monolithic architecture is by comparing the two diagrams below. To read the excellent explanation is to why the decision was made to move ISTIO from a microservices architecture to a monlithic architecture read the post by Christian Posta of Solo.io.
From a monitoring perspective, what this points out is that if ISTIO is not suited to be implemented in a microservices architecture, then surely not every application is either. Which in turn means that vendors who simply remarket Opentracing, or who simply include it in their infrastructure monitoring products are really missing the boat as to what APM means.
ISTIO as a set of Microservices
Notice that the control plan is broken up in to 5 microservices. This is great if each can be evolved independently of each other. This is not so great if evolution of them requires close coordination between the teams evolving them.
ISTIO as a Monolith
Notice that the control plane is just one program (Istiod). Turns out that it is easier to evolve this one program (a monolith), and turns out that it being a monolith is not a barrier to scalability or performance at scale.
Summary
Many people thought that microservices was a trend that would ultimately lead towards most if not all software using this pattern. Based upon this case, it seems like monoliths (and N-Tier SOA applications) are not only going to be around for a long time, but that it is entirely appropriate to build new applications to these patterns depending upon the nature of the application at hand. This creates tremendous challenges for the APM and Observability industries, as a focus upon just one architectural pattern is not going to be good enough.
